[prog] Sample implementations of UNIX utilities.

[Robert J. Hansen]

> Surprisingly enough, it's written in C. (as are a few Java VMs)

It's not at all surprising.  C/C++ have a very real place in the programming
world.  I've never claimed they don't.  One of those very real places is for
systems-level stuff, like virtual machines and kernels.  See my Webpage on
the matter--http://home.earthlink.net/~cortana/c_relevance.html .

> I'm probably one of the quickest people to fall back on C/C++ because I
know
> that I can do whatever I need to on any platform.  At the same time, my

The question isn't whether or not it can do what you need to on any
platform.  INTERCAL can do what you need to do on any platform.  All
Turing-complete languages are equal to all other Turing-complete languages;
the only question is how many operations it will take and how safe your code
will be.

The real question is whether or not a given language will let you do
whatever you need to be done _quickly_.  For instance, in ML I can write the
Sieve of Eratosthenes in about fifteen minutes.  I can spend another ten
minutes giving a rigorous mathematical proof of correctness--i.e., I've
proven my code is one hundred percent free of unintentional bugs [*].  I
compile the code, and presto--in under half an hour I've got the task done,
and thanks to the PoC I know it's done _right_.

Or I can sit down in C, worry and fret about whether or not I'm handling
input in a proper and safe fashion, worry about whether my pointer
arithmetic is right, never be able to do a proof of correctness because it's
C, write another program to validate the outputs in order to make up for the
fact I don't have a proof of correctness... and a couple of hours later, the
problem is solved.  Total execution time might be a second or two, total
programmer time is much higher.

[*] A program which has been proven correct doesn't necessarily mean it's
totally bug free.  To quote Knuth, "Beware bugs in the above code.  I have
proven it correct; I have not actually tried it."  :)

> Languages are sort of like hammers.  Sometimes you need one of those
little

Languages are just tools in the toolbox.  A wise hacker will use the right
tool for the job.  For writing a LISP VM, I'd certainly use C or Assembler.
But as soon as I had the read-eval-print loop done, I'd start to write the
rest of the LISP environment in... LISP.

The simple fact--and yes, from where I sit, it is a fact--is that C/C++ are
grossly overused in the programming world.  It made a lot of sense to use
C/FORTRAN back in the 60's-'80s, when apps were primarily processor-bound.
It doesn't make much sense to use them today, when apps tend to be primarily
interface, memory, network, or input-bound.