Aleksej Saushev wrote:
> Andreas Klimas <klimas@[EMAIL PROTECTED]
> writes:
>
>> John Doty wrote:
>>> John Passaniti wrote:
>>>
>>>> Three of the most common features of Forth that people point
>>>> to when comparing against C is interactivity,
>>> Very im****tant in the past. But these days the *systems* are
>>> 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 ;-)
>> and it is still clumsy.
>> 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.
>
>>>> and 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 sup****t 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.
>> more complex dependency for makefile. C code generators tend to
>> 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?
>
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 ex****ts 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.
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@[EMAIL PROTECTED]
>
Direct replies to this address will be blacklisted. Replace "spamtrap"
with my name to contact me directly.
|
