Subject: Re: Theory #51 (superior(?) programming languages) From: Erik Naggum <erik@naggum.no> Date: 1997/01/21 Newsgroups: comp.arch,comp.lang.lisp,comp.lang.scheme Message-ID: <3062873324634283@naggum.no> * 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". #\Erik -- 1,3,7-trimethylxanthine -- a basic ingredient in quality software.