Re: CL & Practicality

From: Adam Warner (usenet_at_consulting.net.nz)
Date: 10/08/03 

Date: Wed, 08 Oct 2003 14:10:42 +1300

Hi Tuang,

> That sounds right to me. While in theory I could write all my own
> libraries to do anything in any language, that would be a pretty
> impractical basis for comparing tools, and my question is about the
> practical advantage(s) of CL over Scheme for real (non-research)
> software projects.
>
> But then this brings up something I've frankly been wondering about.
> It's my understanding (and I'm posting to have my understanding
> corrected) that there are fewer than 1000 "operators" (I think they're
> called) in Common Lisp. That's probably about twenty times as many as
> there are in Scheme, but Java probably has more than twenty times as
> many as Common Lisp, depending on what you consider to be the equivalent
> of an operator.

You're conflating core language and core language+library issues but yes,
there are aspects of ANSI Common Lisp that could be improved through
portable definition of extra functionality (e.g. networking). Thus there
are a number of us who believe that ANSI Common Lisp is still too small
for optimum creation of portable code. De facto standards are helping to
fill in the gaps (e.g. BSD sockets).

Those who complain about the large size of the language are an amusement;
as are those who claim that the language should only provide one obvious
way to do something.

BTW it is just plain nonsense that Scheme should be the preferred option
for research/academic software projects instead of Common Lisp (at least
in all but a few well-defined areas, and even then defining a subset of
Common Lisp could be a suitable option).

> If the major practical advantage of CL over Scheme is the large amount
> of reusable, portable, free functions already built, debugged, and
> tested by others, then wouldn't a Scheme based on Java be even more
> practical than CL by that measure?

To obtain access to a wide set of de facto standard libraries this could
indeed be a reasonable approach. A Java Native Interface to Common Lisp
could also be a reasonable approach. I don't believe any is currently
available for a non-proprietary implementation of Common Lisp. Christopher
Double has made his JNI code for Corman Lisp freely available, which could
help if attempting to create your own interface:
<http://www.double.co.nz/cl/>

> (I realize that my original question was CL vs. Scheme, not CL vs.
> Scheme/Java, but it's not an academic or legalistic question. I'm
> looking for practicality for general-purpose programming projects.)

Lisp is also great for tackling the "hard" problems where library
availability will be the least of your concerns. I'll give you an example
how this can happen by accident. I have a numeric optimisation problem
that I thought was well-defined enough that Fortran would be a suitable
option, just for the raw speed. After a number of exploratory CMUCL
benchmarks I found CMUCL's general and floating point performance was good
enough when using appropriate declarations, non-descriptor representations
and block compilation to at least convince myself to use it for
exploratory work.

I later discovered I needed my functions to return multiple values to feed
hints to the custom optimiser. The return of multiple values is supported
by the language and CMUCL's "Python implements uses of multiple values
particularly efficiently. Multiple values can be kept in arbitrary
registers, so using multiple values doesn't imply stack manipulation and
representation conversion."

I've recently discovered that I need discrete, symbolic sets as a choice
option and I have to rewrite the optimiser to support this. Using macros I
may store the underlying representation of the symbolic sets as
non-descriptor arrays of types bit, (unsigned-byte 2), etc. if speed is
still an issue. I have also discovered that I need my agents to build
singly-linked lists of some decisions (in a way that it is not directly
amenable to representation as vectors).

Of course everything but the higher level abstractions could be achieved
in Fortran or any other (hopefully fast) general-purpose language. It's
just that the higher abstractions are important to be able to make
progress, debug the model and later be able to extend and rewrite the
model while still maintaining reasonable computational speed (and even in
places where CMUCL is poor, e.g. multidimensional arrays, I can build
macro abstractions upon one dimensional arrays).

> One counter argument I can imagine would be performance. From what I
> hear (and I'm mostly thinking about free implementations of all of
> these), no Java can compete with CMUCL for performance,

Some Java implementations are surprisingly fast for low-level
computations, I/O and (micro) benchmarks so this is a dangerous assumption
in general. But once you start using smart abstractions to hide complexity
and move computations to compile time you should be able to perform
convincingly better.

> and I'd guess that Scheme+Java would be even slower than pure Java
> (again, correct me if I'm wrong).

Not if you have a native implementation of Scheme or Lisp and interface to
Java (refer earlier comment).

> But then that changes the practicality argument for CL from getting more
> functionality to giving up some pre-built functionality (relative to a
> Scheme-on-Java) in exchange for higher performance.

What you've missed in this final comment is that Java is simply not as
practical for tackling hard problems that require a high level of
abstraction, and this is not a controversial characterisation. Java is for
"narrowly focused solutions that are tailored to a specific problem"
(Gilad Bracha, resident Computational Theologist at Sun Microsystems) and
attempts to improve the power of the language will be resisted: "I am
keenly aware of the drawbacks of such an approach, but I don't see it
changing very quickly."
<http://www.artima.com/weblogs/viewpost.jsp?thread=5246>
<http://groups.google.com/groups?selm=pan.2003.08.21.05.03.10.879996%40consulting.net.nz>

Tuang, the best way to discover the practicality of Common Lisp is to
begin coding.

Good luck,
Adam

Relevant Pages

  • Re: Lex, Yacc, and Lisp...
    ... Common Lisp specification. ... I have been involved both in implementing languages for Java and for Common Lisp. ... If you take a look around in the Java world what language extensions people are working on, and risk to take a look behind the scenes, you can tell that this is mostly the same everywhere. ...
    (comp.lang.lisp)
  • Re: SBCL is now faster than Java, as fast as Ocaml, and getting better
    ... times faster than Java, and is finally as fast as Ocaml. ... For purposes of propaganda, i.e. advocating Common Lisp, this is ... exactly the same ratio for each language. ... programming language in the Benchmarks Game?" ...
    (comp.lang.lisp)
  • Re: Lisp for enterprise computing?
    ... if your point is that java's newer features are clumsily integrated with the base language because they were bolted on afterwards, you'll get no argument from me. ... most programmers to understand than AMOP, and these are just *single* language features, and common lisp supports many more language features than java does out of the box, and even more by extension because common lisp is much more extensible ...
    (comp.lang.lisp)
  • Re: Lisp for enterprise computing?
    ... if your point is that java's newer features are clumsily integrated with the base language because they were bolted on afterwards, you'll get no argument from me. ... but I don't think that tutorial you pointed to is more difficult for most programmers to understand than AMOP, and these are just *single* language features, and common lisp supports many more language features than java does out of the box, and even more by extension because common lisp is much more extensible ...
    (comp.lang.lisp)
  • Re: How Common Lisp sucks
    ... necessities in today's world. ... getting acceptance of a considerable number of members in the Common Lisp community. ... Now you are apparently invoking a defacto standard. ... If we don't find a single example for changing the language in a fundamental way that would actually make the language easier to understand for newbies without loosing expressiveness, ...
    (comp.lang.lisp)