Re: What are the domains that lisp doesn't fit int?

On Sat, 28 Apr 2007 02:16:32 +0200, Pascal Bourguignon
<pjb@xxxxxxxxxxxxxxxxx> wrote:

Dan Bensen <randomgeek@xxxxxxxxxxxxxx> writes:

fireblade wrote:
What are ... domains where lisp doesn't fit in?

Drivers: close to the metal.

If lisp worked perfectly well as system programming language on the
lisp machines, what does that say on the ability of lisp for writting
drivers?

It says that the Lisp machines had special hardware and kernel support
to make it work.


Common Lisp doesn't prevent an implementation to have implementation
specific extensions to be able to run on the bare metal, even on an
Intel processor. See Movitz.

True. But the need for extensions shows that standard CL cannot
support the application domain.

Movitz is a truly wonderful piece of software, but it is not quite the
showpiece for bare metal Lisp programming that you think it is. The
kernel runtime functions are not written in Lisp and their use
requires special knowledge in the compiler (which is, of course, not
dissimilar from any other implementation ... but that makes my point
for me). Additionally many of the drivers included with Muerte appear
to have been adapted from open source Linux versions rather than
written new to take advantage of Lisp.

Although new drivers written in Lisp can use the existing runtime
services, new runtime services cannot necessarily be written in Lisp.
Nor does the system as yet provide GC, it currently has only a very
rudimentary, allocate only, "mark no release" memory scheme for use in
kernel programming.

The Lisp machines, and to a lesser extent Movitz, show that CL can be
mated to and used successfully on a bare metal runtime package ... but
that has never been in dispute. In my book that's not the same as
saying CL can be used to program bare metal.


Embedding: Poor memory resources.

If lisp worked on systems of 50 years ago, what does that say on the
memory resources needed by lisp?

As you noted, this is mostly a straw man although I personally have
yet to see a Lisp that can operate in 4K. And the teeny
implementations I have seen were severely limited in functionality.

George
--
for email reply remove "/" from address
.

Relevant Pages

  • Re: LISPPA
    ... > memory resources. ... do in Common Lisp with code that runs about as fast. ... >> comparing Lisp with languages like C, Pascal and Basic, ... If by "visual programming" you mean the sort of ...
    (comp.lang.lisp)
  • Re: How Common Lisp sucks
    ... I could list some web servers written in Common Lisp. ... If a programming infrastructure fails ... underpinning than the p* languages. ...
    (comp.lang.lisp)
  • Re: LISPPA
    ... >> memory resources. ... > do in Common Lisp with code that runs about as fast. ... in "weaks languages": iteration instead of recursion and "local" ... I'm programming in Pascal since 1990 year, ...
    (comp.lang.lisp)
  • Re: Computer Algebra Algorithms
    ... If you want to learn CAS, learn lisp because that is what the ... The parser could be written in C or any other language. ... I would consider that such a minor aspect of a programming ... generally prefer righting there numeric algorithms in Maple and MATLAB ...
    (sci.math.symbolic)
  • Re: How Common Lisp sucks
    ... languages than there are jobs that require them as primary programming ... blog entries on Lisp. ... Lisp that sucks, ...
    (comp.lang.lisp)