[prog] Sample implementations of UNIX utilities.

[Kathryn Andersen]

On Tue, Dec 24, 2002 at 12:51:10AM -0600, Robert J. Hansen wrote:
> > My favourite acronym for LISP is
> 
> That one's an old and hoary joke--still somewhat accurate, though.
> 
> > which lets you know what I think of *that* language.
> 
> Suggests to me you haven't programmed in it long enough to see the beauty of
> functional programming.  :)

Not at all!  Functional programming is cool.  Every now and then I
mutter to myself that I should take another look at Prolog.  And I
enjoyed Miranda in the same course in which I learned LISP.  It isn't
*functional programming* that I found irritating about LISP, it was,
indeed, the irritating stupid parentheses, which contributed to its
sheer unreadableness.  Not to mention the cryptic commands like 'cdr'.
Prolog was much cleaner.

Mind you, I've gotten the impression that if one wants to actually *do*
anything in a functional language, the pure beauty and elegance of the
interface tends to get kruft tacked on in order to interact with the
messy outside world.

> After a while, the parens make sense to
> you--especially if you've got a background in set theory.

Or Lambda Calculus?
 
> > If you want something that is fast and portable across a lot of
> > different architectures, use C/C++.
> 
> I've seen too much Real Code which was ridiculously unportable using C/C++.
> For instance, look at how much C/C++ code assumes Intel endianness, 32-bit
> pointers and 32-bit integers.  For every one programmer who painstakingly
> writes code to handle crossplatform issues well, there are a dozen who
> genuinely don't care.

I wasn't actually talking in those terms -- though that kind of stuff
*is* dealt with at my work, but it tends to get stuck in low-level
libraries so that the rest of us don't have to worry about it.
I was thinking more in terms of the sheer number of platforms that
actually have C/C++ compilers either as standard or easily available.
Or are you going to tell me that there's a LISP compiler that comes on
the Solaris supplemental install disk, for example?

Now, maybe if you're only sticking to Linux systems where you can easily
install everything and the kitchen sink, you can afford to range further
afield, but if you have something which needs to work across Solaris,
HP, Dec, IBM and Linux, say, on systems which are controlled by someone
else (the client) who won't give you root access and doesn't want you
installing a whole heap of ancillary programs... C/C++ is the safest bet.

> That's why I prefer LISP, Ocaml/SML, Python and
> Java--they don't make crossplatform promises, they _are_ crossplatform.

All that being said, Java looks promising for doing pretty UI frontends
which are crossplatform -- while doing the backend in whatever you want
(such as the already-existing C/C++ backend... (grin))
 
> Besides, as I pointed out a couple of messages ago--apps are rarely
> processor bound anymore.  Why are we using C/C++ to squeeze every last bit
> of performance out of our cycles, when our problem is lack of _programmer_
> time, not lack of _processor_ time?

a) because some types of programs do actually need every last bit of
performance
b) because there are good existing libraries in C which save one having
to reinvent the wheel -- thus saving programmer time

Oh, and Merry Christmas!
 
Kathryn Andersen
-=-=-=-=-=-=-=-=-
There are no Accidents Of History.
	-- Kaijen, Observations
-- 
 _--_|\	    | Kathryn Andersen	<kat at katspace.com> <http://www.katspace.com>
/      \    | 
\_.--.*/    | GenFicCrit mailing list <http://www.katspace.com/gen_fic_crit/>
      v	    | 
------------| Melbourne -> Victoria -> Australia -> Southern Hemisphere
Maranatha!  |	-> Earth -> Sol -> Milky Way Galaxy -> Universe