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