Subject: Re: Theory #51 (superior(?) programming languages)
From: Erik Naggum <>
Date: 1997/01/20
Newsgroups: comp.arch,comp.lang.lisp,comp.lang.scheme
Message-ID: <>

* John Bayko
| For comparison, I've written toy programs in LISP, and it's fun, but how
| would you write a windowing system or database in it?  I'm sure LISP
| experts could do that with their eyes closed, but it's not obvious in the
| structure of the language...

it isn't?  if your argument is that I/O is made up of function calls in C,
I'm curious in what way you think I/O is _not_ function calls in various

| Basically, C was the first high level language that was low level enough
| to be useful, getting rid of the conventional abstractions that got in
| the way. Now we just take that for granted - when was the last language
| you've seen designed where I/O was not a function/procedure/method, and
| which didn't have most if not all of C's operators?

if you design a language small enough, _all_ other languages will have to
have all operators that is also in that language.  however, _I'd_ like to
have a language that defined the value of division of signed integers.  C
doesn't.  _I'd_ like to have a language that defined the width of integers.
C doesn't.  _I'd_ like a _low-level_ language to handle integer overflow,
or at least give me access to this absolutely _vital_ information.  C
doesn't.  (in C, A+1 is either A+1 or 0 if A is unsigned or -(A+1) if A is
signed, and you have _no_ way of knowing which, short of testing for the
returned values, which is feasible only for a small number of operations.)
_I'd_ like to have a language that supported strings with any defined
_character_ in them.  C doesn't.  the list goes on.

so how come programmers thought this _loss_ of, e.g., overflow, was a good
thing?  any assembly-language programmer worth his salt checked overflow.
(except those at Bell Labs, obviously.)  any calculation with integers of
_unknown_ size must be _distrusted_ if you can't even know when an integer
operation has overflowed the range of the hardware.  matter of fact, C is
the only _language_ I know that leaves the programmer totally in the dark
as far as such serious computational errors are concerned.

I'm now writing software in Common Lisp.  I struggle with many profoundly
_counterproductive_ habits that I totally internalized in the 13+ years I
programmed in C under Unix -- such as caring about memory expenditure, such
as having flashes of angst due to the low performance of some piece of code
that is used _once_ in a program that runs for hours, such as disassembling
to see if a function was inlined.  I have to learn _not_ to care about
these things, because they are _fundamentally_ unimportant to programming.
but my hunches still go in the direction of premature optimization.  funny
thing is, I was _less_ obsessed with performance when I wrote in MACRO-10
for PDP-10 (the world's most beautful CPU) than I later was in C.

1,3,7-trimethylxanthine -- a basic ingredient in quality software.