Norvig's latest paper on Lisp

229 views
Skip to first unread message

Marc Battyani

unread,
May 17, 2002, 4:09:07 PM5/17/02
to
The "I dumped Java" thread made me think that I don't understand why some
people complain that Lisp is declining while I find it more and more usable
for real/commercial work.

The latest paper I've seen on the subject is from Peter Norvig (whose PAIP
was the book that made me come back to Lisp) :
http://www.norvig.com/Lisp-retro.html

In this paper he writes : "In 2002, the situation for Lisp is more bleak:
the language standard has stagnated, while other languages regularly add new
standards for protocols like HTTP, HTML, XML, SOAP..."

This looks just wrong to me. A quick look at CLiki gives several
possibilities for each protocol:
For HTTP there are AllegroServe, Araneida, CL-HTTP, HTTP dot LSP and
mod_lisp. (There are also some application frameworks like IMHO)

For HTML there are several HTML generation macros which are much more
powerful and easy to use than anything in any other language.

for XML there are also several possibilities.

The only one missing is SOAP but I bet we will see some library soon. (When
I find some time, I will put one with mod_lisp)

Should we choose one possibility for each protocol and put it in the
standard : Of course not.

There are also lots of libraries for SQL interfacing, regex, PDF generation,
graphics, etc...

There is also FLI/FFI that enables the use of C libraries.

So I don't see what is really missing today in Common Lisp for writing web
or X11/Win32 applications for instance.

It's obvious that some stuff should be standardized (like sockets, MP,
bivalent streams, etc...) but not these libraries.

I'm curious to see what people think about this particular subject.

Marc


Chris Beggy

unread,
May 17, 2002, 8:57:30 PM5/17/02
to
"Marc Battyani" <Marc.B...@fractalconcept.com> writes:

> Should we choose one possibility for each protocol and put it in the
> standard : Of course not.
>

I was surprised at his assessment, too.

Maybe he's suggesting that these should either be in the
standard, or in a central repository, like CPAN for perl.

> There are also lots of libraries for SQL interfacing, regex, PDF generation,
> graphics, etc...

Thanks for your mod_lisp for apache and your contributions to clsql.

> There is also FLI/FFI that enables the use of C libraries.
>
> So I don't see what is really missing today in Common Lisp for writing web
> or X11/Win32 applications for instance.
>
> It's obvious that some stuff should be standardized (like sockets, MP,
> bivalent streams, etc...) but not these libraries.
>
> I'm curious to see what people think about this particular subject.

Unless one considers elisp, I don't know about lisp for other
relatively standard things:

mail: smtp, lmtp, imap
news: nntp
messaging: snmp, irc, im, jabber
unix: shell utilities
ident: ldap
streams: mp3 codec
security: gpg, tls, ssl
char: unicode, utf-8, double-byte tools
files: ftp, nfs, afs

I'm sure many of these exist in lisp, but I don't know where. I
also know that these reflect a unix system administration viewpoint.

Chris

John Wiseman

unread,
May 17, 2002, 9:59:28 PM5/17/02
to
Chris Beggy <chr...@kippona.com> writes:

> mail: smtp, lmtp, imap

Franz' SMTP, IMAP and POP clients:
<http://opensource.franz.com/postoffice/index.html>.

Their code would probably almost work in other lisps with the
acl-compat stuff from the portable allegroserve project.


> news: nntp

> messaging: snmp, irc, im, jabber

IRC client, by Pierre Mai:
<http://www.pmsf.de/pmai/SillyIRC.html>

I know people have AIM client code in Lisp. I have one myself, I just
need to work out a licensing issue.

A jabber client would be really cool.


> unix: shell utilities

> ident: ldap

> streams: mp3 codec

> security: gpg, tls, ssl

> char: unicode, utf-8, double-byte tools

> files: ftp, nfs, afs

Franz' NFS server:
<http://opensource.franz.com/nfs/index.html>


John Wiseman

Chris Beggy

unread,
May 17, 2002, 10:39:32 PM5/17/02
to
John Wiseman <wis...@server.local.lemon> writes:

> Franz' SMTP, IMAP and POP clients:
> <http://opensource.franz.com/postoffice/index.html>.
>

> IRC client, by Pierre Mai:
> <http://www.pmsf.de/pmai/SillyIRC.html>
>

Thanks for these great links. Do you think Peter Norvig is aware
of all of these compatible implementations of standards?

Chris

Kenny Tilton

unread,
May 18, 2002, 2:19:51 AM5/18/02
to
> In this paper [Norvig] writes : "In 2002, the situation for Lisp is more bleak:

> the language standard has stagnated, while other languages regularly add new
> standards for protocols like HTTP, HTML, XML, SOAP..."

What rubbish. That is the same as comparing cars by their sound systems.
Lisp has survived for fifty years by doing language-level stuff Deeply
Right, not on the basis of handy interfaces to the Widget du Jour.

btw, the metrics Norvig uses--puh-leaze! He seems to think the herd
(amazon and newsgroup traffic) determines which languages prevail. I
guess we are all using COBOL and VSAM, right?

Everything is up in the air right now with PLs...Java, Perl, Python,
Ruby, yada yada yada with lotsa of the new folks distinguished most by
features copied from Lisp.

Calling a winner at this point is silly, folks should just shut up and
code.

:)

--

kenny tilton
clinisys, inc
---------------------------------------------------------------
"Harvey has overcome not only time and space but any objections."
Elwood P. Dowd

Mark Watson

unread,
May 18, 2002, 12:59:40 PM5/18/02
to
Hello Marc,

Several years ago, in an email to me, Peter Norvig was
talking about Java and AI and said something to the
effect "Java is half as good for AI as Lisp and
that is probably good enough". [rough quote]

He might be right, but substitute Python, Ruby,
etc. for Lisp and the "quote" probably still holds.

I share his frustration about no standards for
SOAP and XML-RPC however. I have spent some time
hacking around for crude SOAP support but I am
not so happy with the results, and I don't have
time work on this much anymore.

Still, I think that you and I agree that the
stability of Common Lisp is usually more important than
support for the latest APIs. That said, I find it
much easier to find people to pay me for Java coding than
Lisp :-(

I have experimented with developing with Mzscheme, and
then using Kawa to compile to Java byte codes; this combinaton
might work out well when you really have to "ship Java".

-Mark

-- Mark Watson, author and Java consultant
-- www.markwatson.com - Open Source and Open Content
-- www.knowledgebooks.com - Commercial artificial intelligence software

Marc Battyani wrote:
> The "I dumped Java" thread made me think that I don't understand why some
> people complain that Lisp is declining while I find it more and more usable
> for real/commercial work.
>
> The latest paper I've seen on the subject is from Peter Norvig (whose PAIP
> was the book that made me come back to Lisp) :
> http://www.norvig.com/Lisp-retro.html

> ........

John Wiseman

unread,
May 18, 2002, 2:42:28 PM5/18/02
to
Chris Beggy <chr...@kippona.com> writes:

> Thanks for these great links. Do you think Peter Norvig is aware of
> all of these compatible implementations of standards?

Well, I would think of those links more as places to start if you are
interested in whatever functionality they offer, not as drop-in
solutions--unless you happen to be using the lisp platform they were
developed for. If you're using another lisp, you simply are going to
have to do some hacking (generally speaking, and due to the use of
things like multiprocessing, sockets, etc.).

I think that might be the disadvantage that Norvig sees, and it is a
real one.


John Wiseman

Wade Humeniuk

unread,
May 18, 2002, 5:26:44 PM5/18/02
to

"Marc Battyani" <Marc.B...@fractalconcept.com> wrote in message
news:EEFC5F7E5C296C74.6CBC7F3B...@lp.airnews.net...

> In this paper he writes : "In 2002, the situation for Lisp is more bleak:
> the language standard has stagnated, while other languages regularly add new
> standards for protocols like HTTP, HTML, XML, SOAP..."
>

XML and SOAP are just attempts to implement what is already easy in Lisp. Lisp's uniform
syntax allows comparable functionality. Thus it is not neccesary to implement these
standards for communicating Lisp applications. It is only the other languages that need
this help. I find it no surprise that Lisp users are slow to use these protocols. If the
need arises to talk to other apps I certainly find myself wondering why go to all that
trouble, and it is trouble. Perhaps Lisp should step up and present itself as an
inter-language communication language, instead of these other syntaxes.

Wade

Chris Beggy

unread,
May 19, 2002, 1:02:43 AM5/19/02
to
John Wiseman <wis...@server.local.lemon> writes:

> Chris Beggy <chr...@kippona.com> writes:
>
>> news: nntp

Some nntp is here:

http://www.davep.org/lisp/

>
>> messaging: snmp, irc, im, jabber
>
> IRC client, by Pierre Mai:
> <http://www.pmsf.de/pmai/SillyIRC.html>
>
> I know people have AIM client code in Lisp. I have one myself, I just
> need to work out a licensing issue.
>
> A jabber client would be really cool.

I found snmp here:
http://www.switch.ch/misc/leinen/snmp/

Chris

Paolo Amoroso

unread,
May 19, 2002, 10:03:52 AM5/19/02
to
I already knew about Norvig's 1997 PAIP retrospective. A few days ago I
noticed the 2002 update, and I was meaning to privately send him some
comments. Since Marc started this thread in comp.lang.lisp, I decided to
publicly post my--lengthy, sorry--comments there and Cc: Norvig, so that he
can get a chance to watch the thread.


On Fri, 17 May 2002 22:09:07 +0200, "Marc Battyani"
<Marc.B...@fractalconcept.com> wrote:

> The latest paper I've seen on the subject is from Peter Norvig (whose PAIP
> was the book that made me come back to Lisp) :
> http://www.norvig.com/Lisp-retro.html

His book motivated me to study Common Lisp in more depth. At the time I
knew mostly Scheme.


> In this paper he writes : "In 2002, the situation for Lisp is more bleak:

I also found his statements surprising, inaccurate and possibly uninformed.
Although Norvig occasionally posts to comp.lang.lisp, I'm not sure whether
he regularly lurks here. It seems that he is not up to date with most of
what goes on in the Lisp community, at least the active part whose avenues
are project mailing lists, and often also this newsgroup.

I question both the usefulness of caring too much about popularity, and the
popularity metrics used by Norvig.

If the purpose of popularity is job security or availability of third party
tools and resources, then things are simple: just jump on the bandwagon of
one of the 2-3 most popular languages, i.e. Java, C++ and Perl according to
Norvig's figures (and the marketing resources behind Java are so huge that
its mere presence may "contaminate" the sample :) In this case there's no
point in comparing language features: just live with your mainstream tools.
The bandwagon attitude also seems to contradict what he wrote in his "Learn
Programming in 21 Days? Or 10 Years?" eaasy.

If we do insist with popularity, there may be other metrics missed by
Norvig. Franz, Inc., for example, was among the relatively few (according
to the event's program; I was not there) companies with a booth at a recent
OOPSLA, I think it was in 2000 or 2001.

Another possible example of Lisp's popularity is that it is being more or
less regularly mentioned in a mainstream Linux online publication, Linux
Weekly News, since last fall (see the Lisp entries in the
Development/Programming Languages section of past issues):

http://lwn.net

I have been "unofficially officially" contributing Lisp news to them since
then, and most of the news item get published (I can provide actual figures
if you are interested). And, of course, let's not forget the KMP interview
in Slashdot. Is this the kind of popularity for Lisp that Norvig is
interested in?

But is the kind of popularity that Norvig mentions in his paper a good
thing for Lisp in the first place? Is Lisp an appropriate language for the
same kind of audience of other popular languages?


> the language standard has stagnated, while other languages regularly add new

What Norvig calls "stagnation" may be considered maturity. The reason why
other language standards change more often may be that those languages are
less mature.

That said, it is still possible to have layered, community standards (and a
recent post suggests that such standards may be added to ANSI via a fast
track procedure). This is indeed happening with Franz's simple streams
(already available) and hierarchical packages (recently unofficially
announced).

It's no coincidence that such standards mostly come from a company, which
presumably can allocate resources to this as Sun is doing for Java (well,
to a "considerably greater" extent, actually...). But if other language
communities consider a reference implementation a standard, then there are
many such Lisp standards according to this definition.


> standards for protocols like HTTP, HTML, XML, SOAP..."

Marc and others have already mentioned Lisp implementations of such
standards. I only add that the best way of realizing about such work is to
subscribe to individual project mailing lists, especially those for CVS
commit logs.

I think that Norvig's claims about the alleged bleak situation of Lisp in
2002 are unfair to the many Lispers who work on commercial and open-source
projects, whose number is actually increasing, as closely watching the Lisp
community suggests.

To summarize my thoughts. If Norvig's popularity metrics are appropriate,
then other languages may surely win, hands down. After the worse is better
paper, this is hardly surprising.

If instead there's life--and business--beyond tha main stream, if the
absolute value of Lisp's market and community is acceptable and growing, as
other hints seem to suggest, then Lisp's situation is far from bleak.
Insisting that it is bleak may be a sort of self-fulfilling prophecy.


Paolo
--
EncyCMUCLopedia * Extensive collection of CMU Common Lisp documentation
http://www.paoloamoroso.it/ency/README
[http://cvs2.cons.org:8000/cmucl/doc/EncyCMUCLopedia/]

Peter Norvig

unread,
May 19, 2002, 11:48:56 AM5/19/02
to
Thanks for the comments on my retrospective update. I stand by my
conclusion "Lisp experts are still as productive as ever, but newer
programmers are less likely to pick up Lisp". I do agree with many of
the points made in this thread. I agree that most of the libraries do
exist somewhere, but the fact that they are not standardized makes the
language harder to use, especially for a non-expert. By "standardized"
I mean available from one canonical location in a form that is
portable across implementations; I don't care whether they are part of
an ANSI standard or not.

One thing I regret about my page is the emphasis on popularity. Of
course it is true that popular does not equate to better. And the
measures I cite were the ones that were available to me, and are not
the most scientific or useful. The only number that I think really
counts is number of jobs offered. Even that number is unreliable; I
know there are more than 4 openings for Lisp programmers.

I've updated my page to de-emphasize popularity and stress the
features that once made Lisp unique, and to incorporate some of the
points made in this thread. Now I want the take-home message to be
"Overall, Lisp does very well on the nine features. Anyone making an
objective choice based on these features would continue to find Lisp
the best choice for a wide range of applications. But there are now
viable contenders that did not exist in 1991." In other words, using
Lisp was a no-brainer in 1990, but now it depends on how you
prioritize a number of factors.

Here's a challenge for the Lisp community: give me the URL that I can
point to and say

"Lisp has a free, portable collection of libraries for threads, GUIs,
HTML, HTTP, XML, SOAP, and many other things available at ?????."

-Peter Norvig

Pierre R. Mai

unread,
May 19, 2002, 2:15:07 PM5/19/02
to
pe...@norvig.com (Peter Norvig) writes:

> Here's a challenge for the Lisp community: give me the URL that I can
> point to and say
>
> "Lisp has a free, portable collection of libraries for threads, GUIs,
> HTML, HTTP, XML, SOAP, and many other things available at ?????."

http://ww.telent.net/cliki

That should contain pointers to all available, free libraries for CL,
and if it doesn't, users/implementors can/should add them on their
own.

That doesn't fully address portable, since not all libraries are
currently portable or ported across the popular implementations.

However the situation is improving all the time. E.g. Kevin
Rosenberg's UFFI effort has unified FFIs for the popular
implementations, and he has taken MaiSQL to all those platforms in the
form of CLSQL, using UFFI. Merging the driver parts of UncommonSQL
(also derived from MaiSQL) with CLSQL is on the way, AFAIK, so that
shortly UncommonSQL+CLSQL should give you fairly powerful,
"standardized" access to RDBMSes across the board.

Regs, Pierre.

--
Pierre R. Mai <pm...@acm.org> http://www.pmsf.de/pmai/
The most likely way for the world to be destroyed, most experts agree,
is by accident. That's where we come in; we're computer professionals.
We cause accidents. -- Nathaniel Borenstein

Thomas F. Burdick

unread,
May 19, 2002, 4:24:31 PM5/19/02
to
Paolo Amoroso <amo...@mclink.it> writes:

> If instead there's life--and business--beyond tha main stream, if the
> absolute value of Lisp's market and community is acceptable and growing, as
> other hints seem to suggest, then Lisp's situation is far from bleak.
> Insisting that it is bleak may be a sort of self-fulfilling prophecy.

In fact, there's one potentially huge value in picking a language
that's strong, but not mainstream: if you insist on a mainstream
language, and you expect your code to be long-lived, you'll be
condemned to constantly rewriting it in the new language of the
decade. Look at Garnet->Amulet, for example. And if you don't want
to rewrite your code, you need to be prepared for the time when
today's langages de jour become has-beens. Like Pascal, Smalltalk, or
Lisp. When Java falls off, would you rather be stuck with
no-longer-mainstream Java or with no-longer-mainstream Lisp?

--
/|_ .-----------------------.
,' .\ / | No to Imperialist war |
,--' _,' | Wage class war! |
/ / `-----------------------'
( -. |
| ) |
(`-. '--.)
`. )----'

Bijan Parsia

unread,
May 19, 2002, 5:19:36 PM5/19/02
to
On 19 May 2002, Peter Norvig wrote:

[snip]


> the points made in this thread. I agree that most of the libraries do
> exist somewhere, but the fact that they are not standardized makes the
> language harder to use, especially for a non-expert. By "standardized"
> I mean available from one canonical location in a form that is
> portable across implementations; I don't care whether they are part of
> an ANSI standard or not.

[snip]

(I'm sure others will make this point, but...) Isn't this a rather hard,
er, standard? I mean, a single implementation language often gets
"portable across implementations" for free, there being only one
implementation.

And even there, there are typically loads of libraries that aren't
portable across platform ports. Look at Python on the mac and Python on
Windows.

Or look at Python vs. Jython
(see: http://www.jython.org/cgi-bin/faqw.py?req=show&file=faq04.001.htp)

I can speak better for Smalltalk (and perhaps the examples are
clearer): there are at least two implemenations (VisualWorks and
Squeak) that provide nearly all their facilities (including GUIs, sound,
networking etc.) identically across all the (many) platforms they
support. That is, not even a recompile is needed to work with the same
program on Mac, Windows, Linux, WinCE, etc. However, porting *between*
these two implementions/dialects can be a significant effort (depending on
what bits you use of each).

Python has 3-7 XML kits. Some are in the base image. Some are not. Some
require specific external parsers, some don't, some work with many,
etc. etc. etc. I've worked with several Python systems that depend on
specific versions of python (1.5.2, 1.6, 2.0, 2.1, 2.2, 2.2.1, etc.).

BTW, where is the canoncial Python SOAP implementation?

(Noting that SOAP is in a *fair* bit of flux at the moment and SOAP
interopt is still rather dicey.)

(SOAP 1.2 isn't even in final call working draft status yet, much less
Candidate recommendation or Recommendation. That is, there *is no SOAP
standard*. There's a W3C note for SOAP 0.9, but...)

Choice can make things harder to use. Thus, the wider range of
implementations, with different capabilities, might make Lisp harder to
use, but, one hopes, in a Good Way :)

Cheers,
Bijan Parsia.

Gabe Garza

unread,
May 19, 2002, 9:18:23 PM5/19/02
to
Bijan Parsia <bpa...@email.unc.edu> writes:

> On 19 May 2002, Peter Norvig wrote:
>
> [snip]
> > the points made in this thread. I agree that most of the libraries do
> > exist somewhere, but the fact that they are not standardized makes the
> > language harder to use, especially for a non-expert. By "standardized"
> > I mean available from one canonical location in a form that is
> > portable across implementations; I don't care whether they are part of
> > an ANSI standard or not.
> [snip]
>
> (I'm sure others will make this point, but...) Isn't this a rather hard,
> er, standard? I mean, a single implementation language often gets
> "portable across implementations" for free, there being only one
> implementation.

It's a hard standard, but it's a reasonable one. And, in my opinion,
the "but there's more then one implementation" answer is a fairly weak
excuse. Compare the convenience of downloading the standard Python
distribution from www.python.org and having, by default, libraries for
html, xml, whatever-the-latest-buzzcronym-is-ML, graphics, operating
system interfaces, database interfaces, etc. Compare this to
downloading one of the free Common Lisps, going to Cliki, going from
there to somebodies homepage, trying to build it, failing because
things that should be standard across implementations (FFI, sockets,
threads, etc.) aren't, and, if you haven't thrown up your hands yet,
fixing it to run on your implementation of choice.

If anything, the proliferation of free Common Lisp implementations is
a sign of fragmentation and wasted effort--we have communities
actively working on CMUCL, SBCL, CLISP, GCL, ECLS, and OpenMCL.
Imagine what we'd have if the free Common Lisp community picked one
implementation, and vested all their efforts into improving it and
writing libraries for it. Considering that it takes a lot of work to
write and maintain a Common Lisp implementation, and we'd have free'd
up the resources to required to maintain 5 of them, I'd bet we'd even
get some damn nice libraries.

But, realistically, this is never going to happen. This is painfully
ironic, because (correct me if I'm wrong--I was 5 when X3J13 was
formed and may not be at all clued in on its original purpose) the
whole point of *COMMON* Lisp was to get a whole bunch of different
groups working on increasingly divirgent Lisp dialects to standardize.

Consider these observations and not requests. I'm very grateful to the
CMUCL developers for continuing to maintain a superb product. I'm
pretty happy with using CMUCL for my own personal projects and
LispWorks for the *very* rare occaisons when I get to use it at work.
Short of unrealistic dreams of Lisp becoming a mainstream language and
being able to easily find a job using it, I'm fairly happy with what
Lisp is giving me now.

Please don't interpret this as bashing the free Common Lisp community
as a whole, either. Writing and maintaining robust software is hard
work, and I absolutely appreciate the free Lisp software that I use.
It's just that I really love Lisp, and I don't think thumping our
chests and gazing pridefully upon a crazy-quilt of implementations and
uncoordinated effort is going to move it that far from where it is
now.

Gabe Garza

Christopher Browne

unread,
May 19, 2002, 9:29:05 PM5/19/02
to
Bijan Parsia <bpa...@email.unc.edu> wrote:
> On 19 May 2002, Peter Norvig wrote:
> [snip]
>> the points made in this thread. I agree that most of the libraries do
>> exist somewhere, but the fact that they are not standardized makes the
>> language harder to use, especially for a non-expert. By "standardized"
>> I mean available from one canonical location in a form that is
>> portable across implementations; I don't care whether they are part of
>> an ANSI standard or not.
> [snip]

> (I'm sure others will make this point, but...) Isn't this a rather
> hard, er, standard? I mean, a single implementation language often
> gets "portable across implementations" for free, there being only
> one implementation.

The fact that it's not easy doesn't make this an unacceptable standard
to hope for.

An important assumption throughout the CL standard is that quite a lot
of details are thrust at implementation since there will be relatively
few implementors in comparison with the number of folks _using_ the
implementations.

> Python has 3-7 XML kits. Some are in the base image. Some are not. Some
> require specific external parsers, some don't, some work with many,
> etc. etc. etc. I've worked with several Python systems that depend on
> specific versions of python (1.5.2, 1.6, 2.0, 2.1, 2.2, 2.2.1, etc.).
>
> BTW, where is the canoncial Python SOAP implementation?
>
> (Noting that SOAP is in a *fair* bit of flux at the moment and SOAP
> interopt is still rather dicey.)

I can be as authoritative on that as anyone can be; there are only two
implementations for Python worth speaking of, neither being totally
satisfactory, in different ways; only one, ZSI, is being actively
worked on anymore. But there are simple samples that it doesn't work
with. (I filed a bug report on this _tonight_, so I have some clue on
this :-).)
--
(reverse (concatenate 'string "gro.gultn@" "enworbbc"))
http://www.cbbrowne.com/info/languages.html
Eagles may soar, free and proud, but weasels never get sucked into jet
engines.

Bijan Parsia

unread,
May 20, 2002, 9:18:52 AM5/20/02
to
On Mon, 20 May 2002, Gabe Garza wrote:

> Bijan Parsia <bpa...@email.unc.edu> writes:
>
> > On 19 May 2002, Peter Norvig wrote:
> >
> > [snip]
> > > the points made in this thread. I agree that most of the libraries do
> > > exist somewhere, but the fact that they are not standardized makes the
> > > language harder to use, especially for a non-expert. By "standardized"
> > > I mean available from one canonical location in a form that is
> > > portable across implementations; I don't care whether they are part of
> > > an ANSI standard or not.
> > [snip]
> >
> > (I'm sure others will make this point, but...) Isn't this a rather hard,
> > er, standard? I mean, a single implementation language often gets
> > "portable across implementations" for free, there being only one
> > implementation.
>
> It's a hard standard, but it's a reasonable one.

Then it need to be fairly applied (or better stated). How portable is code
between Python and Jython? Between Python 1.5.1 and Python 2.2? Why
*can't* we compare apples with apples (i.e., implementations with
implementations)?

I'm not saying that Lisp doesn't have (e.g., marketing) problems because
of it's multi-implementation situation, but I want to know what the *real*
problem is. That you can't port your code between implementations easily
seeems like an *odd* point. How easy is it to port Perl DOM code to
Python? (Which level DOM?)

> And, in my opinion,
> the "but there's more then one implementation" answer is a fairly weak
> excuse. Compare the convenience of downloading the standard Python
> distribution from www.python.org and having, by default, libraries for
> html, xml, whatever-the-latest-buzzcronym-is-ML, graphics, operating
> system interfaces, database interfaces, etc.

I do. I currently have three Python distributions on my hard drive and now
half to download another because a library I'm using (Redfoot) wants
veriosn 2.2.2 or some such.

> Compare this to
> downloading one of the free Common Lisps, going to Cliki, going from
> there to somebodies homepage, trying to build it, failing because
> things that should be standard across implementations (FFI, sockets,
> threads, etc.) aren't, and, if you haven't thrown up your hands yet,
> fixing it to run on your implementation of choice.

If it's a problem of the free versions that's one thing. It's always open
for me to get one of the commercial ones and several of those are
reasonably complete.

> If anything, the proliferation of free Common Lisp implementations is
> a sign of fragmentation and wasted effort--we have communities

Well here's a something it *could* be a sign of: healthy diversity :) With
healthy diversity comes some other issues.

> actively working on CMUCL, SBCL, CLISP, GCL, ECLS, and OpenMCL.
> Imagine what we'd have if the free Common Lisp community picked one
> implementation, and vested all their efforts into improving it and
> writing libraries for it. Considering that it takes a lot of work to
> write and maintain a Common Lisp implementation, and we'd have free'd
> up the resources to required to maintain 5 of them, I'd bet we'd even
> get some damn nice libraries.

Evidently this doesn't serve the needs and desiers of various people,
indeed, the ones actually writing code. What needs would be *neglected* in
the alternative paradise you paint?

> But, realistically, this is never going to happen. This is painfully
> ironic, because (correct me if I'm wrong--I was 5 when X3J13 was
> formed and may not be at all clued in on its original purpose) the
> whole point of *COMMON* Lisp was to get a whole bunch of different
> groups working on increasingly divirgent Lisp dialects to standardize.

On a *base*. It's not clear how things are going to shake out on MOST of
the things on Norivg's list.

> Consider these observations and not requests.

Sure. I agree with some but mostly disagree with the conclusions you
draw. Some of Norvig's complaints seem to be promulgating a *bit* of a
myth, IMHO. Or, at least, based on something of a double standard with a
much more critical eye directed toward Lisp than, e.g., Python.

I speak as someone who's spent a fair bit of time writing Python code and
followng the community and using its standard library. Often the stdlib is
more promise than reality, IMHO.

> I'm very grateful to the
> CMUCL developers for continuing to maintain a superb product. I'm
> pretty happy with using CMUCL for my own personal projects and
> LispWorks for the *very* rare occaisons when I get to use it at work.
> Short of unrealistic dreams of Lisp becoming a mainstream language and
> being able to easily find a job using it, I'm fairly happy with what
> Lisp is giving me now.

Heh. Indeed. That's good.

> Please don't interpret this as bashing the free Common Lisp community
> as a whole, either. Writing and maintaining robust software is hard
> work, and I absolutely appreciate the free Lisp software that I use.
> It's just that I really love Lisp, and I don't think thumping our
> chests and gazing pridefully upon a crazy-quilt of implementations and
> uncoordinated effort is going to move it that far from where it is
> now.

Well, I don't *think* that's what I was doing.

I'm curious that you ignored all the details of my argument, and
especially the comparison with the situation in Smalltalk land. I think my
*real* point is that portability across dialects of every unfinished spec
roaming the land might not be the real solution to
whatever-the-problem-actually-is.

Cheers,
Bijan Parsia.

Bijan Parsia

unread,
May 20, 2002, 9:29:54 AM5/20/02
to
On 20 May 2002, Christopher Browne wrote:

> Bijan Parsia <bpa...@email.unc.edu> wrote:
[snip]


> The fact that it's not easy doesn't make this an unacceptable standard
> to hope for.

Of course not. I surely didn't say anything to the contrary (or even imply
any such thing). But if we're trying to be clear eyed about the situation
and possible solutions we, well, should be clear eyed :)

For example, wouldn't it "solve" the Python-competation problem for a
group of developers to rally around, say, CLisp and focus on making it
feature/bug competative with Python? Why *must* CLers solve the much
harder problem of making ALL implementations "Python competative"? Yet,
afaict, this is what Norvig calls for.

> An important assumption throughout the CL standard is that quite a lot
> of details are thrust at implementation since there will be relatively
> few implementors in comparison with the number of folks _using_ the
> implementations.

Sure. Uh. Ok. I'm not clear what this has to do with the current situation
:) Other important assumptions are that some things are *left* to
implemenations and that a posteriori standardization is good.

> > Python has 3-7 XML kits. Some are in the base image. Some are not. Some
> > require specific external parsers, some don't, some work with many,
> > etc. etc. etc. I've worked with several Python systems that depend on
> > specific versions of python (1.5.2, 1.6, 2.0, 2.1, 2.2, 2.2.1, etc.).
> >
> > BTW, where is the canoncial Python SOAP implementation?
> >
> > (Noting that SOAP is in a *fair* bit of flux at the moment and SOAP
> > interopt is still rather dicey.)
>
> I can be as authoritative on that as anyone can be; there are only two
> implementations for Python worth speaking of, neither being totally
> satisfactory, in different ways;

Right, so forget Lisp for a moment: *Python* doesn't meet Norvig's
criterion!! This makes me think that there's primarily a perception issue
at hand.

> only one, ZSI, is being actively worked on anymore. But there are
> simple samples that it doesn't work with. (I filed a bug report on
> this _tonight_, so I have some clue on this :-).)

[snip]

Indeed, this is as I suspected.

So, there are at least two points of criticism I meant to raise about
Norvig's criteria: 1) it's not clear that Python passes it, and 2) it's
not clear that one has to have cross-implemenation portability of every
little thing to be properly competative with Python and the like. Maybe a
third: It probably doesn't help to make things artifically harder :)

(And *of course* we'd all prefer to be able to have a wider range of
portable programs, so that we can pick and choose which implementation to
develop/deploy our programs based on nothing more than our whims. I
suspect that people in single implementation langauge communities tend to
move between *languages* (e.g., Python, Perl, Ruby, Tcl) the way Lisper &
Smalltalkers & Prologgers move between implemenations and dialects.)

Cheers,
Bijan Parsia.

Gabe Garza

unread,
May 20, 2002, 10:37:13 AM5/20/02
to
Daniel Barlow <d...@telent.net> writes:

> Gabe Garza <g_g...@ix.netcom.com> writes:
>
> > If anything, the proliferation of free Common Lisp implementations is
> > a sign of fragmentation and wasted effort--we have communities
> > actively working on CMUCL, SBCL, CLISP, GCL, ECLS, and OpenMCL.
> > Imagine what we'd have if the free Common Lisp community picked one
> > implementation
>

> A lot of very bored people and a general stagnation of development.

There should be more to Common Lisp then just the glamorous parts,
like the compiler. You also need libraries to have a truly usable
system. These are often boring to write, but every bit as necessary
as the interesting parts of the system if one is to write useful code.
Python has no shortage of developers willing to contribute to the
boring parts, and hence has plenty of libraries, is very useful, and
has a growing user base.

> Nowhere to go if you want to experiment with new things that would
> make the code unstable

Of course there'd be somewhere to go: the "One" implementation.
Download the source, do what you want with it. Is their a current
distribution I don't know of that's accepting of unstable code
or something?

> No choice of implementations with different design goals for size,
> speed, ANSI compatibility, extra-ANSI extensions, safety (I trust you
> will agree that these are conflicting goals)

I completely *disagree* that these are conflicting goals.

Size vs. Speed: LispWorks has a pretty robust compiler, but also has a
tree shaker that can produce reasonably sized executables. Recently
there's been some interesting work building smaller CMUCL cores--and
CMUCL is damn fast.

ANSI vs. Extensions: One of the points of Lisp is that it's the
"programmable programming language." It's *designed* to be extended,
and it's easy to extend it without damaging compatibility. You just
put your extensions in a package other then COMMON-LISP. If your
extensions involve modifications to the readtable, then include a
function to enable and disable them.

Safety: Again, one of the nice things about Lisp is that you can have
either safety or speed. Existing implementations give you this
already (e.g., (declare (optimize (speed 3) (safety 0))) gives *VERY*
different code then (declare (optimize (speed 0) (safety 3))) in
CMUCL). I don't know why you listed this as a conflicting goal--I
apologize if I'm misunderstanding your point. I'm sure you'll correct
me if I am. :)

> No chance to use an implementation with more-or-less onerous
> licensing conditions. (I may not want to extend CLISP if my changes
> must be GPLed; the CLISP maintainers may not want to extend some other
> Lisp if it means that anyone can take their changes and incorporate it
> into proprietary products)

I'll agree that licensing would be a major sore point. But then again,
CLISP is the only GPL'd free distribution I know of, and I don't think
GPL was the developers first choice of license...

> Really, it doesn't sound like a win.

Frankly, even if all your dire predictions were true (and I don't think
this is so), I'd be willing to put up with a less robust core
system (as long as it wasn't GPL'd...) if it meant having a large set
of usable libraries.

> > writing libraries for it. Considering that it takes a lot of work to
> > write and maintain a Common Lisp implementation, and we'd have free'd
> > up the resources to required to maintain 5 of them, I'd bet we'd even
> > get some damn nice libraries.
>

> This might be true. If, that is, you completely ignore all the social
> factors involved and consider free software developers as
> interchangeable "resources" who will work on whatever you direct them
> to work on.

I don't, which is precisely why I say it will never happen in a latter
(unquoted) paragraph. Lots of boring code just isn't going to be
written. I'm not going to write it (at least for free), and someone
else probably isn't going to write it either. There's an even smaller
chance that a team of people will get together to put together a
powerful and coherent system (at least for free).

And, again, I'm not complaining. I'm happy with CMUCL. I just don't
think it's fair to lament the success of languages that have more
practical immediate uses (like Python)--largely due to being single
distributions with tons of libraries--when Lisp has obvious and easily
identifiable shortcomings in this area.

Gabe Garza

Daniel Barlow

unread,
May 20, 2002, 11:42:00 AM5/20/02
to
Gabe Garza <g_g...@ix.netcom.com> writes:
[...]

I started writing a very long response to your article, but I think I
can summarize by saying: as long as the cost of communication is
non-zero, different development communities with different priorities
will form. Even supposing they all start from the same code base, it
would be somewhere in the range (very difficult, physically
impossible) to keep the branches from proceeding at different speeds
and in different directions.

You have to fix the pressures that push people to split before you can
say "splitting is a bad thing". If not splitting means you can't
solve the problems that you set out to solve, then clearly splitting
is a less bad thing.

In short, develop a instantaneous direct mind link and then we'll talk
again ;-) In the absense of such, ragging on free Lisp developers for
being wasteful is like ragging on legs for being overmuscled because
we wouldn't need all that strength if only the Earth had 1/6th normal
gravity.

> And, again, I'm not complaining. I'm happy with CMUCL. I just don't
> think it's fair to lament the success of languages that have more
> practical immediate uses (like Python)--largely due to being single
> distributions with tons of libraries--when Lisp has obvious and easily
> identifiable shortcomings in this area.

I agree with that bit. After all, I created CLiki mostly in order to
encourage the development (and visibility) of free libraries.
However, what you _said_ was

> If anything, the proliferation of free Common Lisp implementations is
> a sign of fragmentation and wasted effort

which is what I was objecting to


-dan

PS That may well be the first time I've heard anyone describe compiler
development as glamorous. I believe it's usually kernel hackers who
get the supermodels

--

http://ww.telent.net/cliki/ - Link farm for free CL-on-Unix resources

Mark Watson

unread,
May 20, 2002, 12:02:33 PM5/20/02
to
Gabe Garza wrote:

> If anything, the proliferation of free Common Lisp implementations is
> a sign of fragmentation and wasted effort--we have communities
> actively working on CMUCL, SBCL, CLISP, GCL, ECLS, and OpenMCL.
> Imagine what we'd have if the free Common Lisp community picked one
> implementation, and vested all their efforts into improving it and
> writing libraries for it. Considering that it takes a lot of work to
> write and maintain a Common Lisp implementation, and we'd have free'd
> up the resources to required to maintain 5 of them, I'd bet we'd even
> get some damn nice libraries.


It is interesting to be a historian for a while :-)

Probably, Smalltalk lost out to Java because of
licensing issues with Smalltalk (vendor problems
with Smalltalk, Java was 'free', etc.)

Sadly, I think that the large scale adoption of Lisp
could have happened if a few things had been different:

1. CLisp would have had a BSD or LGPL style license, or
was licensed like Swi-Prolog is now (GPL with a waiver
for cmmercial development).

2. If we had a commercial product like LispWorks Professional
15 years go. I remember at SAIC, my bosses liked how
quickly demos could be cranked out in Interlisp on my
old 1108 box, but there were not good deployment options.
Now, a product like LispWorks allows for free runtime
distribution on Windows and Linux - what I needed 15
years ago :-(

CLisp is very fine for development and I defend
Bruno Haible, Michael Stoll, Marcus Daniels,
Pierpaolo Bernardi, and Sam Steingold's right
to choose the kind of license they want for their
fine work (Sam makes great arguments for the
GPL license, BTW). For the entire Lisp
community however, I think that CLisp with
a more liberal license would end up being
the standard Lisp environment, and more people would
work on extending it.

Bijan Parsia

unread,
May 20, 2002, 12:12:11 PM5/20/02
to
On Mon, 20 May 2002, Mark Watson wrote:

[snip]


> It is interesting to be a historian for a while :-)

Let the revisionism begin!

> Probably, Smalltalk lost out to Java because of
> licensing issues with Smalltalk (vendor problems
> with Smalltalk, Java was 'free', etc.)

Er..this presumes that Smalltalk and Java were, in any sane way,
competiters for some "thing".

There were free Smalltalks available (Little Smalltalk, GNU Smalltalk).

Arguably, the Smalltalk community -- certainly several vendors -- damaged
themselves by trying to "beat" Java.

> Sadly, I think that the large scale adoption of Lisp
> could have happened if a few things had been different:

Ok, we're *way* beyond history and into speculation :) Fun, but not
necessarily productive.

> 1. CLisp would have had a BSD or LGPL style license, or
> was licensed like Swi-Prolog is now (GPL with a waiver
> for cmmercial development).

Really? If CLisp had had non-GPL licencing 5 years ago it would have beat
out Java?!?!

Ok, I'm reading a bit more into what you said than you actually said
:) But what's your supporting evidence? Java had TONS of money (tons, it
really can't be stressed how much money Java had), loads of good will
(almost as much as it had money), good press, a HUGE company pimping it
everywhere, the negative vibes against Microsoft, etc. etc. etc.

And it will probably "lose" to C# :)

[snip]

If a mere, tiny licence change to CLisp would have made Lisp "huge" then
we should all strongly bash the CLisp developers and all the people in the
community who didn't get enough money together to make them change it (or
to produces something equivalent with the right licence).

I just don't believe it. Not a whit.

Both your conditions seem more "What Lisp would have had to have done in
order for *YOU* to have been using it all this time, for most
everything." That's perhaps useful information, but let's not generalize
*too* quickly here :)

Cheers,
Bijan Parsia.

Michael Hudson

unread,
May 20, 2002, 12:55:15 PM5/20/02
to
Gabe Garza <g_g...@ix.netcom.com> writes:

> Python has no shortage of developers willing to contribute to the
> boring parts,

This is not true!

Cheers,
M.

--
Considering that this thread is completely on-topic in the way only
c.l.py threads can be, I think I can say that you should replace
"Oblivion" with "Gravity", and increase your Radiohead quotient.
-- Ben Wolfson, comp.lang.python

Kenny Tilton

unread,
May 20, 2002, 3:36:55 PM5/20/02
to

Peter Norvig wrote:
> One thing I regret about my page is the emphasis on popularity.

...


> Here's a challenge for the Lisp community: give me the URL that I can
> point to and say
>
> "Lisp has a free, portable collection of libraries for threads, GUIs,
> HTML, HTTP, XML, SOAP, and many other things available at ?????."

That still emphasizes popularity.

BTW, show me a URL to a Python with good GC, macros, C+20% performance,
generic methods, special variables, an ANSI standard, and which has the
stability of a forty-plus year old language.

Now which is harder, whipping up interfaces to the latest toys or
finishing Python?

Raymond Toy

unread,
May 20, 2002, 4:38:54 PM5/20/02
to
>>>>> "Bijan" == Bijan Parsia <bpa...@email.unc.edu> writes:

Bijan> On Mon, 20 May 2002, Mark Watson wrote:
>> 1. CLisp would have had a BSD or LGPL style license, or
>> was licensed like Swi-Prolog is now (GPL with a waiver
>> for cmmercial development).

[snip]

Bijan> If a mere, tiny licence change to CLisp would have made Lisp "huge" then
Bijan> we should all strongly bash the CLisp developers and all the people in the
Bijan> community who didn't get enough money together to make them change it (or
Bijan> to produces something equivalent with the right licence).

Bijan> I just don't believe it. Not a whit.

Indeed!

CMUCL is truly public domain so could gather it up and do whatever you
wanted to it, including making it proprietary.

CMUCL hasn't made Lisp a big hit either.

Ray

Gabe Garza

unread,
May 20, 2002, 9:39:40 PM5/20/02
to
Kenny Tilton <kti...@nyc.rr.com> writes:
> BTW, show me a URL to a Python with good GC, macros, C+20% performance,
> generic methods, special variables, an ANSI standard, and which has the
> stability of a forty-plus year old language.
>
> Now which is harder, whipping up interfaces to the latest toys or
> finishing Python?

Yeah, Lisp is the greatest language in the world. No one here, myself
included, is going to disagree with you.

That doesn't change the fact that, to many users, those things are all
completely irrelevant if they can't easily open a socket, connect to a
database, spawn a process, stat a file, open a pipe, send a datagram,
throw a window on the screen, match a string against a regular
expression, encrypt a string, use the syslog facility, parse CGI
environment variable values, parse urls, send mail, read mail, send a
file via ftp, read a file via ftp, start an nntp session, parse an xml
file, manipulate image files, manipulate sound files, ...

Different people are going to judge languages based on different sets
of criteria. Lisp is tops by my criteria, but only because I know
enough about computers to either roll my own support for the above if
I have to or write ffi bindings. Could you honestly recommend Lisp to
someone to whom being able to easily do some of those things was
important? What about someone who was just begining to program, but
needed to be able to write useful programs fairly soon?

If you want Lisp to appeal to more people--and I'm not saying that you
should, or that I do, or that it's even a worthy goal--there are more
helpful things then being disdainful of criticism (and it was actually
pretty *light* criticism).

Gabe Garza

Kenny Tilton

unread,
May 20, 2002, 11:25:27 PM5/20/02
to

Gabe Garza wrote:
>
> there are more

> helpful things then being disdainful of criticism...

Look, the criticism sucks, what can I do? :)

There are two questions. (a) How good is a language? (2) How much glue
is there to today's hot toys? All this yammering lumps the two together.
That is a godawful mistake. Good languages are hard, glue is easy. Also,
popularity generates glue as much as glue generates popularity. if glue
is your design goal you should end up with glue but unless you are
extending CL the language invented to provide the glue will likely be a
slow, unstable hack in need of years of refinement.

the criticism reaches for finality based on a few years' history.
"Wouldn't it be great if CL had seamless access to VSAM, JCL, RMS, DCL,
and Pascal?!" oops... what is that rule of thumb about how long one has
to wait before writing the history of something? What really gives me a
pain where I sit is folks like Norvig and Graham pulling their chins and
pronouncing "what's wrong" with a language which kicked ass before they
had written a line of code and will continue to kick ass long after they
are pushing up daisies, all because of a little excitement this week (in
geological time) over a few toy languages.

This is like dissecting the general manager's off-season trades when the
division leader loses five games in a row.

If they are through with CL, fine, they can have Python or Arc and leave
CL to the young tigers who are picking up the flag. I just wish they'd
spare us the lame 30-second-history parting shots at the language that
made them.

:)

Here is what would be helpful: if the fanatics sawing away at extending
Python, Perl and Ruby would close up shop and learn CL. Helpful also
would be Graham or Norvig coding up the CL interfaces they miss. Helpful
in actuality are the people starting to share CL stuff.

Bruce Hoult

unread,
May 20, 2002, 11:37:35 PM5/20/02
to
In article <3CE9BFDD...@nyc.rr.com>,
Kenny Tilton <kti...@nyc.rr.com> wrote:

> Here is what would be helpful: if the fanatics sawing away at extending
> Python, Perl and Ruby would close up shop and learn CL.

That's not going to happen as long as people with experience in said
languages (and other not mentioned, such as Smalltalk, Dylan, Scheme,
OCaml) who come to this newsgroup get as chilly a reception as they do
at present.

-- Bruce

Neil Schemenauer

unread,
May 20, 2002, 11:51:31 PM5/20/02
to
Kenny Tilton <kti...@nyc.rr.com> wrote:
> BTW, show me a URL to a Python with good GC, macros, C+20%
> performance, generic methods, special variables, an ANSI
> standard, and which has the stability of a forty-plus year old
> language.

Which one of those things are required for writing, for example,
a simple web server? You can do it in Python using a few lines
of code. The same code will work with Jython was well. How
many lines of CL does it take?

Yes, the GC in sucks. I know. I wrote it. Yes, Python is
agonizingly slow when compared to C++ or compiled CL. You know
what else? It doesn't matter. Python gets the job done. It's
got a large, well documented stardard library. It's got a free,
very portable, fairly bug free implementation. It plays well
with other languages and libraries.

> Now which is harder, whipping up interfaces to the latest toys or
> finishing Python?

Harder is not the question. The question is will anyone do it?
Lots of CL users seem to have the attitude that CL is king and
all other languages are inferior. They seem to think that no
advancement of the language is necessary. The ANSI CL standard
was an awesome technical feat but progress cannot stop there. A
standard network socket interface would be nice, for example. Is
the CL community working on one?

I feel sad. CL is a great language. However, if it doesn't grow
its standard library (even if it's only a de facto standard) then
it's going to eventually die. The community needs to realize
this and start working on it. Denying the problem does not help.

Neil

John Wiseman

unread,
May 21, 2002, 12:20:56 AM5/21/02
to
Kenny Tilton <kti...@nyc.rr.com> writes:

> There are two questions. (a) How good is a language? (2) How much
> glue is there to today's hot toys? All this yammering lumps the two
> together.

Yes, and I think Norvig did a good job of describing what the issues
were, and keeping them separate. Both are pretty important when you
want to write code.

I just noticed this, and it's kinda relevant, so I'll quote Paul
Graham (<http://www.paulgraham.com/icad.html>):

As for libraries, their importance also depends on the
application. For less demanding problems, the availability of
libraries can outweigh the intrinsic power of the language. Where is
the breakeven point? Hard to say exactly, but wherever it is, it is
short of anything you'd be likely to call an application. If a
company considers itself to be in the software business, and they're
writing an application that will be one of their products, then it
will probably involve several hackers and take at least six months
to write. In a project of that size, powerful languages probably
start to outweigh the convenience of pre-existing libraries.

I think the following statement is hard for anyone in comp.lang.lisp
to deny (but I sure expect to be surprised):

Lisp is definitely a better language than most (though it's not as far
ahead as it once was) and the state of lisp libraries is definitely
not as good as that of many other languages.

Let's just admit it's a problem (for some, maybe not for everyone) and
work on it.

Actually, people are *working* on the problem of making it easy to
create, distribute, find and install lisp libraries right now--the
Comprehensive Common Lisp Archive Network (CCLAN) is developing the
required infrastructure, which is a lot of work.

There's also the issue of writing good, portable libraries, which is a
lot of work. I believe that common interfaces for sockets and threads
(and maybe user-extensible streams) would make it *much* easier to
write portable versions of a certain class of library that happens to
be popular right now.

For myself, I'm close to deciding that anything I write will use the
APIs for these things as defined by Allegro Common Lisp, mostly
because they're the best I've seen, but also because it seems like
there's some movement toward accepting them as de facto standards
(E.g., OpenMCL's implementing the ACL socket API, the Portable
AllegroServe project's acl-compat files, maybe even some recent cmucl
and sbcl development.)


John Wiseman

Thien-Thi Nguyen

unread,
May 21, 2002, 12:33:31 AM5/21/02
to
Kenny Tilton <kti...@nyc.rr.com> writes:

> Helpful in actuality are the people starting to share CL stuff.

sharing was around even before CL, dude.

thi

Kenny Tilton

unread,
May 21, 2002, 1:38:36 AM5/21/02
to

? You must have misparsed my godawful sentence.

Kenny Tilton

unread,
May 21, 2002, 1:44:13 AM5/21/02
to

Bruce Hoult wrote:
>
> In article <3CE9BFDD...@nyc.rr.com>,
> Kenny Tilton <kti...@nyc.rr.com> wrote:
>
> > Here is what would be helpful: if the fanatics sawing away at extending
> > Python, Perl and Ruby would close up shop and learn CL.
>
> That's not going to happen as long as people with experience in said

> languages ... who come to this newsgroup get as chilly a reception

I have heard that theory before, but I am not sure it holds water. I try
to imagine myself getting stoked over some new language but then
abandoning it because of a feisty NG... nahhhh.

Bruce Hoult

unread,
May 21, 2002, 1:57:13 AM5/21/02
to
In article <3CE9E003...@nyc.rr.com>,
Kenny Tilton <kti...@nyc.rr.com> wrote:

> Bruce Hoult wrote:
> >
> > In article <3CE9BFDD...@nyc.rr.com>,
> > Kenny Tilton <kti...@nyc.rr.com> wrote:
> >
> > > Here is what would be helpful: if the fanatics sawing away at extending
> > > Python, Perl and Ruby would close up shop and learn CL.
> >
> > That's not going to happen as long as people with experience in said
> > languages ... who come to this newsgroup get as chilly a reception
>
> I have heard that theory before, but I am not sure it holds water. I try
> to imagine myself getting stoked over some new language but then
> abandoning it because of a feisty NG... nahhhh.

Well you might not, and I clearly aren't, but I see plenty of people pop
up here, get abused and insulted, and they're never seen again. Which,
apparently, the long term Lisp people here are happy to see happen.

-- Bruce

Arjun Ray

unread,
May 21, 2002, 2:19:04 AM5/21/02
to
In <bruce-D9FF08....@copper.ipg.tsnz.net>,
Bruce Hoult <br...@hoult.org> wrote:

| but I see plenty of people pop up here,

[raises hand]

| get abused and insulted,

Well, I wasn't. Or, at least, not that I could tell (since I could be
supremely oblivious.)

| and they're never seen again.

Okay, it must be time for someone to chase me away.

| Which, apparently, the long term Lisp people here are happy to see
| happen.

This strikes me as a canard. They are ultimately much more devastating
than abuse or insults.

Kenny Tilton

unread,
May 21, 2002, 2:17:39 AM5/21/02
to

Neil Schemenauer wrote:
>
> However, if it doesn't grow
> its standard library (even if it's only a de facto standard) then
> it's going to eventually die.

The only way Lisp will die is the same way the mac gui lost to the
microsoft dos command line, ie when some other language matches Lisp and
goes it one better. That would be fine by me, if not CL vendors. :)

> The community needs to realize
> this and start working on it. Denying the problem does not help.

Hey, I'd like lotsa libraries, I just do not see it as a problem. Then
again, I tend to develop applications in which what I write is the beef.
Sounds like these other languages are more like scripting languages,
connecting libraries that supply the beef.

These scripting languages are not technical threats to CL. As for the
popularity threat, well, unpopularity may be fatal to some languages,
but Lisp clearly is not one of them, precisely because it is so
fundamentally excellent. COBOL was popular, Pascal was popular, C++ was
popular... live by popularity, die by popularity.

My crystal ball says: The explosion of new languages means C++ is spent
and is falling back to Earth. CL is the answer, witness the excitement
over CL features reintroduced by the new languages. These new languages
will serve as stepping stones for a few refugees from C++ to CL. This
new blood needs reach only a very low threshhold before the old blood,
discouraged by years of unpopularity, takes heart and returns to action.
In /very/ short order CL has more libraries than anyone, precisely
because of CL's fundamental strength. Popularity follows incidentally,
not vitally.

You heard it here first. Now where's my fiddle...

:)

Frode Vatvedt Fjeld

unread,
May 21, 2002, 2:57:05 AM5/21/02
to
Neil Schemenauer <nas-u...@arctrix.com> writes:

> [..] Lots of CL users seem to have the attitude that CL is king and


> all other languages are inferior. They seem to think that no
> advancement of the language is necessary. The ANSI CL standard was
> an awesome technical feat but progress cannot stop there.

Actually I don't think most CL users (at least not myself) believe CL
to be the end of history, only that most emerging competitors are
giant leaps backwards rather than steps forward. The Python language
certainly is a leap backwards in every respect, with the possible
exception of C-world integration (and some might count the whitespace
syntax a win, but I at least consider it a failed experiment).

So no advancement of the CL language would be necessary to outclass
the competition, which of course is not to say that advancement
wouldn't be a good thing.

I agree that having loads of defacto-standardized libraries would be
nice, but in actuality I personally don't have any great need for any
library functionality in particular, which again is probably why I
haven't contributed much to any such library. And this might be the
case for others too.

--
Frode Vatvedt Fjeld

David Golden

unread,
May 21, 2002, 3:23:10 AM5/21/02
to
Bruce Hoult wrote:

> Well you might not, and I clearly aren't, but I see plenty of people pop
> up here, get abused and insulted, and they're never seen again. Which,
> apparently, the long term Lisp people here are happy to see happen.
>

I suspect a major problem is that the "new generation" of news readers
don't know what a killfile is.

David Golden

--
Don't eat yellow snow.

Bruce Hoult

unread,
May 21, 2002, 3:29:31 AM5/21/02
to
In article <yBmG8.7372$04.2...@news.iol.ie>,
David Golden <david....@oceanfree.net> wrote:

> Bruce Hoult wrote:
>
> > Well you might not, and I clearly aren't, but I see plenty of people pop
> > up here, get abused and insulted, and they're never seen again. Which,
> > apparently, the long term Lisp people here are happy to see happen.
>
> I suspect a major problem is that the "new generation" of news readers
> don't know what a killfile is.

Who do you suggest should be killfiling whom?

Besides, what does a "new generation" have to do with anything? I've
been on usenet for more than a decade, I've always used software with a
killfile ([[s]t]rn, then NewsWatcher) but have never killfiled anyone,
and I'm not about to start now.

-- Bruce

Erik Naggum

unread,
May 21, 2002, 6:25:18 AM5/21/02
to
* Bruce Hoult

| Well you might not, and I clearly aren't, but I see plenty of people pop
| up here, get abused and insulted, and they're never seen again.

You do? You see, to people who observe _before_ they judge, this is
simply not in the evidence. Just because you feel like it _should_ be
true, because that would be much more fun for you, for whatever perverse
reason, does not _make_ it true. However, there is some truth to the
idea that perception makes reality. In this sense, you are the one who
keeps making this story stick to people's memory, much to the annoyance
of other people. Could you please stop? You are scaring the newbies.
--
In a fight against something, the fight has value, victory has none.
In a fight for something, the fight is a loss, victory merely relief.

70 percent of American adults do not understand the scientific process.

Bruce Hoult

unread,
May 21, 2002, 6:53:51 AM5/21/02
to
In article <32309655...@naggum.net>, Erik Naggum <er...@naggum.net>
wrote:

> * Bruce Hoult
> | Well you might not, and I clearly aren't, but I see plenty of people pop
> | up here, get abused and insulted, and they're never seen again.
>
> You do? You see, to people who observe _before_ they judge, this is
> simply not in the evidence. Just because you feel like it _should_ be
> true, because that would be much more fun for you, for whatever perverse
> reason, does not _make_ it true. However, there is some truth to the
> idea that perception makes reality. In this sense, you are the one who
> keeps making this story stick to people's memory, much to the annoyance
> of other people. Could you please stop? You are scaring the newbies.

You might have some sort of point if there was a factual basis to your
claims. As usual there isn't. I have never before made the observation
that people pop up here, get abused and insulted, and are never seen
again. Not once. Check the archive on google.

I suggest you read what you wrote above and understand that it applies
best to youself.

-- Bruce

Erik Naggum

unread,
May 21, 2002, 7:24:28 AM5/21/02
to
* Bruce Hoult

| You might have some sort of point if there was a factual basis to your
| claims. As usual there isn't.

Christ, dude. So you had no arguments. Just checking.

| I have never before made the observation that people pop up here, get
| abused and insulted, and are never seen again. Not once. Check the
| archive on google.

The point, Bruce, was that you have never made that observation at all.

| I suggest you read what you wrote above and understand that it applies
| best to youself.

Yeah, yeah. Apply to yourself. Yadayada. How much RAM do you really
need to do that thing?

Incidentally, have you considered how much the first two sentences above
might apply to yourself? I guess not. "Apply to myself" does not compute.

Just for the record: You are not a newbie. You are only incredibly
annoying and won't go away, and you feel abused much more than you are,
and then you abuse in return. This is doubly annoying. Usually, this
kind of behavior is associated with newbiehood, but you have been around
a long time, so you cannot use yourself as evidence of your claim, OK?

Ingvar Mattsson

unread,
May 21, 2002, 7:25:08 AM5/21/02
to
Chris Beggy <chr...@kippona.com> writes:

[SNIP]
> Unless one considers elisp, I don't know about lisp for other
> relatively standard things:
>
> mail: smtp, lmtp, imap
> news: nntp
> messaging: snmp, irc, im, jabber
> unix: shell utilities
> ident: ldap
> streams: mp3 codec
> security: gpg, tls, ssl
> char: unicode, utf-8, double-byte tools
> files: ftp, nfs, afs

I have the basis for an nntp library somewhere on my home disk. I
played around with it in order to build myself a CL-based news reader
(more as a toy than anything else) and (possibly) as use for a gateway
between nntp and other media.

If there is enough interest, I could probably dust it off and see what
I can do about getting it downloadable from somewhere.

//Ingvar
--
When the SysAdmin answers the phone politely, say "sorry", hang up and
run awaaaaay!
Informal advice to users at Karolinska Institutet, 1993-1994

Bruce Lewis

unread,
May 21, 2002, 9:33:14 AM5/21/02
to
Neil Schemenauer <nas-u...@arctrix.com> writes:

> Kenny Tilton <kti...@nyc.rr.com> wrote:
> > Now which is harder, whipping up interfaces to the latest toys or
> > finishing Python?
>
> Harder is not the question. The question is will anyone do it?

This reminds me of a psychology experiment to find the difference
between the problem-solving approaches of physicists and
mathematicians.

They set up a room with a wastebasket in the middle, and a chair on the
side with a fire extinguisher underneath. They set fire to the
wastebasket and then sent the physicist in the door. She looked at the
fire, looked at the extinguisher, went over to the chair, picked up the
extinguisher and put out the fire.

They repeated the same experiment with a mathematician. He exhibited
the exact same behavior.

For the next experiment, they moved the wastebasket between the doorway
and the chair. They set it on fire and sent in the physicist. She
looked at the fire, saw the chair on the other side, and walked around
to get the extinguisher. Then she put out the fire.

They set up the experiment again, but this time sent in the
mathematician. He looked at the fire, saw the chair on the other side,
and walked over to the wastebasket. Using his foot, he shoved the
burning wastebasket into the center of the room. Then he sat in the
chair and did nothing.

When the psychologists interviewed him, he explained, "I saw that the
new problem was similar to the one I'd previously solved, so I reduced
the new to the old problem and was done."

This is experiment is, of course, fictional. However, the mode of
thinking is real. As long as the CL community ignores problems that are
boring and straightforward, they won't get solved. Standardizing
interfaces is one such problem. It involves working with people, not
just code, so it's not as fun as the usual things you do with CL.

Those of you who just want to see CL not die have nothing to worry
about. But those of you who want to use CL more in your day jobs will
have to see some boring, straightforward problems solved before it will
happen.

--
<brlewis@[(if (brl-related? message) ; Bruce R. Lewis
"users.sourceforge.net" ; http://brl.codesimply.net/
"alum.mit.edu")]>

Adam Warner

unread,
May 21, 2002, 9:44:20 AM5/21/02
to
Ingvar Mattsson wrote:

> Chris Beggy <chr...@kippona.com> writes:
>
> [SNIP]
>> Unless one considers elisp, I don't know about lisp for other
>> relatively standard things:
>>
>> mail: smtp, lmtp, imap
>> news: nntp
>> messaging: snmp, irc, im, jabber
>> unix: shell utilities
>> ident: ldap
>> streams: mp3 codec
>> security: gpg, tls, ssl
>> char: unicode, utf-8, double-byte tools files: ftp, nfs, afs
>
> I have the basis for an nntp library somewhere on my home disk. I played
> around with it in order to build myself a CL-based news reader (more as
> a toy than anything else) and (possibly) as use for a gateway between
> nntp and other media.
>
> If there is enough interest, I could probably dust it off and see what I
> can do about getting it downloadable from somewhere.

I'm interested Ingvar. The currently available nntp library is GPLed which
means you must GPL your software in order to be able to distribute a
software product combined with the library. Not only does this effectively
preclude all proprietary software from accessing the library but it also
stops any combined products being released under a more liberal licence.

The next less restrictive licence to choose would be the LLGPL:
http://opensource.franz.com/preamble.html

Eventually it would be nice to see the library included in the
Comprehensive Common Lisp Archive Network:
http://ww.telent.net/cliki/cclan
http://cclan.sourceforge.net/

Some code in cCLan is released under the Bugroff license:
http://www.geocities.com/SoHo/Cafe/5947/bugroff.html

I guess this code is effectively public domain. Do what you like with the
code without bothering the author. I think a GPL-compatible BSD/MIT-style
license would be a better choice than telling lawyers to learn an honest
trade.

If you want people to be required to provide any changes to the library
when they release code that uses this library consider the LLGPL. If you
want people to be free to modify the library without being required to
provide their code consider the MIT or no advertising clause (i.e.
GPL-compatible) BSD licence, e.g.:

http://www.opensource.org/licenses/mit-license.html

Either provides you with greater protections as an author than the bugroff
licence. For example it is wise to make an explicit warranty disclaimer.

Thanks again for your potential offer of code.

Regards,
Adam

Paolo Amoroso

unread,
May 21, 2002, 10:28:19 AM5/21/02
to
On Mon, 20 May 2002 01:18:23 GMT, Gabe Garza <g_g...@ix.netcom.com> wrote:

> If anything, the proliferation of free Common Lisp implementations is
> a sign of fragmentation and wasted effort--we have communities
> actively working on CMUCL, SBCL, CLISP, GCL, ECLS, and OpenMCL.

Is GCL still supported? Is it still the primary platform for Maxima
deployment?

I seem to understand that the ECLS developer community includes a single
individual.

As for CMUCL and SBCL, both developer communities recently had and exchange
of ideas about merging back the projects. It looks like there may be
interest in this, and it may be technically possible. But don't hold your
breath.


Paolo
--
EncyCMUCLopedia * Extensive collection of CMU Common Lisp documentation
http://www.paoloamoroso.it/ency/README
[http://cvs2.cons.org:8000/cmucl/doc/EncyCMUCLopedia/]

Ingvar Mattsson

unread,
May 21, 2002, 10:40:29 AM5/21/02
to
Adam Warner <use...@consulting.net.nz> writes:

OK, if I remember correctly, the current code is tied to CMUCL's
socket-opening code, but I imagine compatibility wrappers to be
easy(ish) to find/write (there *may* be ACL compat code, depending on
when in time it was written).

[SNIP]

> Thanks again for your potential offer of code.

Not a problem, it's been collecting virtual dust on my disk since a
few years abck. As for what license I will release it under, I don't
know, but my gut feeling right now is "here is the code, do what you
will, if it breaks, you keep both parts, should you want to submit a
fix, here's my mail address".

//Ingvar
--
When C++ is your hammer, everything looks like a thumb
Latest seen from Steven M. Haflich, in c.l.l

Bijan Parsia

unread,
May 21, 2002, 11:06:27 AM5/21/02
to

Just to provide a counter-data-point, I come to this newsgroup with
experience in Smalltalk, and I fairly often mention Smalltalk and
Smalltalk issues, and I don't feel that I've gotten a very chilly
reception.

OTOH, I don't think people will give up on Perl, Python, Ruby, etc. just
because they get a warmer reception in comp.lang.lisp. I mean *really*.

Even if you just meant that it's a *necessary* condition (which wasn't
obvious from your rhetoric), I would think that tarting out comp.lang.lisp
is *far* down the list of things to be accomplished ;)

Cheers,
Bijan Parsia.

Bijan Parsia

unread,
May 21, 2002, 11:20:31 AM5/21/02
to
On Tue, 21 May 2002, John Wiseman wrote:

> Kenny Tilton <kti...@nyc.rr.com> writes:
>
> > There are two questions. (a) How good is a language? (2) How much
> > glue is there to today's hot toys? All this yammering lumps the two
> > together.
>
> Yes, and I think Norvig did a good job of describing what the issues
> were, and keeping them separate.

If you go back in this three, you'll see that I think almost exactly the
opposite. I think Kenny's formulation hides that (a) generally is a feater
of the *langauge* whereas (2) [weird numbering scheme Kenny!] is generally
a feature of implementations.

It may sound like a Schemely reponse to say, "Oh, but the there are
*implementations* that have what you need." but I'm not clear that
is. But, in point of fact, it's *much* harder to get
portable-over-all-implementation libs than to get *one* implementation
with all the functionality. If the latter is what's *really* needed for
success, pursuing the former will slow things down. A lot.

That's what I mean by Norvig's "double standard". *No one* disputes the
use of being able to take socket or thread or...code and drop it into
almost any CL implementation and have it just work. I do dispute that
*that's* what makes CL "lose ground" to Python (for the most part).

Finally, I think a *lot* of care must be taken when claiming that the
Python (or better, the Ruby) standard libs are so great. Ruby's a very
young language. Very young. But, afaict, it's *never* had this sort of
whinging thrown at it.

A lot of the issues of between implementation porting crop up (though
perhaps not as serverely) for between version of Python.

> Both are pretty important when you
> want to write code.

Sure. As no one denies. But when python is lacking in some area (SVG
support anyone?) folks just code it up.

[snip]


> I think the following statement is hard for anyone in comp.lang.lisp
> to deny (but I sure expect to be surprised):
>
> Lisp is definitely a better language than most (though it's not as far
> ahead as it once was) and the state of lisp libraries is definitely
> not as good as that of many other languages.

I don't know why you thing this is hard. The real question is *which*
libraries? AFAICT, LispWorks has *excellent* libraries (for *lots* of
things). As does Allegro. As does MCL. Etc.

Try to replicate the KnowledgeWorks stuff in Python!

Ok, maybe not everyone needs that, but that's at least part of the point,
yes?

Sure, there's no *standard* for sockets...but there's not *standard* for
sockets in python, just a canonical implemenation.

> Let's just admit it's a problem (for some, maybe not for everyone) and
> work on it.

Well, let's admit the *right* problem.

Or better, let's just work on useful, portable libraries. Since we *all*
admit they're a good, we can be positively driven rather than negatively.

*But*, given scare resources, it makes sense to prioritize, yes?

> Actually, people are *working* on the problem of making it easy to
> create, distribute, find and install lisp libraries right now--the
> Comprehensive Common Lisp Archive Network (CCLAN) is developing the
> required infrastructure, which is a lot of work.

Yep. Yay for them.

But the Vendors do good too.

[snip]


> For myself, I'm close to deciding that anything I write will use the
> APIs for these things as defined by Allegro Common Lisp, mostly
> because they're the best I've seen, but also because it seems like
> there's some movement toward accepting them as de facto standards
> (E.g., OpenMCL's implementing the ACL socket API, the Portable
> AllegroServe project's acl-compat files, maybe even some recent cmucl
> and sbcl development.)

Sounds like an excellent plan to me, FWIW.

Cheers,
Bijan Parsia.

Tim Bradshaw

unread,
May 21, 2002, 9:35:40 AM5/21/02
to
* Neil Schemenauer wrote:

> Which one of those things are required for writing, for example,
> a simple web server? You can do it in Python using a few lines
> of code. The same code will work with Jython was well. How
> many lines of CL does it take?

I think my original one was about 60 - its current descendent is 250
or something (of profusely commented code) but it has lots more stuff
(most of which is over-design I never used, sigh). The original one
never made it into CVS so I'm working from memory. I do know that it
took under an hour to write, including learning about the socket
interface in the implementation I'm using. The current one has 25 or
30 lines of implementation-dependent code depending on which
implementation you're using. Porting it took less long than I've
spent on this article.

If people are put off by the effort required to do this, then, well,
they're probably going to be put off by getting up in the morning. In
the application that used (uses) this little web server I spent
*hundreds of times* longer doing application-specific HTML-generating
code than I ever did in the web server.

I think most of the `not standard so I can't use it' complaints are
work avoidance. So there's a standard interface to
HugeComplicatedInteroperabilityStandard, say. What has this bought
you, since you are still two years away from understanding
HugeComplicatedInteroperabilityStandard well enough to use it, and in
that time it will either have died, or spawned four new versions and
fifteen other things you need to understand to use it. Look at XML:
can anyone *read* fast enough to keep up with the new standards it's
spawning?

--tim (please CC any followups to me if you want me to see them, I
don't read news very often, sorry to be rude.)

Raymond Toy

unread,
May 21, 2002, 11:41:16 AM5/21/02
to
>>>>> "Paolo" == Paolo Amoroso <amo...@mclink.it> writes:

Paolo> On Mon, 20 May 2002 01:18:23 GMT, Gabe Garza <g_g...@ix.netcom.com> wrote:
>> If anything, the proliferation of free Common Lisp implementations is
>> a sign of fragmentation and wasted effort--we have communities
>> actively working on CMUCL, SBCL, CLISP, GCL, ECLS, and OpenMCL.

Paolo> Is GCL still supported? Is it still the primary platform for Maxima

Yes. There's some new development work on gcl. See savannah.gnu.org.

Paolo> deployment?

Yes and no. The latest versions of Maxima will now run with Clisp and
CMUCL. The intent is for Maxima to run on any ANSI CL.

Ray

Kaz Kylheku

unread,
May 21, 2002, 12:35:32 PM5/21/02
to
On Fri, 17 May 2002 22:09:07 +0200, Marc Battyani
<Marc.B...@fractalconcept.com> wrote:
>In this paper he writes : "In 2002, the situation for Lisp is more bleak:
>the language standard has stagnated, while other languages regularly add new
>standards for protocols like HTTP, HTML, XML, SOAP..."

I can't think of a single programming language which has new
``standards'' for these things. Only libraries.

Christopher Browne

unread,
May 21, 2002, 1:02:56 PM5/21/02
to

Common Lisp is nicely characteristic of a system in which this sort of
thing is almost intentionally ambiguous. There are large parts of the
CL standard that are kind of "libraries," but which are not
characterized as such in the standard.

In light of that, it seems not unreasonable to continue the trend,
leaving it ambiguous whether new functionality should be considered
"language" or "library."

In any case, what people care about is that:

-> They can expect to use STL with C++ in a standard way;
-> They can expect to use CORBA with C++ in a standard way;
-> They can expect to use SOAP::Lite with Perl in a quasi-standard way.

Whether it's library or language is less important than that it is
conveniently usable.

"Conveniently usable" is true of SOAP::Lite. (Whether you like SOAP
or Perl or not.)

The same is not true for RPC or socket access in CL.

Objecting on the basis that Perl only has one implementation is an
_excuse_, and someone who wants "conveniently usable" doesn't care
about excuses, just about whether the facility is "conveniently
usable."
--
(reverse (concatenate 'string "ac.notelrac.teneerf@" "454aa"))
http://www.cbbrowne.com/info/multiplexor.html
"Windows95, Word97, Office98: With all the criticisms of MICROS~1, at
least they include ``best-before'' dating on many of their
products..." -- cbbr...@hex.net

Andy

unread,
May 21, 2002, 1:05:55 PM5/21/02
to Tim Bradshaw
Tim Bradshaw wrote:

[snip]

> I think most of the `not standard so I can't use it' complaints are
> work avoidance. So there's a standard interface to
> HugeComplicatedInteroperabilityStandard, say. What has this bought
> you, since you are still two years away from understanding
> HugeComplicatedInteroperabilityStandard well enough to use it, and in
> that time it will either have died, or spawned four new versions and
> fifteen other things you need to understand to use it. Look at XML:
> can anyone *read* fast enough to keep up with the new standards it's
> spawning?
>

If i would try to understand every detail of anything i would end up
wise
(maybe) and pour (shure). So what i need is an abstraction of things
like
HCIS to use it.
Thats what interfaces for (or do you know what CBE cmd your PCI bus uses
to write into your ethernet card ;-). Simple look at the definition of
the
interface, understand the model, use the interface and don't bother
about
whats behind the door. Ok, this rarly works like this. But if i want
to program a web site then i want to start with a tool like araneida or
any
other tool that hides the bloody rfc2616 details way from
me as far as possible. And i think this is true not only for lisp but
for each
language that one want to use.

On the other side, i found a lot of tools and libraries that are
available
for lisp on the web. And most of them works fine and are well
documented. That
is a big difference to a lot of libs for other languages. Sometimes the
libs
don't work correctly or the documentation is bad or wrong. So for my
feeling
the available tools are first quality. This might come from lisp but i
think
it comes more from the quality of there authors.

So all what is needed is some kind of goodwill from the comunity. If one
makes
a tool for a project that can be usefull to other one should publish and
support
it. A lot of the readers of these newsgroup do so and i hope the others
will
think about these trivial call.
Since the lisp community is a small one it is a big difference if one
percent or
fifty percent of the community will contribute. I will do (when i'm
ready for
doing anything usefull with lisp ;-)

Best regards
AHz

P.S: Anyone said this NG crouwls out new members. I'm a newbie. I'm
still here
and i like it.
A.

Marc Battyani

unread,
May 21, 2002, 1:55:56 PM5/21/02
to

"Peter Norvig" <pe...@norvig.com> wrote in message
news:da69ff6a.02051...@posting.google.com...
> Thanks for the comments on my retrospective update. I stand by my
> conclusion "Lisp experts are still as productive as ever, but newer
> programmers are less likely to pick up Lisp". I do agree with many of
> the points made in this thread. I agree that most of the libraries do
> exist somewhere, but the fact that they are not standardized makes the
> language harder to use, especially for a non-expert. By "standardized"
> I mean available from one canonical location in a form that is
> portable across implementations; I don't care whether they are part of
> an ANSI standard or not.
>
> One thing I regret about my page is the emphasis on popularity. Of
> course it is true that popular does not equate to better. And the
> measures I cite were the ones that were available to me, and are not
> the most scientific or useful. The only number that I think really
> counts is number of jobs offered. Even that number is unreliable; I
> know there are more than 4 openings for Lisp programmers.
>
> I've updated my page to de-emphasize popularity and stress the
> features that once made Lisp unique, and to incorporate some of the
> points made in this thread. Now I want the take-home message to be
> "Overall, Lisp does very well on the nine features. Anyone making an
> objective choice based on these features would continue to find Lisp
> the best choice for a wide range of applications. But there are now
> viable contenders that did not exist in 1991." In other words, using
> Lisp was a no-brainer in 1990, but now it depends on how you
> prioritize a number of factors.

I've looked at the latest version of your page (the one with coulours :))
and IMHO it's much better !
Thanks for modifying it.

Marc

Marc Battyani

unread,
May 21, 2002, 2:24:50 PM5/21/02
to

"Neil Schemenauer" <nas-u...@arctrix.com> wrote

> Which one of those things are required for writing, for example,
> a simple web server? You can do it in Python using a few lines
> of code. The same code will work with Jython was well. How
> many lines of CL does it take?

Zero if you use mod_lisp. Less than 100 if you write it from scratch.
Well you still have to generate the HTML you want to reply, but for this the
advantage is definitively on the Common Lisp side with its macros.

> Yes, the GC in sucks. I know. I wrote it. Yes, Python is
> agonizingly slow when compared to C++ or compiled CL. You know
> what else? It doesn't matter. Python gets the job done. It's
> got a large, well documented stardard library. It's got a free,
> very portable, fairly bug free implementation. It plays well
> with other languages and libraries.

OK.

> > Now which is harder, whipping up interfaces to the latest toys or
> > finishing Python?
>
> Harder is not the question. The question is will anyone do it?

> Lots of CL users seem to have the attitude that CL is king and
> all other languages are inferior.

:)

> They seem to think that no
> advancement of the language is necessary. The ANSI CL standard
> was an awesome technical feat but progress cannot stop there. A

> standard network socket interface would be nice, for example. Is
> the CL community working on one?

There are various ACL sockets compatibility layers so maybe we can assume
that the ACL socket interface is the de facto standard.
I've created a compatibility layers page on CLiki to put these kind of
libraries.

> I feel sad. CL is a great language. However, if it doesn't grow


> its standard library (even if it's only a de facto standard) then

> it's going to eventually die. The community needs to realize


> this and start working on it. Denying the problem does not help.

This thread is precisely here for debating this.
As I posted before I'm not for standardizing anything but the lower level
layers and only when they are obvious. ie : yes for standardizing the socket
layer but no for standardizing a web server.

Marc

Marc Battyani

unread,
May 21, 2002, 2:24:53 PM5/21/02
to

"Kaz Kylheku" <k...@localhost.localdomain> wrote in message
news:slrnael1j...@localhost.localdomain...

These words were from Peter Norvig and since them he has modified his page.

Marc


Erik Naggum

unread,
May 21, 2002, 3:38:22 PM5/21/02
to
* Christopher Browne <cbbr...@acm.org>

| "Conveniently usable" is true of SOAP::Lite. (Whether you like SOAP
| or Perl or not.)
|
| The same is not true for RPC or socket access in CL.

Some languages manage to survive with many ways to do the same thing,
others "die" as soon as two different ways to do the same thing crop up.
Apparently, Common Lisp is not big enough for multiple implementations of
core features. (I wonder why so many people insist on making their own
versions of almost everything, from whole environments to sockets, rather
than using or adapting existing systems. Clearly, the ability to make
design decisions that cannot be fixed, and hence produce "mistakes" is at
the core of this phenomenon, visible in particular in Scheme.)

This is somewhat like Unicode: It has managed to be sold as a unifying
coded character set, yet it is actually only _another_ one, and its
function as unifying depends on its acceptance as such. Common Lisp
should have been a unifying Lisp, too, but some clueless rebels have been
underminig it from the start with "alternatives" and think they are
offering people "choice" -- but choice is precisely what people do _not_
want: While I may want a great selection of fresh food, I do not want the
"option" of paying for the same item with different prices in different
currencies or using different credit or discount cards so I have to
become conscious of lots of stupid little details. While people may
regard the choice of political party and candidates to be essential to
democracy, most people would be confused beyond their sanity if they were
required to choose the political system in an election, such as by
running campaigns for competing constitutions.

Some things are better the fewer choices there are, and really good only
when there is no choice so you never even think about it. Some things
are better the more choices there are. It is an issue of considerable
wisdom, intelligence, and ability to yield to the bigger picture to
understand which is which. Choice per se is _not_ good. Standards that
_limit_ choice are actually phenomenally important social creations, just
like one, authoritative, correct spelling instead of personal "choice".
Like, in 1894, Norway passed a law to adopt a uniform time zone for all
of the kingdom of Norway, based on the Greenwich meridian, which is one
such very clever thing that solves a host of problems in its absence,
which I bet nobody was aware of, and still are not quite aware of, since
using a global UTC instead of a local time zone is so much smarter for
exactly the same reason. We have yet to _accept_ the standard way to
write dates that is globally unambiguous, however, but at least we have
standardized on a single calendar for (almost) the entire world, now.
Stuff like this is not really about limiting choice, it is about making
so many other choices available to us. This is really hard to see before
the fact, and sometimes even after.

Thomas F. Burdick

unread,
May 21, 2002, 3:58:29 PM5/21/02
to
Christopher Browne <cbbr...@acm.org> writes:

> In any case, what people care about is that:
>
> -> They can expect to use STL with C++ in a standard way;
> -> They can expect to use CORBA with C++ in a standard way;
> -> They can expect to use SOAP::Lite with Perl in a quasi-standard way.
>
> Whether it's library or language is less important than that it is
> conveniently usable.
>
> "Conveniently usable" is true of SOAP::Lite. (Whether you like SOAP
> or Perl or not.)
>
> The same is not true for RPC or socket access in CL.
>
> Objecting on the basis that Perl only has one implementation is an
> _excuse_, and someone who wants "conveniently usable" doesn't care
> about excuses, just about whether the facility is "conveniently
> usable."

Well, if ther person who wants conveniant usability doesn't mind
limiting him/herself to a single implementation, I think that most
combinations of Today's Buzzword Library are convenient. The only
time the issue of multiple implementations comes up is if a person
either insists in using /all/ implementations, or wants a combination
of libraries available for one implementation, but insists on using
another.

Which is not to say that there aren't holes, just that I've found
every combination I've needed, pretty easily. Well, except for a
general-purpose MIME parsing and generating library; I ended up just
doing an ugly hack that worked for any valid case that particular app
could encounter.

--
/|_ .-----------------------.
,' .\ / | No to Imperialist war |
,--' _,' | Wage class war! |
/ / `-----------------------'
( -. |
| ) |
(`-. '--.)
`. )----'

Christopher Browne

unread,
May 21, 2002, 4:02:56 PM5/21/02
to
In an attempt to throw the authorities off his trail, Erik Naggum <er...@naggum.net> transmitted:

> * Christopher Browne <cbbr...@acm.org>
> | "Conveniently usable" is true of SOAP::Lite. (Whether you like SOAP
> | or Perl or not.)
> |
> | The same is not true for RPC or socket access in CL.
>
> Some languages manage to survive with many ways to do the same thing,
> others "die" as soon as two different ways to do the same thing crop up.
> Apparently, Common Lisp is not big enough for multiple implementations of
> core features. (I wonder why so many people insist on making their own
> versions of almost everything, from whole environments to sockets, rather
> than using or adapting existing systems. Clearly, the ability to make
> design decisions that cannot be fixed, and hence produce "mistakes" is at
> the core of this phenomenon, visible in particular in Scheme.)

Yes, this is a problem.

The problem isn't that any of the "ways" are necessarily particularly
bad.

It's not fundamentally a "problem" that people have tried various ways
of getting at SQL databases; tried various ways of generating HTML;
tried various ways of [whatever].

The problem comes when things don't settle down to something at least
vaguely resembling a standard.

If there are three "sockets" systems to work with, and I decide to
layer my HTTP library on top of one, and you decide to layer your
CORBA library on top of another, _that_'s where it starts being a
problem.

If I'm trying to figure out what to layer my HTTP library on top of,
and can't decide, or have something that's only usable with one CL,
there's where "problem" starts emerging more clearly.

The fact that there's only one Perl implementation means that it's
straightforward to expect to be able to layer one Perl extension atop
another Perl extension; you can layer all sorts of network
functionality atop the Perl sockets layer, because everyone knows
that's the defacto standard way to "do network stuff."

It's not a fundamental problem to have multiple implementations, just
as there exists Python, Jython, and possibly even Viper (Python atop
OCAML). It would be a problem if they had massively different ways of
handling the "base layers."

CL truly does need some "common networking" modules, whether based on
identity ("There Can Be Only One" -- The Highlander) or on
interoperability (where several "libre" libraries have provided
emulations of Franz libraries).

The problem that Unix "Make" got stuck with cruft that we can't get
rid of today demonstrates that design requires some care.

And I disagree; the issue _isn't_ that "CL is not big enough for
multiple implementations."

The issue is that if people get accustomed to the differences, then
you get to the point of it being impossible to fix them, just as with
Unix Make.

C++ is, if any system is, "big enough;" a big chunk of what it suffers
from is that it initially wasn't designed sufficiently carefully,
which meant that multiple implementations went their directions, and
when they decided to standardize those directions, they had to
compromise by saying "It's all standard!", making a standard that's
nasty to try to implement.

The same can easily happen with CL: If different vendors (commercial
or free) implement different crucial extensions that are crucial
enough to persist, that grows into a horrible fungus of
not-quite-interoperability. (IF*, anyone?)
--
(reverse (concatenate 'string "gro.gultn@" "enworbbc"))
http://www.ntlug.org/~cbbrowne/spreadsheets.html
Rules of the Evil Overlord #51. "If one of my dungeon guards begins
expressing concern over the conditions in the beautiful princess'
cell, I will immediately transfer him to a less people-oriented
position." <http://www.eviloverlord.com/>