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

* John Bayko
| >_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.
| That's a problem too, but it's not so bad since it doesn't happen very
| often, and when it does, you can compare to predefined MAXINT type
| constants and filter values before they overflow (instead of after,
| which might be better for reliability in the long run anyway).

I guess this depends on what kind of programmer you are.  I would rather
sacrifice speed than accuracy.

| If you don't like C's strings for example, use arrays - same thing.

I must have been unclear.  C's arrays don't know how big they are, either.
the zero byte terminating C's strings is just one of the many possible ways
to handle this fundamental design flaw in C.

| And when they do, they've invested enough effort that it's easier to just
| work around them than restart in a better language... (another element of
| C popularity - the simple/complex transition trap!).

you cannot possibly work around all the problems in C.  it would slow your
program (not to mention your _programming_) to a halt, and that highly
appreciated performance edge in C would just simply cease to exist.  safe C
is extremely hard to write.  buggy C is easy to write, in fact, _anybody_
can do it.  and that's precisely what they do: it's what's makes a language
the "most popular".

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