Albert van der Horst wrote:
> 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.
>
I never mentioned IDEs, since this is the most trivial aspect of your
development toolchain, especially when your team is larger than one. In
fact, I took pains to be as non-specific about the many and varied tools
we can use as developers, except to note:
- Languages often have their typical and common sup****t tools, which are
often languages in their own right. As developers we use "little
languages" all the time. Each one must be grokked.
- When comparing and contrasting languages it is easy to fall into the
trap of comparing specific and personal development environments vs. a
bare language. This is, of course, unfair and misleading.
> 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.
>
This actually seems to prove my point that the toolchain goes beyond the
language, and that each language has an explicit or implicit reliance on
any number of other stuff.
Someone had to learn Make well enough to grow this build system you
describe. It did not come for free, it did not spring fully formed from
your forehead and it was not copied verbatim off the internet.
A trivial makefile is just that: trivial. It can't do much, and if you
want more, you have to learn the arcane syntax and solve the problems
and generally debug the build system as you would a program.
I said "arcane" and I meant it. Make has a syntax all its own, and
learning how to even get by with make is a good skill that is almost
required to be a good C coder on most platforms. Especially if you do
cross-platform development on a large applications suite with a large
team, as I do.
> You can't do that with windows. I mean it: full stop.
>
I have no idea what you mean. Nothing you describe in the previous
paragraph is platform-specific. I do what you describe and more with
Make on Windows every day.
I'm not entirely sure what part of the rest of my comments you
specifically disagree with (you quote a long passage of mine, and then
simply say you disagree -- but with what?), but I don't think I'm making
any earth-shattering assertions here.
Being working developers means having to invest learning time into a
variety of non-language specific domains. These domains are somewhat
shaped by the language itself, and can often be considered part of the
language when it makes sense to do so.
If we are to compare HelloWorld, let's compare HelloWorld. If we are to
compare solving real-world problems for customers and maintaining a code
base for decades, lets talk about that. Context is everything.
Anyway, everyone knows that after the Language Wars are over we will all
be forced to use COBOL in re-education camps. I, for one, welcome our
wordy and punctuation-filled overlords.
--
clvrmnky <mailto:spamtrap@[EMAIL PROTECTED]
>
Direct replies to this address will be blacklisted. Replace "spamtrap"
with my name to contact me directly.
|
