Subject: Re: Core Lisp (was Re: cautios question (about languages)) From: Erik Naggum <erik@naggum.no> Date: 1999/07/30 Newsgroups: comp.lang.lisp Message-ID: <3142320224400283@naggum.no> * Chuck Fry | What's the difference between "proto-Lisp" and "Core Lisp"? No one has | so much as posted a hypothetical description of a Core Lisp, so where is | your basis for comparison? a proto-Lisp is very close to the compiler and the machine and has access to a lot of low-level stuff, like pointers, representational details of complex types, etc, and allows you to isolate them from the exported Lisp. as a Core Lisp has been described (by intended use), it would be a programming language in its own right, defining primitives upon which the rest of Common Lisp needs to be defined, but which are primitives and which need access to the machine is very hard to tell. CLOS could be defined entirely in a Common Lisp sans CLOS, but to make it perform well, you need a lot of access to lower-level stuff. efficient stream I/O is the same way, and the two combined really need special support to do well. | > this is wrong -- startup time is unaffected by total system size. | | Again, since no spec has been made available for comparison, I don't see | how one can draw a conclusion either way. by watching other systems, large and small, of course. size of the system has nothing to do with it. that is, other factors are so much more important that system size becomes completely irrelevant. | > haven't various people tried to produce a Core English already? | | What does that have to do with programming languages? if you ask hard enough questions, no answer about programming languages has to do with programming languages. take Kent's many philosophic, linguistic, and psychologic comments. they aren't about programming languages per se, but about people defining and using programming languages, and as long as we are human, that actually has strong merit. if we aren't considering humans, however, a lot more options become available in programming language design, and none of the lessons learned from other experiments involving languages and humans have any bearing on what we do. | Users have been screaming for a core + libraries architecture for years. | It's time we gave it to them. users have asked for features and extensions to Perl and C++, and that's what they got. I think the tobacco industry uses the same core argument. the good way is to give people what they need to be happy, not what they want. they want core + libraries, but that's not what they need, as every person who has set out to do this in the past have discovered. what they _do_ need is very hard to figure out as long as they keep thinking they need core + libraries. the problem is: when people _get_ core + libraries, they want languages with everything in them, because it's a terrible mess to deal with core + incompatible and overlapping libraries. let's take a good look at what core + libraries would solve, and let's at least pretend that core + libraries is not the solution. which _other_ ways to obtain the desiderata will we find in our search? #:Erik -- suppose we blasted all politicians into space. would the SETI project find even one of them?