In article <fva8b0$cbt$1@[EMAIL PROTECTED]
>,
Clever Monkey <spamtrap@[EMAIL PROTECTED]
> wrote:
>Aleksej Saushev wrote:
>> Andreas Klimas <klimas@[EMAIL PROTECTED]
> writes:
<SNIP>
>>
>> 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.
There is a huge difference between the above Makefile and using
Visual studio. If I have a similar project I can just copy the
include statement without much idea what the hell bsd.prog.mk is.
If you look into my Makefile's for the ciforth project, you
see commands for making archives, tests, get bits of information
from the source, sort it and shape it in different kinds of
do***entation and builds for a zillion configurations and versions.
This was a lot of work to figure out, and little of it had to do
with knowing about make. So the Makefile is an invaluable condensation
of all there is to know about the project, shaped in a form very
well adapted to a project. And, by the way, you see very little
of ``very arcane syntax''. I'm just too lazy too learn that.
You can't do that with windows. I mean it: full stop.
My renesas environment on Linux s****ts building it out of a version
control system, in different versions, an automatic test using
kermit, tailored do***entation. This is vastly superior to the
Studio like official Renesas environment for building.
*That* can hardly build my Forth and put it into flash.
Adding other features there amounts to finding the correct tools,
buying them, having them cooperate. But graphics tools are just
not flexible enough. How to get rid of lines starting with a '!' ?
( |sed -e '/^!/d'| ). If the tool builders didn't have the foresight
to build that in, at the place you need, you're toast.
If they have, chance is that bugs crop up if you want to loose Forth
comments, because '\' is a character they didn't test for.
Graphic tools only work for just another run of the mill
program, of the sort the tool builders foresaw.
>
>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.
I don't agree. If you add domain knowledge to a hello.c program
you have something useful.
The hello.c program you can steal, if you can't type it in by
heart.
The rest amounts to
make hello
This is the innocence Bill Gates stole from us.
May I talk again about ciforth? There is one library file, and one
executable for interpreting, scripting and stand alone executables.
Even if there are some things that are awkward to use, at least you
need not find out which (if any) of a number of very alike icons does
what you want it to do. You can just bloody read it. Great invention,
language. Much better than icon language: the drawings of spears and
mammoths on the walls of caves.
>clvrmnky
Groetjes Albert
--
--
Albert van der Horst, UTRECHT,THE NETHERLANDS
Economic growth -- like all pyramid schemes -- ultimately falters.
albert@[EMAIL PROTECTED]
&=n http://home.hccnet.nl/a.w.m.van.der.horst
|
