Newsgroups: comp.arch,comp.lang.lisp,comp.lang.scheme
Path: cantaloupe.srv.cs.cmu.edu!das-news2.harvard.edu!news.dfci.harvard.edu!camelot.ccs.neu.edu!nntp.neu.edu!grapevine.lcs.mit.edu!bloom-beacon.mit.edu!panix!news.mathworks.com!howland.erols.net!newsfeed.internetmci.com!demos!pluscom!usenet
From: moroz@inist.ru (Oleg Moroz)
Subject: Re: Theory #51 (superior(?) programming languages)
Content-Type: text/plain; charset=us-ascii
X-Newsreader: Forte Agent .99g/32.339
Sender: usenet@news.rinet.ru (Backup pseudo-user)
Content-Transfer-Encoding: 7bit
Nntp-Posting-Host: inist.cronyx.ru
Organization: Cronyx Ltd. Rinet Internet Access Site
Message-ID: <32e6a3d8.4322028@news-win.rinet.ru>
References: <5c5c65$9ed@news-rocq.inria.fr> <3062937607803710@naggum.no>
Mime-Version: 1.0
Date: Wed, 22 Jan 1997 23:43:34 GMT
Lines: 30
Xref: glinda.oz.cs.cmu.edu comp.arch:74545 comp.lang.lisp:24745 comp.lang.scheme:18023

On 22 Jan 1997 16:00:07 +0000, Erik Naggum <erik@naggum.no> wrote:

>* Robert Harley
>| In the ring "modulo 2^n, where n is the number of bits in the type",
>| according to Mssrs Kernighan and Ritchie.  If you assumed a different
>| ring (such as Z) that's tough.  You should read the language spec
>| before pontificating in error.
>
>you gotta love this kind of response.  it's the language specification that
>is in error.  just as it is in error in many other ways.  division between
>two signed integers can yield either floor or ceiling depending on what the
>CPU architecture supports.  chars are signed or unsigned according to what
>the "hardware" thinks is faster.  etc.  the _language_ C is underspecified.
>no matter how well they write their specification, C remains underspecified.
>
>C is _designed_ to be "fast but unreliable".  _that_ is the problem.

The fact is that for most everyday programming needs many (if not all)
programmers need just that - fast and unreliable integer arithmetic, not an
overspecified Common Lisp or Ada numerics or Scheme's number tower. And when
they do need the precisely defined number-crunching operations, they can surely
code them explicitly. 

I think that one of the faults of CL and like was to first overspecify some
features of the language and then depend on "sufficiently smart compilers" to
achieve good performance, instead of using more straightforwardly implementable
things as the language basis and then building on it with more (standard)
libraries and such.

Oleg
