Re: advantages of forth over other languages
- From: Clever Monkey <spamtrap@xxxxxxxxxxxxxxxxxxxxxxxx>
- Date: Wed, 30 Apr 2008 12:54:44 -0400
Aleksej Saushev wrote:
Andreas Klimas <klimas@xxxxxxxxxxxxxxxxxxxxx> writes:Well, I think you've highlighted at least one issue that the OP might have meant: you've described a situation where you not only have to know C, you also have to know about the public interfaces and exports of those libraries, and you have to learn the extremely arcane syntax of another language: make. Sure, once you know how to make that basic Makefile, you know it. But, how do you get to that knowing? This is part of the "cognitive load" required to work with that language environment.
John Doty wrote:John Passaniti wrote:and it is still clumsy.
Three of the most common features of Forth that people pointVery important in the past. But these days the *systems* are
to when comparing against C is interactivity,
interactive and I can get around the edit/build/test loop in a
few seconds even with a compile/link language. Faster than I
can think ;-)
you need a C-File, probable H-File, edit Makefile, take
care of dependency have to link a lot of libraries every
time only to get a small (test) function running.
If you have pretty widespread BSD system (NetBSD, OpenBSD, FreeBSD),
you only need to type "make this", and it will compile "this.c",
link it, and bring you executable without even asking you to
write Makefile. If you want more complex things, you have plenty
of examples in your /usr/src, and once you learn it, you get plenty
of libraries to suffice your needs, which you can't say about Forth.
more complex dependency for makefile. C code generators tend toand the ability to do run-time evaluation.I assume you mean compile-time: I know of few languages that
prevent run-time evaluation!
But here, C folks again use the *systems* that support C:
generate C code with a script or another C program during the
build. You can have whatever build-time computation you want
that way.
be more complex as those little building words in Forth.
Oh really? This so trivial, that you even can't imagine.
For instance, this is Makefile for expr(1) tool from NetBSD
empty lines removed:
# $NetBSD: Makefile,v 1.14 2000/09/19 17:20:00 jdolecek Exp $
PROG= expr
SRCS= expr.y
.include <bsd.prog.mk>
Really complex, isn't it?
Technically, one may have to learn the shell language they use as the basis for the edit-compile-test loop, as well.
None of this stuff comes for free.
When comparing and contrasting languages, we should be careful to compare apples with apples. In the case of C we should recognize that the entire development system often includes much more than the core language and compiler, and each component adds to the potential cognitive load, and is not a "freebie." Each one has to be figured out as you go.
One need only remember those first-year students who knew [insert some language here] but were confronted with an unfamiliar development environment. Around my school, this made for some tense end-of-semester projects as many people struggled with everything /other/ than the code! Not an impossible hurdle, of course, but it is unfair to simply hand-wave this part of the C experience as trivial, because it most certainly is not.
In fact, if you survey some of the threads over on comp.lang.c you will find a not insignificant percentage of them are related to folks trying to figure out the linker, the environment or something completely separate from the language and compiler.
I would note that the entire language environment is precisely what we want when we choose a language, so it is this total environment (including how build artefacts are created and deployed) that should be considered when comparing and contrasting. The "compiler" or whatever is often only a small part of the considerations we have to make as working coders.
This is why the much-maligned Java is so successful in some ways: it offers a near-total source-to-artefact development and deployment solution, along with a Good Enough OO language spec and compiler. With all its failings it offers all sorts of non-language related tools that make it very attractive for (certain types of) enterprise development.
So, by all means, let's talk about how the different toolsets we can use as developers helps or hinders our work. But lets not be naive about the full scope of understanding needed to really get the most out of a particular language. C is an excellent cross-platform object code generator. Actually getting that object code and doing anything useful with it requires a whole set of tools that is not part of the ISO C standard.
--
clvrmnky <mailto:spamtrap@xxxxxxxxxxxxxxxx>
Direct replies to this address will be blacklisted. Replace "spamtrap" with my name to contact me directly.
.
- References:
- Re: advantages of forth over other languages
- From: Andreas Klimas
- Re: advantages of forth over other languages
- From: Aleksej Saushev
- Re: advantages of forth over other languages
- Prev by Date: Re: TIFF in Forth
- Next by Date: What's right with FORTH and wrong with c.l.f.
- Previous by thread: Re: advantages of forth over other languages
- Next by thread: ANN: FORTH, Inc. is moving!
- Index(es):
Relevant Pages
|
