[prog] Sample implementations of UNIX utilities.

[Robert J. Hansen]

> masochistic, I do think C is very relevant indeed to modern programming. For 

Oh, I never said it wasn't.  :)  At some point every programmer needs to
know how to break the silicon to his/her will, and the best way to do
that is to learn Assembly.  But since we've long past the point where
universities routinely teach Assembly, C will do in a pinch--you lose
the entire notion of registers [*], you lose most of the direct
connection to the CPU, but at least you get direct memory addressing and
pointer fun.

[*] `register int x = 0' notwithstanding.

> one, a "portable assembly language" is a very good way of teaching how 
> computers actually *work*.

Or, alternately, it's a lousy way of teaching how computers actually
work.  The lambda calculus is, IMO, the best mathematical construct we
have right now to describe the Universal Turing Machine--thus, I think
languages which emphasize the lambda calculus are very good ways of
teaching how computers work.

On the other hand, if you want to know how a given _implementation_ of a
Turing Machine works... then yeah.  You have to get gritty with the
silicon.  The problem is this knowledge is generally pretty
nonportable.  Take a coder who's worked on IA32 his/her entire life,
drop their best code onto something with a truly _bizarre_ memory layout
(Intel = ABCD, PPC = DCBA, old PDPs were ACBD, if I recall!) and see how
many errors get flagged.

> Hmm...having read that link, I'm interested in why you call it a "rant," 

Mostly because I've received quite a few emails from morons since it's
gone up talking about how C is the talismanic ne plus ultra of
computation.  :)  

Honestly, while I think C is a great teaching tool, I think the
open-source world is in an unhealthy relationship with it.  There are
too many young punks (and punkettes) who think that they know C and
Perl, and thus they know Everything Worth Knowing about programming.  We
need to open our eyes to other ways of thinking about computation, other
ways of solving problems.  

> know about (I don't know much in the way of what (s)he calls "theoretical 

He.  :)

> have in C... :-) It must be something in me, really - I *enjoy* the sensation 
> of being able to tell my machine *exactly* what to do, and no messing. Why 

Please note that my rant was only about practical programming--when
you've got a specific goal which you need to accomplish in the shortest
time possible while still meeting your reliability and safety targets. 
If you're just programming for fun, hell, write in INTERCAL.  If it's
for fun, go to town with it.  :)

> memory. It also lends an understanding, as I have mentioned earlier, about 
> what's actually going on - also explains why you feel that performance hit 
> when you use a GC'ed and memory protected language like Java (you're right in 

As an interesting aside, I saw an IEEE article a while ago which showed
a GC algorithm which could outperform most manual GC.  As I recall, it
applied only to FORTRAN, but... the upshot is it's not a hard and fast
rule that GC _must_ impose a performance penalty.  Except in Java, where
I think they actually specify that the GC algorithm must suck.

(In reality, Java puts very few requirements on the GC algorithm--it's
very much open to the implementor.  But forgive me for thinking Java GC
is bletcherous.)

> Also, the performance thing *does* matter. Why does Zeus sell? Because it can 

Sure, for certain aspects of the problem domain.  But just because
certain parts of the problem domain demand Assembly-level speed and
response time doesn't mean we should expect that the entire problem
domain demands that.

> high-level language for the rest of your career, I'm pretty sure that the 
> *ability* to do raw speed and efficiency, and the understanding of how it all 
> works under the surface, are pretty valuable. And this does not apply solely 

Sure, the skills are valuable.  I'm not suggesting anyone should say
"bah, why learn C, it's useless".  But a skill that's just as important
is being able to choose the right tool for the job, and being able to
use that tool effectively.

> to the "low-level drivers and VM code" shoebox that you seem to believe is 
> all C is good for ;-)

I don't think C is good only in those areas.  Off the top of my head,
there's the embedded space and FFI, both of which are _large_ problem
domains.  But most of us aren't going to spend our careers working
there.  :)

> Oh yes, and while I'm at it - about that list of write vs run times for the 
> mathematical algorithm whose name I can't remember (d'oh): that's a tad on 

Sieve of Eratosthenes.  I posted a short C++ snippet to the group a
while back which was called the Sieve, but which didn't actually
implement it--I was using it only to show some aspects of the STL. 
That's not the same as what I used in the Compiler Theory course.

> the misleading side. Of *course* the C++ one is going to take bloody *ages* 
> to do, if you're doing weird things with constructors so as to do most of the 
> compilation at compile-time. I call unfair test! :-P

It's not at all unfair to use the strengths of a language.  C++ _rocks_
for numeric programming thanks to template metaprogramming.  Take a look
at the Blitz project, which just blows my mind in a dozen different
ways.  We've spent fifty years optimizing FORTRAN compilers to be the
absolute best, bar none, at numeric programming and here comes Blitz and
blows FORTRAN away.

Read Chapter 24 of Stroustrup's "The C++ Programming Language".  He
makes a very good point, one which I wish more of my managers
understood, that programmers and programming languages aren't identical,
and that by forcing everyone in a department into the same
lowest-common-denominator you wind up wasting (a) the best talent in
your office and (b) the best tools in your toolbox.

> Right, I've just spewed a whole load of stuff, and I'm not quite sure how 
> comprehensible it is to people here, and whether anyone will agree. Thoughts? 

Oh, I disagree--but I certainly find your comments to be interesting. 
:)