Re: ILC2005: McCarthy denounces Common Lisp, "Lisp", XML, and Rahul


I think I just managed to put my finger on an unacknowledged
fact that underpins this whole conversation.

There are two conflicting goals here.  The first and IMO most
fundamental is being able to write software that runs on and
takes full advantage of particular hardware and particular
OS's.  The second and if I understand you correctly IYO most
fundamental is being able to write software that does not depend
on particular hardware and particular OS's. To the extent that
a given hardware or OS provides capabilities which are unique,
and you want to take advantage of them, these are incompatible
goals.

The dangerous, grotty, binary stuff has to be done,
regardless.  If you want to take advantage of particular
hardware or a particular OS's capabilities, then one way
or the other, you have to get down in the mud with the pigs
and extend the Lisp implementation using a language that can
subvert the GC or typesafety or pick apart the pointers and
access the internal tables and read and write the typetags,
etc.

I think that Lisp is a reasonable and natural language for
doing this in; after all, creating language extensions is
in large part what Lisps are about.

You've been advocating a "chinese wall" approach, where access
to such capabilities is performed in an "implementation"
language, allowing the Lisp programming to be completely
abstract and generic.

Either way, good design principles require isolating the
grotty stuff at a low level and building abstractions from
"safe" building blocks;  I advocate that the isolation happen
just like any other abstraction level in program design,
and you advocate forcing the isolation by requiring it to
be done in a different source language.

I might go so far as to put the "dangerous" primitives in
a different section of the language manual, and require
some kind of "wheel" priveleges to check in code that uses
them, and use extraordinary measures in source control
systems to keep them isolated, track their use, and keep
them exclusively in the hands (and heads) of a relatively
few "system wizards."  I agree that they have to change
when the grotty binary stuff underneath them changes, and
ought to be marked in the manuals as being liable to change.
I agree even that *every* use of such primitives ought to
be a decision treated with seriousness and scrutiny by a
code review process.

But I don't buy that it is a good thing that there is
useful, necessary programming that can't be done in Lisp.

				Bear

.

Relevant Pages

  • Re: a dozen cpus on a chip
    ... No nontrivial language can ever be proven to be imposible to crash. ... compilers still available which implement ISO M2. ... It is a common misconception that Lisp is always interpretted. ... various X86 machines the hardware does exist that could allow the OS ...
    (sci.electronics.design)
  • Re: Why Lisp supposedly "sucks for game development"
    ... Lisp community. ... how low-level your language can go. ... tends to _almost_ match the hardware, ...
    (comp.lang.lisp)
  • Re: Why Lisp supposedly "sucks for game development"
    ... >> Lisp community. ... any extensible language will bring that "height". ... and build their hardware. ... I have no doubts that Lisp systems won't be able to squeeze ...
    (comp.lang.lisp)
  • Re: ILC2005: McCarthy denounces Common Lisp, "Lisp", XML, and Rahul
    ... was developed under the auspices of an authoritative organization I think it fell out of favour because of the nature of the language. ... I feel that Lisp is an organic language, if the above was attempted all that would happen is the mud would squeeze through your fingers. ... advantage of a particular hardware and OS. ... that there may be deficiencies in hardware and OS design (and could ...
    (comp.lang.lisp)
  • Re: ILC2005: McCarthy denounces Common Lisp, "Lisp", XML, and Rahul
    ... >> the language should be available to users. ... In the design of Common Lisp, I asked Dave Moon (one of the architects ... Now, there are good kinds of low-level, like the way that floats are ...
    (comp.lang.lisp)