Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

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

480 views
Skip to first unread message

Kenny Tilton

unread,
Jun 23, 2005, 5:37:50 PM6/23/05
to
[apologies if this has materialised in similar form or does so soon
unbeknownst to me, but from where I sit it appears Google ate a similar
report posted yesterday via google groups.]

Dr. McCarthy joined with Henry Baker, his predecessor at the microphone,
in bemoaning the standardization of Common Lisp as stultifying if not
mortifying, in that it ended innovation.

When rahul defended standardization as allowing his code to run ten
years from now, McCarthy indicated that (paraphrasing) by the looks of
Rahul it was unlikely he would produce code that anyone would want to
run ten years from now.*

XML had the honor of having McCarthy stop in the middle of a meandering
bit of reflection to mention how much he disliked XML.

And when your correspondent asked why he had chosen such a crappy name
for such a great language and whether he regretted, in what is becoming
an annual rite of humiliation, he pretty much ignored my question, but
did mention that his preference had been FLPL, for Fortran List
Processing Language, because he liked Fortran.

Intriguingly, there is a Fortran package with that exact name and
acronym and function, created in 1960 as far as I can make out from some
light googling.

* McCarthy actually meant that very little code lasts ten years.

--
Kenny

Why Lisp? http://lisp.tech.coop/RtL%20Highlight%20Film

"If you plan to enter text which our system might consider to be
obscene, check here to certify that you are old enough to hear the
resulting output." -- Bell Labs text-to-speech interactive Web page

Christopher C. Stacy

unread,
Jun 23, 2005, 7:36:35 PM6/23/05
to
Kenny Tilton <kti...@nyc.rr.com> writes:
> * McCarthy actually meant that very little code lasts ten years.

That would suggest a serious disconnect with reality;
it's a little hard to believe.

Paul F. Dietz

unread,
Jun 23, 2005, 7:46:21 PM6/23/05
to

I think he said 20 years, not 10, and I'm not sure he was
entirely serious.

Paul

Pascal Costanza

unread,
Jun 23, 2005, 9:50:52 PM6/23/05
to
Kenny Tilton wrote:
> [apologies if this has materialised in similar form or does so soon
> unbeknownst to me, but from where I sit it appears Google ate a similar
> report posted yesterday via google groups.]
>
> Dr. McCarthy joined with Henry Baker, his predecessor at the microphone,
> in bemoaning the standardization of Common Lisp as stultifying if not
> mortifying, in that it ended innovation.

As much as I like Common Lisp, I think he has a point here.

> When rahul defended standardization as allowing his code to run ten
> years from now, McCarthy indicated that (paraphrasing) by the looks of
> Rahul it was unlikely he would produce code that anyone would want to
> run ten years from now.*

This was one of the most bizarre moments I have experienced ever, that
people tried to convince John McCarthy that standardization is actually
a good thing. As if he would ever care.

It was clear from his talk that he cares about a long-term vision
(namely how to achieve human-level artificial intelligence). Language
standardization is worth zilch in that regard.

Pascal

--
2nd European Lisp and Scheme Workshop
July 26 - Glasgow, Scotland - co-located with ECOOP 2005
http://lisp-ecoop05.bknr.net/

Peter Seibel

unread,
Jun 23, 2005, 11:32:01 PM6/23/05
to
Pascal Costanza <p...@p-cos.net> writes:

> Kenny Tilton wrote:
>> [apologies if this has materialised in similar form or does so soon
>> unbeknownst to me, but from where I sit it appears Google ate a
>> similar report posted yesterday via google groups.]
>> Dr. McCarthy joined with Henry Baker, his predecessor at the
>> microphone, in bemoaning the standardization of Common Lisp as
>> stultifying if not mortifying, in that it ended innovation.
>
> As much as I like Common Lisp, I think he has a point here.

As did Baker, or rather a dozen or so good points--can't wait until
his full slidedeck is available.

>> When rahul defended standardization as allowing his code to run ten
>> years from now, McCarthy indicated that (paraphrasing) by the looks
>> of Rahul it was unlikely he would produce code that anyone would
>> want to run ten years from now.*
>
> This was one of the most bizarre moments I have experienced ever,
> that people tried to convince John McCarthy that standardization is
> actually a good thing. As if he would ever care.

While concuring with Pascal that that was a weird moment (and it
wasn't just Rahul who tried to convince McCarthy that the standard was
a good thing), I'd like to point out that I don't think McCarthy was
insulting Rahul--merely misunderstanding him. From where I was sitting
it sounded like Rahul started his comment by saying something along
the lines of, "I don't care about standardization because it's going
to ensure that code that was written 20 years ago still runs today
...". In that he was riffing off a previously comment from someone
else in the audience. He went on to say that the reason he was glad
there was a standard was because it meant there were multiple
implementations *today* that could all run his code, each with
different strengths and weaknesses. However McCarthy appeared to have
heard him to say that he did care about having code from 20 years ago
that ran today and said that based on Rahul's appearance, it didn't
seem that he could have any code from 20 years ago that he'd need to
run today, i.e. Rahul is too young. A slight dig, perhaps but not
actually an insult. Just didn't want folks to think that McCarthy went
out of his way to be rude to folks.

-Peter

--
Peter Seibel * pe...@gigamonkeys.com
Gigamonkeys Consulting * http://www.gigamonkeys.com/
Practical Common Lisp * http://www.gigamonkeys.com/book/

Sashank Varma

unread,
Jun 24, 2005, 1:32:46 AM6/24/05
to
Peter Seibel wrote:

> However McCarthy appeared to have
> heard him to say that he did care about having code from 20 years ago
> that ran today and said that based on Rahul's appearance, it didn't
> seem that he could have any code from 20 years ago that he'd need to
> run today, i.e. Rahul is too young. A slight dig, perhaps but not
> actually an insult.

This is how I interpreted it as well.

The more general question -- Did standardization produce
stultification? -- is quite provocative though. Really, there are two
questions here:

(1) Has progress in Lisp slowed dramatically since CLtL1? (And this is
really what Baker and McCarthy meant by standardization -- the
ascension of Common Lisp.)

(2) Did CLtL1 *cause* this slowdown?

IMO, the answer to (1) is "yes" and the answer to (2) is "no." The
*real* reason progress slowed -- again, IMO -- was the dramatic drop in
both interest in and funding for Lisp following AI Winter, which began
around........1984. If this is correct, then standardization was
probably critical in keeping the dwindling community together.

This brings up an interesting question: Is the binding constraint of
the standard, which was critical during the 1980s and 1990s, gonna
choke the community now that it is again showing signs of growth?

It's a real question. One possibility is that as the community grows,
so will a parallel movement to open, clean up, modify, and extend the
standard. A harbinger of this is the CLRFI process, which is currently
trying to bootstrap itself. Another possibility is that the community
will split in a healthy way, with business users adhering closely to
the standard in the interests of portability, and with academics again
experimenting with new features and birthing new dialects.

Sashank

Christopher C. Stacy

unread,
Jun 24, 2005, 1:45:18 AM6/24/05
to
"Sashank Varma" <sashan...@yahoo.com> writes:
> (1) Has progress in Lisp slowed dramatically since CLtL1?
> (2) Did CLtL1 *cause* this slowdown?

I think we need "better" basis for a useful
discussion about this, By which I mean:
Define "progress" and "slowdown".

And do people think that those are mutually exclusive?

Kenny Tilton

unread,
Jun 24, 2005, 1:57:25 AM6/24/05
to

Christopher C. Stacy wrote:

Oh. please. You have no knowledge or experience of production code. It
/always/ gets thrown way when it needs changing. By the time the
corpolopolis acknowledges change is needed, the old code is too rotten
to refactor.

ie, No, I was just having fun, JMcC did not really slam Rahul, he just
made an easy point: production code regularly gets tossed, because it is
so much easier to rewrite than salvage. And if you are re-salvaging, tou
may as well change syntax change here and there.

Sashank Varma

unread,
Jun 24, 2005, 2:19:36 AM6/24/05
to
Christopher C. Stacy wrote:

I'm not sure what you're getting at. Progress can slow down in the
sense of decelerating, i.e., the second derivative is negative. There's
no doubt there's been progress over the last 21 years (e.g., the MOP).
Question (1) is about whether Lisp has declined from being a fecund
source of programming language innovations, as it was in the 1960s and
1970s.

Kenny Tilton

unread,
Jun 24, 2005, 2:11:26 AM6/24/05
to

Paul F. Dietz wrote:

> Christopher C. Stacy wrote:
>
>> Kenny Tilton <kti...@nyc.rr.com> writes:
>>
>>> * McCarthy actually meant that very little code lasts ten years.
>>
>>
>>
>> That would suggest a serious disconnect with reality;
>> it's a little hard to believe.
>
>
> I think he said 20 years, not 10,

Fantastic. We have a new entry for examples of "stupid quibble". Rahul
said ten, OK? (As if it fucking matters.)

and I'm not sure he was
> entirely serious.

I think this is the difference between a yobbo and and an intellect.

While everyone was laughing at "you do not look old enough...", and
Rahul was protesting that he meant "in the future", McCarthy slipped in
the mumble making clear that his point was simply that very little code
(from anyone!) lasts long enough to justify freezing a language. Your
correspondent can confirm this from <gasp!> actual production dode
experience.

Anyone with an iota of an experience in production code knows how fast
systems get swapped out, and that was the trivial yet telling point
McCarthy made in teasing Rahul and that particular defense of
standardization.

Kenny Tilton

unread,
Jun 24, 2005, 2:14:17 AM6/24/05
to

Pascal Costanza wrote:

> Kenny Tilton wrote:
>
>> [apologies if this has materialised in similar form or does so soon
>> unbeknownst to me, but from where I sit it appears Google ate a
>> similar report posted yesterday via google groups.]
>>
>> Dr. McCarthy joined with Henry Baker, his predecessor at the
>> microphone, in bemoaning the standardization of Common Lisp as
>> stultifying if not mortifying, in that it ended innovation.
>
>
> As much as I like Common Lisp, I think he has a point here.

Please get back to us when you have some application functionality you
cannot express in Common Lisp. As much as you think you like CL....

....PWUAAAAHAHAHAHAHAHAHAHAHAHH!!!!!!!

Christopher C. Stacy

unread,
Jun 24, 2005, 2:24:15 AM6/24/05
to
Kenny Tilton <kti...@nyc.rr.com> writes:

> Christopher C. Stacy wrote:
>
> > Kenny Tilton <kti...@nyc.rr.com> writes:
> >
> >>* McCarthy actually meant that very little code lasts ten years.
> > That would suggest a serious disconnect with reality;
> > it's a little hard to believe.
>
> Oh. please. You have no knowledge or experience of production code.

I've been delivering production code since about 1976,
so I guess if I haven't figured anything out by now,
I'm not likely to ever figure it out. (So you should
probably stop wasting time lecturing me about it.)

Kenny Tilton

unread,
Jun 24, 2005, 2:22:47 AM6/24/05
to

Peter Seibel wrote:

> Pascal Costanza <p...@p-cos.net> writes:
>
>
>>Kenny Tilton wrote:
>>
>>>[apologies if this has materialised in similar form or does so soon
>>>unbeknownst to me, but from where I sit it appears Google ate a
>>>similar report posted yesterday via google groups.]
>>>Dr. McCarthy joined with Henry Baker, his predecessor at the
>>>microphone, in bemoaning the standardization of Common Lisp as
>>>stultifying if not mortifying, in that it ended innovation.
>>
>>As much as I like Common Lisp, I think he has a point here.
>
>
> As did Baker, or rather a dozen or so good points--

As one who actually writes application Lisp code, no, Baker bid not have
a good point at all. For one thing, he manifested utter ignorance of
refactoring enhancements in other IDEs. For another, oh gimme a fucking
break, I really need a refactoring tool when I decide to change a class
name. (Hint: refactoring is all I do, this is not an issue.)

The incredibly sad thing is that baker's premise was "why is Lisp so
unpopular?" As was his predecesssor's. When I said, get a grip, Lisp is
taking off, audience members cried out, WTF are you talking about?

These dinosaurs are cute, but they do not follow cll and they have no
clue about its recent upopularity upsurge.

Christopher C. Stacy

unread,
Jun 24, 2005, 2:38:32 AM6/24/05
to
"Sashank Varma" <sashan...@yahoo.com> writes:

> Christopher C. Stacy wrote:
>
> > "Sashank Varma" <sashan...@yahoo.com> writes:
> > > (1) Has progress in Lisp slowed dramatically since CLtL1?
> > > (2) Did CLtL1 *cause* this slowdown?
> >
> > I think we need "better" basis for a useful
> > discussion about this, By which I mean:
> > Define "progress" and "slowdown".
> >
> > And do people think that those are mutually exclusive?
>

> I'm not sure what you're getting at. Progress can slow
> down in the sense of decelerating, i.e., the second
> derivative is negative.

I'm not sure what you're getting at.

What is the definition of "progress"?
New features?
Is that desirable?

Is the complaint that there has been insufficient new features
or new languages and that the fault lies in having developed
a language which already suited the needs of its users?

Besides, I don't see anyone stopping anyone else from
inventing their own versions of Lisp.

Also, one can play all kinds of guessing games about imaginary
alternate universe histories, so I'm not even sure what the
point of the discussion is.

> Question (1) is about whether Lisp has declined from
> being a fecund source of programming language
> innovations, as it was in the 1960s and 1970s.

Seems to me that most of the world haven't even
caught up to the Lisp ideas from two decades ago.

Also seems to me that people have taken some ideas
from other languages and applied them to Lisp.
(For example, in the last few weeks I saw messages
here from people taking ideas from functional
programming and from distributed programming
languages and trying to make dialects of Lisp.)

I can't imagine what the point is of whether Lisp
has "declined", anyway. Perhaps nobody has had
any super great ideas lately. That's somehow
the fault of people who like to use Common Lisp?

If someone has their own great ideas and wants to stop
working on Common Lisp and go invent their own language,
they should feel free. It's not like if they come into
close proximity with Lisp people that things are going
dangerously Arc.

Friedrich Dominicus

unread,
Jun 24, 2005, 2:38:37 AM6/24/05
to
Kenny Tilton <kti...@nyc.rr.com> writes:

> While everyone was laughing at "you do not look old enough...", and
> Rahul was protesting that he meant "in the future", McCarthy slipped
> in the mumble making clear that his point was simply that very little
> code (from anyone!) lasts long enough to justify freezing a
> language.

Well exactly that is not the case. Why was there a year 2000 problem?
Because nobody expected software to survice longer then a few
years. How many billions of dollars were spend on fixing those
"could-not-survive-so-long" software.

And every standard is just the snapshot in time. How many standards do
exist for Fortran? How many for C?

Friedrich

--
Please remove just-for-news- to reply via e-mail.

Pascal Costanza

unread,
Jun 24, 2005, 2:43:24 AM6/24/05
to
Sashank Varma wrote:

> The more general question -- Did standardization produce
> stultification? -- is quite provocative though. Really, there are two
> questions here:
>
> (1) Has progress in Lisp slowed dramatically since CLtL1? (And this is
> really what Baker and McCarthy meant by standardization -- the
> ascension of Common Lisp.)
>
> (2) Did CLtL1 *cause* this slowdown?
>
> IMO, the answer to (1) is "yes" and the answer to (2) is "no."

I think this is still oversimplified, but a good step closer to the truth.

> The
> *real* reason progress slowed -- again, IMO -- was the dramatic drop in
> both interest in and funding for Lisp following AI Winter, which began
> around........1984. If this is correct, then standardization was
> probably critical in keeping the dwindling community together.
>
> This brings up an interesting question: Is the binding constraint of
> the standard, which was critical during the 1980s and 1990s, gonna
> choke the community now that it is again showing signs of growth?

I don't think so. I see a difference between minor improvements of the
language and fundamental improvements. Minor improvements are things
like case sensitivity of symbols, better function names, improved
collection frameworks, GUI APIs, database libraries, iterate, etc. pp.
They are minor in the sense that the basic concepts are already there,
they provably work, noone is hindered in making use of these things. It
may or may not be useful to integrate them into the Common Lisp
standard, but it doesn't cause serious problems that they are not in the
standard. Common Lisp is flexible enough to make these things work anyway.

Major improvements would be new programming paradigms. Imagine something
like OOP or neural networks didn't exist yet. Lisp has provably shown
that it is again flexible enough to provide an excellent framework for
developing new programming approaches.

I think the negative effect of standards is not a real one - noone
hinders anyone to start even completely from scratch and build
completely new languages - but a psychological one. Standards induce the
belief that we have somehow reached a final stage in computer science
and that we only need to fill a few gaps and fix some annoying details,
and we're done. I think this is far from the truth.

In the industrial arena, companies like Sun and Microsoft and their
pseudo-standards are much worse in making people belief that we are
already "there", and in the acadamic realm, programming language
theorists are stifling real progress. When real breakthroughs first
appeared, they have always been useless in practice and unsound in
theory, and only much later developed into something practical and
well-understood.

In that regard, standards and standardization hurt.

Christopher C. Stacy

unread,
Jun 24, 2005, 2:53:00 AM6/24/05
to
Pascal Costanza <p...@p-cos.net> writes:
> In that regard, standards and standardization hurt.

What kind of bold iconoclastic geniuses are these,
who would be conceiving and bringing to life their
great new ideas for programming languages, but who
will now never do anything, merely because someone
pointed out that Common Lisp already exists?

Pascal Costanza

unread,
Jun 24, 2005, 2:55:05 AM6/24/05
to
Kenny Tilton wrote:
>
> Pascal Costanza wrote:
>
>> Kenny Tilton wrote:
>>
>>> [apologies if this has materialised in similar form or does so soon
>>> unbeknownst to me, but from where I sit it appears Google ate a
>>> similar report posted yesterday via google groups.]
>>>
>>> Dr. McCarthy joined with Henry Baker, his predecessor at the
>>> microphone, in bemoaning the standardization of Common Lisp as
>>> stultifying if not mortifying, in that it ended innovation.
>>
>> As much as I like Common Lisp, I think he has a point here.
>
> Please get back to us when you have some application functionality you
> cannot express in Common Lisp.

...only after you have made sure that you're not implicitly using a
Turing equivalence argument here. ;-P

Pascal Costanza

unread,
Jun 24, 2005, 3:03:25 AM6/24/05
to

That's not what I said.

Pupeno

unread,
Jun 24, 2005, 3:12:08 AM6/24/05
to
Friedrich Dominicus wrote:
> Well exactly that is not the case. Why was there a year 2000 problem?
What problem ? I man, anybody saw the problem (aside from a couple of cobol
prgrams) ?

> Because nobody expected software to survice longer then a few
> years. How many billions of dollars were spend on fixing those
> "could-not-survive-so-long" software.
Well, the money spent in solving the 2kY problem is known to be one of the
biggest wastes on the IT market (has anyone evaluated upgradding-to-XP
yet ?)

> And every standard is just the snapshot in time. How many standards do
> exist for Fortran? How many for C?

personally I see lots of projects without a standard evolve faster than
Common Lisp (Perl, Python, Ruby, PHP). I would be all on the side of
dropping the standard (it doesn't help portability a lot because if you use
multithreading or sockets or one of those things not standarized *yet*, you
are screwed. But, I'm just a newbie.
--
Pupeno <pup...@pupeno.com> (http://pupeno.com)
Reading ? Science Fiction ? http://sfreaders.com.ar

Marcin 'Qrczak' Kowalczyk

unread,
Jun 24, 2005, 3:23:35 AM6/24/05
to
Kenny Tilton <kti...@nyc.rr.com> writes:

> Please get back to us when you have some application functionality you
> cannot express in Common Lisp.

Running two arbitrary threads of Lisp code concurrently can only be
expressed by writing a concurrent Lisp interpreter in Lisp. This is a
lot of work for someone who just wants to use threads.

--
__("< Marcin Kowalczyk
\__/ qrc...@knm.org.pl
^^ http://qrnik.knm.org.pl/~qrczak/

Sashank Varma

unread,
Jun 24, 2005, 3:51:38 AM6/24/05
to
Christopher C. Stacy wrote:

> I'm not sure what you're getting at.
> What is the definition of "progress"?
> New features?
> Is that desirable?

Not in and of itself.

I don't mean "new" features in the sense of "standardizing things that
are not yet standardized in Common Lisp but that are standardized in
other languages," like threads. I actually don't care about this stuff.
I'm happy to use the extensions my particular implentation provides to
interface to mundane services outside of Lisp.

> Besides, I don't see anyone stopping anyone else from
> inventing their own versions of Lisp.

Agreed.

> Seems to me that most of the world haven't even
> caught up to the Lisp ideas from two decades ago.

Agreed. But has Common Lisp the language progressed at all since the
ANS appeared?

I guess this is the real pea under my mattress. Lisp was for the first
three decades of its life a fecund source of new ideas about
programming languages. During this time, the language splintered into
different dialects -- MacLisp, Interlisp, Scheme, Lisp Machine Lisp,
etc. -- but this did not slow the pace of innovation. In fact, it had
the opposite effect.

The problem with many sufficiently diffferent dialects is that porting
code is difficult, so Common Lisp came into being. Soon thereafter,
innovation slowed. Sure, things like Connection Machine Lisp and the
MOP came into existence, but CLtL2 and the ANS seem to have been about
codifying ideas that already existed in one form or another by the mid
1980sw, but did not make it into CLtL1 for political or pragmatic
reasons.

So the question is: Why is Lisp producing fewer programming language
innovations now than it was 25 years ago? One "explanation" is
standardization -- this is what Henry Baker and John McCarthy seemed to
have been saying at the 2005 ILC. However, I think this is just a
coincidence of history. As you say, the ANS does not stop someone from
inventing a new Lisp variant.

> I can't imagine what the point is of whether Lisp
> has "declined", anyway. Perhaps nobody has had
> any super great ideas lately.

This is my great fear. In the Dynamic Language Wizards panel discussion
of a year ago, someone lamented that the current ACM model computer
science curriculum devotes on 5 hours to the study of programming
language design. Guy Steele said maybe this wasn't a bad thing, that
maybe computer science had passed beyond the time when new programming
languages had to be invented on a weekly basis. Maybe we really are at
some kind of language design plateau.

Another possibility is that some other force is holding us back. As
Lispers, the invention of new programming language constructs is our
particular forte. So what's stopping us? Not standardization. What
then?

===

Here is another possible explanation for what I and some others feel: I
was talking with a friend recently while visiting Pittsburgh. She's a
Zen type. I told her that my visit was disorienting because normally I
feel nostalgic when I return to the place where I did my undergraduate
work, but this time was different. She told me that nostalgia is a
distortion, a way of hiding from one's current reality in the myth of
the past. The laments one hears about the slowdown in Lisp's progress
might be just this -- nostalgia.

What's weird is that they are rarely spoken by those who actually lived
through the halcyon days of MIT in the 1970s, Symbolics in the early
1980s, etc. More frequently, they are uttered by (relative) newbies
like myself -- I discovered the language in the spring of 1988 -- who
just missed the golden age of Lisp. It is a second-hand nostalgia we
feel.

Hmmm.

Espen Vestre

unread,
Jun 24, 2005, 4:06:05 AM6/24/05
to
Kenny Tilton <kti...@nyc.rr.com> writes:

> These dinosaurs are cute, but they do not follow cll and they have no
> clue about its recent upopularity upsurge.

I realised that this upsurge is real when I went to the lisp meeting
in Amsterdam this spring and compared it to the ELUGM-99, also in
Amsterdam. ELUGM-99 was a three-day event organized by Franz, ie., you
would think, a much larger event than this years' one-day meeting.
But if I remember right, it had only half the number of attendees
(which we still thought was o.k.).

(I just discovered that the pictures from ELUGM '99 are still
on the Franz Web server:
http://www.franz.com/services/conferences_seminars/ELUGM_Pics/)
--
(espen)

Friedrich Dominicus

unread,
Jun 24, 2005, 4:11:41 AM6/24/05
to
Pupeno <pup...@pupeno.com> writes:

> Friedrich Dominicus wrote:
>> Well exactly that is not the case. Why was there a year 2000 problem?
> What problem ? I man, anybody saw the problem (aside from a couple of cobol
> prgrams) ?
>> Because nobody expected software to survice longer then a few
>> years. How many billions of dollars were spend on fixing those
>> "could-not-survive-so-long" software.
> Well, the money spent in solving the 2kY problem is known to be one of the
> biggest wastes on the IT market (has anyone evaluated upgradding-to-XP
> yet ?)

Well this is statement which I doubt very much. What would have
happened if the money would not have been spend? We don't know because
nobody dared to ignore it. Now let us hope that securitiy gets at
least that much attentoin....

>
>> And every standard is just the snapshot in time. How many standards do
>> exist for Fortran? How many for C?
> personally I see lots of projects without a standard evolve faster than
> Common Lisp (Perl, Python, Ruby, PHP). I would be all on the side of
> dropping the standard (it doesn't help portability a lot because if you use
> multithreading or sockets or one of those things not standarized *yet*, you
> are screwed. But, I'm just a newbie.

Well have you tried to run a Perl 3 program with Perl 5?

Have you read about the trouble going from perl 4 to Perl 5? Why do
you think are those branches still in use? Because most of the people
do not like to rewrite their coded over and over again because if
changes in some implementations.

I have no
problems to compile fifteen year old C programs. And the same is true
for quite some Lisp Code out there which explicity was written to be
portable.

Standards are IMHO on of the sharpest tools the "users" have against
the "vendors". I have seen in at least one other programming language
what happens if the users do not have something like a standard.

And you can see how happily the big ones ignore standards. Just check
the MSVC documentation on the C language.

Of course that is just a problem if you have more then on
implementation. But fortunatly we do have the choice. If you do think
standards are good I suggest you check back to the thread "modern
lisp" mode from Franz.

I would not care as much about standards if backward-compatiblity
would be one on the highest priorites. I just can tell for C and
Common Lisp that at least here I found this high priority. Guess what
Franz even has some library to cope with Flavours!

In a language with such a long history as Lisp, standards are a
blessing.

Tayssir John Gabbour

unread,
Jun 24, 2005, 4:21:52 AM6/24/05
to
Pascal Costanza wrote:
> Major improvements would be new programming paradigms. Imagine something
> like OOP or neural networks didn't exist yet. Lisp has provably shown
> that it is again flexible enough to provide an excellent framework for
> developing new programming approaches.
>
> I think the negative effect of standards is not a real one - noone
> hinders anyone to start even completely from scratch and build
> completely new languages - but a psychological one. Standards induce the
> belief that we have somehow reached a final stage in computer science
> and that we only need to fill a few gaps and fix some annoying details,
> and we're done. I think this is far from the truth.
>
> In the industrial arena, companies like Sun and Microsoft and their
> pseudo-standards are much worse in making people belief that we are
> already "there", and in the acadamic realm, programming language
> theorists are stifling real progress. When real breakthroughs first
> appeared, they have always been useless in practice and unsound in
> theory, and only much later developed into something practical and
> well-understood.
>
> In that regard, standards and standardization hurt.

I'm surprised because it seems almost obvious that standards are there
to put a halt on certain kinds of innovation. One guy who helped out
the standards claimed that CL standardization killed Interlisp:

"Common Lisp as a dialect arose because institutions with a large
investment in Lisp (primarily ARPA, actually, but also some
commercial entitites) were tired of the semantics of Lisp changing
daily and they wanted to be able to invest in something which was
both powerful and stable. My understanding is that they had proposed
Interlisp because it appeared to have the largest installed base,
and this caused the myriad Maclisp-variants to declare that they
differed in only-gratuitous ways which if solidified would constitute
a larger installed base than Interlisp. CL was the result, and
Interlisp was killed."
http://groups-beta.google.com/group/comp.lang.lisp/msg/b525c6d8367c3d4a?hl=en

Further, innovation motive can clearly conflict with the commercial
motive, since some customers don't want to recompile and retest apps
built on evolving platforms. And you almost get proof from Microsoft
who endlessly repeats "innovation" because that's one of its weaknesses
-- customers apparently want solutions far more than tech.

So based on what I read on this thread, it seems odd this would be
controversial if there were old-timers there who could point out what
actually happened. Everytime I hear about the CL standard effort, it
sounds like a pretty violent thing.


Tayssir

Matthias

unread,
Jun 24, 2005, 4:32:02 AM6/24/05
to
Kenny Tilton <kti...@nyc.rr.com> writes:

> [apologies if this has materialised in similar form or does so soon
> unbeknownst to me, but from where I sit it appears Google ate a
> similar report posted yesterday via google groups.]
>
> Dr. McCarthy joined with Henry Baker, his predecessor at the
> microphone, in bemoaning the standardization of Common Lisp as
> stultifying if not mortifying, in that it ended innovation.

Well, other languages were standardized by the same heavyweight
process as CL (C, C++, SQL, Fortran). While these languages sure
evolve slower than Perl/Python/Ruby/etc there is development. The C++
standard is revised and extended every 5 years or so. The current
version of Fortran is from 1995 and I believe there is a revision
process going on right now.

For other languages there is, despite standardization, _no_ guarantee
that 20year old code will run or compile with a current
implementation. Changes to any standard usually break some code (in
the simplest case by introducing a new keyword). So, this notion that
"standard" implies "if my code runs now it will run forever" is wrong.

Paolo Amoroso

unread,
Jun 24, 2005, 4:50:52 AM6/24/05
to
Peter Seibel <pe...@gigamonkeys.com> writes:

> Pascal Costanza <p...@p-cos.net> writes:
[...]


>> As much as I like Common Lisp, I think he has a point here.
>
> As did Baker, or rather a dozen or so good points--can't wait until
> his full slidedeck is available.

Any examples?


Paolo
--
Why Lisp? http://lisp.tech.coop/RtL%20Highlight%20Film
Recommended Common Lisp libraries/tools:
- ASDF/ASDF-INSTALL: system building/installation
- CL-PPCRE: regular expressions
- UFFI: Foreign Function Interface

lin8080

unread,
Jun 24, 2005, 5:00:50 AM6/24/05
to

Sashank Varma schrieb:


> The more general question -- Did standardization produce
> stultification? -- is quite provocative though.

[...]


> This brings up an interesting question: Is the binding constraint of
> the standard, which was critical during the 1980s and 1990s, gonna
> choke the community now that it is again showing signs of growth?

In my oppinion standards are only good for sellers but not for
developers. It is very difficult to do something new only using
standards. So in my trying, i through away any kind of standards. (sure
there are some standards remaining, like a based-on bone-body).

Other viewpoint is that non-standards are hard to manage. They need a
big part of describe and how to use and most of them are case
specialized. (try to teach this, or search for on the web, brrr, see
fortran survive story)

> Another possibility is that the community
> will split in a healthy way, with business users adhering closely to
> the standard in the interests of portability, and with academics again
> experimenting with new features and birthing new dialects.

Instead of making a new dialect, let a module (interface) come in. While
creating a new dialect one is forced to create all kinds of existing
"standarts" too. This is not always a good solution.

It shows the necessary of listening to the users wishes (which takes
some time) and enable them to quick-hack the actual needed tool
(utility), a balance act between using one universal tool or tonnes of
tools-boxes (sometimes this is called scripting).

...
stefan

Carl Shapiro

unread,
Jun 24, 2005, 5:21:42 AM6/24/05
to
Paolo Amoroso <amo...@mclink.it> writes:

> Peter Seibel <pe...@gigamonkeys.com> writes:
>
> > Pascal Costanza <p...@p-cos.net> writes:
> [...]
> >> As much as I like Common Lisp, I think he has a point here.
> >
> > As did Baker, or rather a dozen or so good points--can't wait until
> > his full slidedeck is available.
>
> Any examples?

http://www.international-lisp-conference.org/multimedia/baker-slides.pdf

More material will become available as soon as I collect the slides
and receive permission to distribute it. Same goes for the audio we
recorded during all of the conference tracks.

Paolo Amoroso

unread,
Jun 24, 2005, 5:39:54 AM6/24/05
to
Kenny Tilton <kti...@nyc.rr.com> writes:

> Dr. McCarthy joined with Henry Baker, his predecessor at the
> microphone, in bemoaning the standardization of Common Lisp as
> stultifying if not mortifying, in that it ended innovation.

Okay, let's file this, we will arrange for a vote at ILC 2006:

Issue: COMMON-LISP-STANDARDIZATION-SUCKS

References: ILC 2005

Related issues: STANDARDIZATION-SUCKS

Category: DELETION

Edit history: Version 1, 24-Jun-05 by Paolo Amoroso

Status: For discussion and evaluation; not proposed for
inclusion in the standard at this time.

Problem description:

The standardization of Common Lisp is stultifying if not


mortifying, in that it ended innovation.

Proposal COMMON-LISP-STANDARDIZATION-SUCKS:KILL-STANDARD

Overview:

From http://lispmeister.com/blog/lisp-news/ILC05-rep-1.html:
"If someone was to drop a bomb on this building, it would wipe out
50 percent of the Lisp community. That would probably be a good
thing. It would allow Lisp to start over."

These passages are relevant to or affected by X3J13 Cleanup Issue
COMMON-LISP-STANDARDIZATION-SUCKS:

* The whole ANSI Common Lisp specification

Note: It is possible that there are other passages affected by this
cleanup issue. This list is not part of the specification, and has
not been formally audited for completeness by X3J13.


> * McCarthy actually meant that very little code lasts ten years.

Be sure not to invite McCarthy and VisiCalc co-inventor Dan Bricklin
at the same event:

Software That Lasts 200 Years
http://www.danbricklin.com/200yearsoftware.htm

The structure and culture of a typical prepackaged software company
is not attuned to the long-term needs of society for software that
is part of its infrastructure. This essay discusses the ecosystem
needed for development that better meets those needs.

Message has been deleted

Matthias Buelow

unread,
Jun 24, 2005, 6:27:19 AM6/24/05
to
"Sashank Varma" <sashan...@yahoo.com> writes:

>This is my great fear. In the Dynamic Language Wizards panel discussion
>of a year ago, someone lamented that the current ACM model computer
>science curriculum devotes on 5 hours to the study of programming
>language design. Guy Steele said maybe this wasn't a bad thing, that
>maybe computer science had passed beyond the time when new programming
>languages had to be invented on a weekly basis. Maybe we really are at
>some kind of language design plateau.

Plus, programming language research has moved on to languages more
"fruitful" in theoretical results, i.e., functional languages like ML
and Haskell, with strong type systems, where there are quite a few
open problems still. Perhaps Lisp simply has become too boring for
research with no really interesting problems left? Writing the nth
object system, compiler, or garbage collector or what have you isn't
going to cut it anymore. That's old, well understood stuff by now,
that is, it has moved to mainstream. And you apparently cannot
mathematically formalize a dynamic type system as well as a strict,
inferential one, and this alone would make it quite unattractive for
use in research papers.

mkb.

Espen Vestre

unread,
Jun 24, 2005, 6:34:34 AM6/24/05
to
Kenny Tilton <kti...@nyc.rr.com> writes:

> Anyone with an iota of an experience in production code knows how fast
> systems get swapped out,

Fast? I had to interface to telco systems from the mid-seventies as
late as in 1998.
--
(espen)

Edi Weitz

unread,
Jun 24, 2005, 9:30:13 AM6/24/05
to
On 24 Jun 2005 12:27:19 +0200, Matthias Buelow <m...@incubus.de> wrote:

> Plus, programming language research has moved on to languages more
> "fruitful" in theoretical results, i.e., functional languages like
> ML and Haskell, with strong type systems, where there are quite a
> few open problems still. Perhaps Lisp simply has become too boring
> for research with no really interesting problems left? Writing the
> nth object system, compiler, or garbage collector or what have you
> isn't going to cut it anymore. That's old, well understood stuff by
> now, that is, it has moved to mainstream. And you apparently cannot
> mathematically formalize a dynamic type system as well as a strict,
> inferential one, and this alone would make it quite unattractive for
> use in research papers.

Languages that are "fruitful" in this sense are good for researchers
who have to publish papers or want to write a thesis. That doesn't
necessarily mean they're good for real world applications as well.

Cheers.
Edi.

--

Lisp is not dead, it just smells funny.

Real email: (replace (subseq "spam...@agharta.de" 5) "edi")

Paul F. Dietz

unread,
Jun 24, 2005, 10:04:12 AM6/24/05
to
Sashank Varma wrote:

> This brings up an interesting question: Is the binding constraint of
> the standard, which was critical during the 1980s and 1990s, gonna
> choke the community now that it is again showing signs of growth?

I don't believe it will. Common Lisp has plenty of room
for extension without doing violence to the current standard,
and the flaws I see in the current standard can be tolerated
or surmounted, IMO. The bigger question in my mind is whether
the current organization of the lisp community will allow
concensus to be reached on these extensions.

Paul

Kenny Tilton

unread,
Jun 24, 2005, 10:03:33 AM6/24/05
to

Christopher C. Stacy wrote:
> Kenny Tilton <kti...@nyc.rr.com> writes:
>
>
>>Christopher C. Stacy wrote:
>>
>>
>>>Kenny Tilton <kti...@nyc.rr.com> writes:
>>>
>>>
>>>>* McCarthy actually meant that very little code lasts ten years.
>>>
>>>That would suggest a serious disconnect with reality;
>>>it's a little hard to believe.
>>
>>Oh. please. You have no knowledge or experience of production code.
>
>
> I've been delivering production code since about 1976,

Then you know that bad systems get thrown out and good systems change
over time because requirements change over time. If they are being
thrown out, there you go. If they are being revised, there you go: a
substantial new effort in which any change to the language probably only
helps by making the language more expressive. This is the same reason
that code quality matters and the fact code works does not: any
successful system grows to take on new functionality and at least lasts
long enough to see requirements change. Good code means it will see more
work.

Kenny Tilton

unread,
Jun 24, 2005, 10:12:44 AM6/24/05
to

Pascal Costanza wrote:

> Kenny Tilton wrote:
>
>>
>> Pascal Costanza wrote:
>>
>>> Kenny Tilton wrote:
>>>
>>>> [apologies if this has materialised in similar form or does so soon
>>>> unbeknownst to me, but from where I sit it appears Google ate a
>>>> similar report posted yesterday via google groups.]
>>>>
>>>> Dr. McCarthy joined with Henry Baker, his predecessor at the
>>>> microphone, in bemoaning the standardization of Common Lisp as
>>>> stultifying if not mortifying, in that it ended innovation.
>>>
>>>
>>> As much as I like Common Lisp, I think he has a point here.
>>
>>
>> Please get back to us when you have some application functionality you
>> cannot express in Common Lisp.
>
>
> ...only after you have made sure that you're not implicitly using a
> Turing equivalence argument here. ;-P

Nope. Fire away. But I /am/ armed with DEFMACRO, so get those shields up. :)

Kenny Tilton

unread,
Jun 24, 2005, 10:18:02 AM6/24/05
to

Espen Vestre wrote:

> Kenny Tilton <kti...@nyc.rr.com> writes:
>
>
>>These dinosaurs are cute, but they do not follow cll and they have no
>>clue about its recent upopularity upsurge.
>
>
> I realised that this upsurge is real when I went to the lisp meeting
> in Amsterdam this spring and compared it to the ELUGM-99, also in
> Amsterdam. ELUGM-99 was a three-day event organized by Franz, ie., you
> would think, a much larger event than this years' one-day meeting.
> But if I remember right, it had only half the number of attendees
> (which we still thought was o.k.).

yeah, one of the great reasons for going to a conference is being
surrounded by dozens of people actively using Lisp and the consequent
morale boost.

The ALU should send an email to all the attendees: "If you do not know
CL is winning, Kenny says read c.l.l. every day and cheer up."

Ulrich Hobelmann

unread,
Jun 24, 2005, 10:29:50 AM6/24/05
to
Pupeno wrote:
> personally I see lots of projects without a standard evolve faster than
> Common Lisp (Perl, Python, Ruby, PHP). I would be all on the side of
> dropping the standard (it doesn't help portability a lot because if you use
> multithreading or sockets or one of those things not standarized *yet*, you
> are screwed. But, I'm just a newbie.

Then have fun porting your stuff from PHP3 to 4, and now to PHP5 etc.

I'm happy I never used those languages!

--
Don't let school interfere with your education. -- Mark Twain

Kenny Tilton

unread,
Jun 24, 2005, 10:32:00 AM6/24/05
to

Espen Vestre wrote:

<g> Look, guys, you cannot win! In some cases these systems are just
running the same binary. Hell, the source has likely been lost. So the
larger point of "let languages evolve continually" stands. If these apps
/are/ being changed or at least recompiled, well, someone either was
bright enough to keep the /compiler/ binaries around, or the evolution
of the language has not made it impossible to run systems for twenty
years-- what language has not evolved since the seventies or even
eighties? Even COBOL has changed a lot over the years, and I seem to
recall dragging my C system across more than one interesting development
in thet tiny language.

Espen Vestre

unread,
Jun 24, 2005, 10:33:01 AM6/24/05
to
Ulrich Hobelmann <u.hob...@web.de> writes:

> Then have fun porting your stuff from PHP3 to 4, and now to PHP5 etc.
>
> I'm happy I never used those languages!

Oouch. Now you reminded me of the painful first 5.* versions of perl.
Some of the 0.01 versions were like completely new languages :-(
--
(espen)

Espen Vestre

unread,
Jun 24, 2005, 10:42:44 AM6/24/05
to
Kenny Tilton <kti...@nyc.rr.com> writes:

> <g> Look, guys, you cannot win! In some cases these systems are just
> running the same binary. Hell, the source has likely been lost. So the
> larger point of "let languages evolve continually" stands.

Well, I take your point, and partially agree. However, if you
introduce the kind of backwards incompatiblity that perl was plagued
with in the 5.0.* versions (5.0.3? I can't remember, must be my
selective memory :)), you're creating a mess, especially for a
language like perl where you have to keep umpteen versions of the
interpreter around for all those little scripts that you never will
have time to upgrade to the next 0.01 version.

I agree that large systems usually will be maintained all the time, so
most reasonable incremental changes to the language will be easy to
adapt to, since you're upgrading your development tools anyway (I
guess that seventies telco system was compiled with a much more recent
cobol implementation than the one used by the original developers...).
--
(espen)

Peter Seibel

unread,
Jun 24, 2005, 11:03:01 AM6/24/05
to
Matthias Buelow <m...@incubus.de> writes:

Well, there are other avenues of research. Much of what Baker talked
about at the just-completed ILC were things that would fall in the
domain of programming language user interface. Which *is* an area
where Lisp has historically been both strong and a source of
innovation. Indeed, one of Baker's big points was that when the Lisp
community came to the fork in the road between Interlisp (with it's
structure editor) and Maclisp (with programs ultimately stored as text
in files), they made a mistake by taking the Maclisp fork. I don't
know if can get a PhD in computer science for coming up with a better
tool for programmers (as opposed to a better mathamatical basis for
proving things about computation) but I do agree with Baker that there
are still improvements to be made in how programmers interact with
their programs.

-Peter

--
Peter Seibel * pe...@gigamonkeys.com
Gigamonkeys Consulting * http://www.gigamonkeys.com/
Practical Common Lisp * http://www.gigamonkeys.com/book/

alex goldman

unread,
Jun 24, 2005, 11:11:18 AM6/24/05
to
Peter Seibel wrote:

> Interlisp (with it's
> structure editor)

What's that structure editor? I'd like to see some screenshots, or play with
it.

Wade Humeniuk

unread,
Jun 24, 2005, 11:23:58 AM6/24/05
to
Sashank Varma wrote:
>
> This is my great fear. In the Dynamic Language Wizards panel discussion
> of a year ago, someone lamented that the current ACM model computer
> science curriculum devotes on 5 hours to the study of programming
> language design. Guy Steele said maybe this wasn't a bad thing, that
> maybe computer science had passed beyond the time when new programming
> languages had to be invented on a weekly basis. Maybe we really are at
> some kind of language design plateau.
>

Yes we are at a plateau. If you want a new label for where computer
languages are at, its, "The Age of Libraries". Its what the industry
and programmers fret about. Where are the libraries? I cannot do
anything without a "standard library"! And to be frank, NO amount
of programming language innovation will solve the "library" problem.

Language design is dead, dead, dead because its been taken over by
pseudo-programming language vocabularies (i.e natural language).
Its the "standardization" by imprecise-human-language-and-thought
that has slowed down any innovation. Its not the CL syntax or the
individual built-in functions of the ANSI CL spec that has slowed
things down, its the implicit higher level organization in the
spec which has slowed down things (like, the condition system, the breakdown
of various phases of the compilation process, the concept of the
sequence). These are powerful and attractive ideas that cements one's
thinking.

> Another possibility is that some other force is holding us back. As
> Lispers, the invention of new programming language constructs is our
> particular forte. So what's stopping us? Not standardization. What
> then?
>

Its reality that is holding people back, like I said above, no amount
of new programming language constructs will help out the concerns of
the computer industry.

If you want one thing holding back innovation its the anthropomorphizing
of the computer.

Wade

Peter Seibel

unread,
Jun 24, 2005, 11:32:25 AM6/24/05
to
Paolo Amoroso <amo...@mclink.it> writes:

> Peter Seibel <pe...@gigamonkeys.com> writes:
>
>> Pascal Costanza <p...@p-cos.net> writes:
> [...]
>>> As much as I like Common Lisp, I think he has a point here.
>>
>> As did Baker, or rather a dozen or so good points--can't wait until
>> his full slidedeck is available.
>
> Any examples?

So despite Kenny's scoffing I haven't yet seen an environment that
makes it as easy (and accurate) as it ought to be to change the names
of things. Apparently the refactoring browser for Smalltalk was pretty
good but I've never actually seen it in action. And some of the newer
Java tools such as Eclipse can sort of do it but two slowly and not
accurately enough in my brief (and recent) experience.

I also have been thinking along similar lines as Baker about the need
to integrate tests with the code they test and I'm not imposed to the
idea of the language environment using type checking to help me find
bugs in my code as long as it's like a butler rather than a
dominattrix--who was it (Baker?) who drew the distinction between
"strong" and "strong-armed" type checking?

I also like the idea of being able to inline and uninline functions
easily.

That said, I'm not sure I understood what Baker's problem with dynamic
variables was. They're definitely on my list of "important Lisp
features".

Okay, so that wasn't really a dozen. But there a bunch of things on
his other slides that are at least food for thought.

alex goldman

unread,
Jun 24, 2005, 11:47:27 AM6/24/05
to
Peter Seibel wrote:

> That said, I'm not sure I understood what Baker's problem with dynamic
> variables was. They're definitely on my list of "important Lisp
> features"

As Paolo would put it, "you may learn Scheme" :-)

Kirk Job Sluder

unread,
Jun 24, 2005, 12:07:34 PM6/24/05
to
Pupeno <pup...@pupeno.com> writes:

> Friedrich Dominicus wrote:
> personally I see lots of projects without a standard evolve faster than
> Common Lisp (Perl, Python, Ruby, PHP). I would be all on the side of
> dropping the standard (it doesn't help portability a lot because if you use
> multithreading or sockets or one of those things not standarized *yet*, you
> are screwed. But, I'm just a newbie.

Well, I would argue that these languages do have de-facto
standardization due to the fact that one distribution dominates. Almost
all python projects use cpython which so far has made some effort to
maintain backwards compatibility. (This might change with version 3.)
Perl5 likewise is a de-facto standard.

> --
> Pupeno <pup...@pupeno.com> (http://pupeno.com)
> Reading ? Science Fiction ? http://sfreaders.com.ar

--
Kirk Job-Sluder
"The square-jawed homunculi of Tommy Hilfinger ads make every day an
existential holocaust." --Scary Go Round

Christopher C. Stacy

unread,
Jun 24, 2005, 12:10:52 PM6/24/05
to
Espen Vestre <es...@vestre.net> writes:

2000, here.

Christopher C. Stacy

unread,
Jun 24, 2005, 12:11:49 PM6/24/05
to
Kenny Tilton <kti...@nyc.rr.com> writes:

> Christopher C. Stacy wrote:
> > Kenny Tilton <kti...@nyc.rr.com> writes:
> >
> >>Christopher C. Stacy wrote:
> >>
> >>
> >>>Kenny Tilton <kti...@nyc.rr.com> writes:
> >>>
> >>>
> >>>>* McCarthy actually meant that very little code lasts ten years.
> >>>
> >>>That would suggest a serious disconnect with reality;
> >>>it's a little hard to believe.
> >>
> >>Oh. please. You have no knowledge or experience of production code.
> > I've been delivering production code since about 1976,
>
> Then you know that bad systems get thrown out

Remind me which planet you're from, again?

Onay Urfalioglu

unread,
Jun 24, 2005, 12:24:28 PM6/24/05
to
Kenny Tilton wrote:

> [apologies if this has materialised in similar form or does so soon
> unbeknownst to me, but from where I sit it appears Google ate a similar
> report posted yesterday via google groups.]
>
> Dr. McCarthy joined with Henry Baker, his predecessor at the microphone,
> in bemoaning the standardization of Common Lisp as stultifying if not
> mortifying, in that it ended innovation.
>

> When rahul defended standardization as allowing his code to run ten
> years from now, McCarthy indicated that (paraphrasing) by the looks of
> Rahul it was unlikely he would produce code that anyone would want to
> run ten years from now.*
>
> XML had the honor of having McCarthy stop in the middle of a meandering
> bit of reflection to mention how much he disliked XML.
>
> And when your correspondent asked why he had chosen such a crappy name
> for such a great language and whether he regretted, in what is becoming
> an annual rite of humiliation, he pretty much ignored my question, but
> did mention that his preference had been FLPL, for Fortran List
> Processing Language, because he liked Fortran.
>
> Intriguingly, there is a Fortran package with that exact name and
> acronym and function, created in 1960 as far as I can make out from some
> light googling.


>
> * McCarthy actually meant that very little code lasts ten years.
>

If there were only ONE CL-implementation, there would be no requirement for
a standard... this would lead to

* a much higher quality codebase since much bigger user base
* more and more bugfree extensions and libraries
* each extension, once accepted, would be a de facto standard automatically
since there is only one impl.
* an overall speedup of development and progress of CL itself since all
developers would HAVE TO work TOGETHER (in harmony)


IMO, this is one of the strength of PL like Python, Ruby ....


Kenny Tilton

unread,
Jun 24, 2005, 12:31:51 PM6/24/05
to

One where "system life cycle" includes death.

Matthias Buelow

unread,
Jun 24, 2005, 12:58:30 PM6/24/05
to
Onay Urfalioglu <on...@gmx.net> writes:

>If there were only ONE CL-implementation, there would be no requirement for
>a standard... this would lead to

[...]

IMHO there're two models. The python/perl/ruby etc. model lends itself
to hobbyist, amateur and general "hackish" programming (in the
positive sense). While fixed standards benefit industrial programming
and the development of large systems by large teams, over several
years, especially when several high-quality, commercial
implementations are available. With standards comes planning security
and choice (of competing vendors), something that is more important in
an industrial environment than neat features of a single
implementation.

mkb.

GP lisper

unread,
Jun 24, 2005, 1:06:24 PM6/24/05
to
On Fri, 24 Jun 2005 08:38:37 +0200, <just-for-...@q-software-solutions.de> wrote:
>
> Well exactly that is not the case. Why was there a year 2000 problem?

Y2K was the biggest joke of the century. Really showed how poor the
educational system is nowdays, and how willingly people believe that
burning money fixes the world. The wolves separated many $$ from the
sheep with that one.


NEXT UP: The "666 problem" AKA June 6, 2006. lol

GP lisper

unread,
Jun 24, 2005, 1:14:23 PM6/24/05
to


This is exactly what McCarthy was arguing FOR. But it wasn't an
audience from the ivory tower, it was an audience that either made
money from lisp or wanted to do so. The ivory tower works off of
publishing papers, big changes give them more opportunities for
papers. Not the right audience for that point.


"Elephants never forget"

Elephants are trained at a young age with a heavy, unbreakable chain
tying them down. They strain against it for a long time, then stop
and never try again. Afterwards they can be bound with a rope.

'never forgetting' is not how humans operate, funny thing to hear from
a 'human-class AI proponent'.

--
The LOOP construct is really neat, it's got a lot of knobs to turn!
Don't push the yellow one on the bottom.

Jens Axel Søgaard

unread,
Jun 24, 2005, 1:18:21 PM6/24/05
to
Peter Seibel wrote:

> So despite Kenny's scoffing I haven't yet seen an environment that
> makes it as easy (and accurate) as it ought to be to change the names
> of things.

Do you know the syntax-checker tool in DrScheme?

When you click the "syntax-check" button the tool internally
expands the source code and figures out with variables is
bound where.

Now moving the mouse over a binding instance of variable will
overlay arrows to the bound instances. Right clicking in the
binding instance reveals a rename menu item that will rename
the binding instance and all bound instances.

The third screenshot of

<http://www.plt-scheme.org/software/drscheme/tour/tour-Z-H-12.html>

shows the overlayed arrows.

For better screen shots see:

<http://www.ccs.neu.edu/scheme/pubs/jfp01-fcffksf.ps>

--
Jens Axel Søgaard

Pascal Bourguignon

unread,
Jun 24, 2005, 1:23:36 PM6/24/05
to
cst...@news.dtpq.com (Christopher C. Stacy) writes:

> Kenny Tilton <kti...@nyc.rr.com> writes:
>> * McCarthy actually meant that very little code lasts ten years.
>
> That would suggest a serious disconnect with reality;
> it's a little hard to believe.

Indeed, code lasts much longer.
Some _development_ _projects_ last longer!
It would not be too good if you had to rewrite these big project
entirely before they're even finished.


However, it's possible that the only stultifying feature of Common
Lisp is the command that "Thou shalt not modify the definition of
COMMON-LISP symbols".

But since it's is not too difficult to modify the behavior of Common
Lisp just defining a new package in which the modified functions are
defined and from which they're exported, why don't we see more
packages using some of these extended lisp package instead of
COMMON-LISP?


(defpackage "EXPERIMENTAL-LISP-USER"
(:use "EXPERIMENTAL-LISP"))
(in-package "EXPERIMENTAL-LISP-USER")

(defun fact (n)
(specified-as
(= (fact 0) 1)
(= (fact n) (* n (fact (1- n))))))


In conclusion, I bet you've just been prey of Pr. McCarthy's humor sense.


--
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
A: Top-posting.
Q: What is the most annoying thing on usenet and in e-mail?
__Pascal Bourguignon__ http://www.informatimago.com/

Peter Seibel

unread,
Jun 24, 2005, 1:28:45 PM6/24/05
to
Jens Axel Søgaard <use...@soegaard.net> writes:

> Peter Seibel wrote:
>
>> So despite Kenny's scoffing I haven't yet seen an environment that
>> makes it as easy (and accurate) as it ought to be to change the names
>> of things.
>
> Do you know the syntax-checker tool in DrScheme?
>
> When you click the "syntax-check" button the tool internally
> expands the source code and figures out with variables is
> bound where.
>
> Now moving the mouse over a binding instance of variable will
> overlay arrows to the bound instances. Right clicking in the
> binding instance reveals a rename menu item that will rename
> the binding instance and all bound instances.

I have to admit that I've installed PLT Scheme several times and poked
at it a bit but never really got deeply into it. I'll move it up a bit
on my list of things to check out. Thanks.

GP lisper

unread,
Jun 24, 2005, 1:25:11 PM6/24/05
to
On Fri, 24 Jun 2005 09:23:35 +0200, <qrc...@knm.org.pl> wrote:
> Kenny Tilton <kti...@nyc.rr.com> writes:
>
>> Please get back to us when you have some application functionality you
>> cannot express in Common Lisp.
>
> Running two arbitrary threads of Lisp code concurrently can only be
> expressed by writing a concurrent Lisp interpreter in Lisp. This is a
> lot of work for someone who just wants to use threads.

Isn't it more than merely an interpreter? You want this setup because
you want shared objects, so what happens when one thread no longer
references an object?

If it was easy, it would be done by now. Generally people find that
threads are a nice idea for someone else.

GP lisper

unread,
Jun 24, 2005, 1:20:48 PM6/24/05
to
On 24 Jun 2005 11:21:43 +0100, <ing...@hexapodia.net> wrote:
>
> Kenny Tilton <kti...@nyc.rr.com> writes:
>
> [ SNIP ]

>> Anyone with an iota of an experience in production code knows how fast
>> systems get swapped out, and that was the trivial yet telling point
>> McCarthy made in teasing Rahul and that particular defense of
>> standardization.
>
> Anyone with experience of production code? My experience is taht
> anything taht gets instaleld runs until the circumstyacnes have
> changed enough that it is no longer viable keeping the code in
> production. I saw PDP-11 machines running physiological monitors as
> late as 1992, but they were scheduled for throwing out, not because
> the code (about 12 years old at that point) was bad or that massive
> advancements in sensors had been done in the last 12 years, but
> because it was at a point that the hardware itself was no longer
> sensibly supportable.

That is the routine in a money-poor enviroment. A money-rich
enviroment, such as a trading floor, adopts new tech the moment that a
potential gain exists.

Pascal Costanza

unread,
Jun 24, 2005, 1:36:00 PM6/24/05
to
Kenny Tilton wrote:
>
> Pascal Costanza wrote:
>
>> Kenny Tilton wrote:
>>>
>>> Please get back to us when you have some application functionality
>>> you cannot express in Common Lisp.
>>
>> ...only after you have made sure that you're not implicitly using a
>> Turing equivalence argument here. ;-P
>
> Nope. Fire away. But I /am/ armed with DEFMACRO, so get those shields
> up. :)

Oh, so you _are_ using a Turing equivalence argument. ;)

To put it like this: I am interested in the kinds of macros that noone
has written yet.


Pascal

--
2nd European Lisp and Scheme Workshop
July 26 - Glasgow, Scotland - co-located with ECOOP 2005
http://lisp-ecoop05.bknr.net/

Jens Axel Søgaard

unread,
Jun 24, 2005, 1:42:39 PM6/24/05
to
Jens Axel Søgaard wrote:
> When you click the "syntax-check" button the tool internally
> expands the source code and figures out with variables is
> bound where.
>
> Now moving the mouse over a binding instance of variable will
> overlay arrows to the bound instances. Right clicking in the
> binding instance reveals a rename menu item that will rename
> the binding instance and all bound instances.

I forgot:

Moving the mouse over an bound instance will make the IDE
overlay an arrow to the binding instance. Right clicking
will give you an option to "jump to binding instance".
This is quite handy when the binding instance isn't nearby,
say at the top of the source or in a another module.

--
Jens Axel Søgaard

Pupeno

unread,
Jun 24, 2005, 1:42:44 PM6/24/05
to
Tayssir John Gabbour wrote:
> Further, innovation motive can clearly conflict with the commercial
> motive, since some customers don't want to recompile and retest apps
> built on evolving platforms. And you almost get proof from Microsoft
> who endlessly repeats "innovation" because that's one of its weaknesses
> -- customers apparently want solutions far more than tech.

I can understand that and put in that way it makes sense, but there are
languages that are not governed by an standard which although than are more
primitive than Lisp (or Common Lisp) they are evolving faster and may
eventually reach CL levels (which of course, where reached by CL years
ago).
My examples are PHP, Python, Perl, Ruby. They are instead governed by the
single-implementation (dictatorship if you want) and when other
implementations appear, they just follow the main one.
And if we do the industry comparition, well any of those languages (Ruby
maybe not) seem to be used more than CL. So if the lack of a standard is
harmfull, it should be very harmful for them. And I don't really see an
industry claiming for a Python or PHP or Perl standard.
If we talk about portability, I'm more confident that my Python or PHP code
will run on other platforms (same implementation though) than that my CL
code would run on another platform (where I may encounter a different
implementation).
Having said that someone could argue that nobody is stopped anyone to start
a new Lisp governed by implementation instead of standard. True, but nobody
is doing in seriously either (there are only toy implementations that are
not CL, or othres like Scheme, elisp, etc). If there is, please tell me, I
am interested. The only reason I am not doing it myself is because I don't
know how (something which may change eventually, for which I already
started talking notes).
To not make just a rant I invite all of those that are here claiming that
the standard is harmfull to start another implementation not governed by
the standard (yes, I'd help, as much as I can, which might not be much
now).

Pascal Bourguignon

unread,
Jun 24, 2005, 1:44:41 PM6/24/05
to
Paolo Amoroso <amo...@mclink.it> writes:
> Be sure not to invite McCarthy and VisiCalc co-inventor Dan Bricklin
> at the same event:
>
> Software That Lasts 200 Years
> http://www.danbricklin.com/200yearsoftware.htm
>
> The structure and culture of a typical prepackaged software company
> is not attuned to the long-term needs of society for software that
> is part of its infrastructure. This essay discusses the ecosystem
> needed for development that better meets those needs.

JVM is a good step toward long-term survival of (Java) software.
Hardware will change, but a simple virtual machine is all you need to
keep your software running.
Perhaps all software should always run on a virtual machine.

The survival of lisp software would be improved if more
implementations used a lisp virtual machine.
Look how openmcl became caduc on June 6th ;-)
Or how OpenGenera is insignificant for lack of Alpha processors.


--
__Pascal Bourguignon__ http://www.informatimago.com/
Cats meow out of angst
"Thumbs! If only we had thumbs!
We could break so much!"

Zaninsk

unread,
Jun 24, 2005, 1:57:56 PM6/24/05
to

> JVM is a good step toward long-term survival of (Java) software.
> Hardware will change, but a simple virtual machine is all you need to
> keep your software running.
> Perhaps all software should always run on a virtual machine.
>
> The survival of lisp software would be improved if more
> implementations used a lisp virtual machine.
> Look how openmcl became caduc on June 6th ;-)
> Or how OpenGenera is insignificant for lack of Alpha processors.
>

Yes but if you are serious about performance you'll likely implement a JIT
engine for X, Y, Z processor. Why not cut out the midle man and compile
directly to your real machine? If performance is not a point then yes,
virtual machines are a good advantage.


Pupeno

unread,
Jun 24, 2005, 2:01:45 PM6/24/05
to
As I said in another message: yes, ok, you are rigth, but then, I can't
understand why Python er Perl is much used on the industry than Lisp (maybe
I'm seeing a different industry than you). The industry I see is not so
worried in the long term problem (be it that bad er good) but in the Just
Work(tm) part, or the amount of libraries, or amount of documentation. For
example if I want a web application server for Python, the answer is Zope,
which just runs on Windows, MacOS X and almost all other variations of
Unix, Linux, BSD. If I tell my boss: "oh there's a solution A for doing B
en CL, but it is developed and run on OpenCML, we just first check if it'd
work on our current deployed SBCL on Linux, and maybe port it if necessary"
my boss will ge crazy and conclude that this is not the way (and I kinda
agree with him). At the companies where I worked we never worried about ten
years from now or running our code on a different platform (we were doing
mainly server things) but we did worry a lot about how hard was to use
others code (like libraries).
Thanks.

Pupeno

unread,
Jun 24, 2005, 2:13:55 PM6/24/05
to
Ulrich Hobelmann wrote:

> Pupeno wrote:
>> personally I see lots of projects without a standard evolve faster than
>> Common Lisp (Perl, Python, Ruby, PHP). I would be all on the side of
>> dropping the standard (it doesn't help portability a lot because if you
>> use multithreading or sockets or one of those things not standarized
>> *yet*, you are screwed. But, I'm just a newbie.
>

> Then have fun porting your stuff from PHP3 to 4, and now to PHP5 etc.

As PHP developer I preeffer to port stuff to PHP 5 and gain a better object
model than continue to use PHP 4.

> I'm happy I never used those languages!

You are lucky, for me, they are the only source of income.

Pupeno

unread,
Jun 24, 2005, 2:32:10 PM6/24/05
to
Kirk Job Sluder wrote:
> Well, I would argue that these languages do have de-facto
> standardization due to the fact that one distribution dominates. Almost
> all python projects use cpython which so far has made some effort to
> maintain backwards compatibility. (This might change with version 3.)
> Perl5 likewise is a de-facto standard.
Yes, I agree and it was discussed on other sub-threads. My point is that *I*
prefeer the model of one-implementation/de-facto-standard than the ANSI
model.

Matthias Buelow

unread,
Jun 24, 2005, 2:35:23 PM6/24/05
to
Pupeno <pup...@pupeno.com> writes:

>As I said in another message: yes, ok, you are rigth, but then, I can't
>understand why Python er Perl is much used on the industry than Lisp (maybe
>I'm seeing a different industry than you). The industry I see is not so
>worried in the long term problem (be it that bad er good) but in the Just
>Work(tm) part, or the amount of libraries, or amount of documentation. For

Well, it is my impression that Perl and Python are restricted to the
scripting and glue-language role, or for one-shot hacks. I'd doubt
that someone would chose Perl for a traffic routing or telecom
switching system, or somesuch, typically projects which take years in
the making and occupy larger programmer teams. It's here where
standards are beneficial (or pseudo-standards like with Sun acting as
a de-facto standards body for Java).

mkb.

Matthias Buelow

unread,
Jun 24, 2005, 2:41:28 PM6/24/05
to
Pupeno <pup...@pupeno.com> writes:

>Yes, I agree and it was discussed on other sub-threads. My point is that *I*
>prefeer the model of one-implementation/de-facto-standard than the ANSI
>model.

I don't think that python and perl constitute de-facto standards at
all, since even for a de-facto standard, you have to consider
long-term feature stability, long, well defined standardization
cycles, accountability and the existence of alternative providers. If
van Rossum and whoever runs Perl these days desire to change their
languages completely, who's going to stop them? Contrast that with
Sun, who basically are constrained by their large customer base, and
are actually providing a de-facto standard (which other vendors, like
IBM, are following). I think there's a difference in quality here,
about what constitutes a de-facto standard, and what is "just" a
single implementation.

mkb.

Pupeno

unread,
Jun 24, 2005, 2:42:53 PM6/24/05
to
Matthias Buelow wrote:
> Well, it is my impression that Perl and Python are restricted to the
> scripting and glue-language role, or for one-shot hacks. I'd doubt
> that someone would chose Perl for a traffic routing or telecom
> switching system, or somesuch, typically projects which take years in
> the making and occupy larger programmer teams. It's here where
> standards are beneficial (or pseudo-standards like with Sun acting as
> a de-facto standards body for Java).
As I said, I way be seeing a different industry that you (because where I am
located none of these developments ever happen).

Kirk Job Sluder

unread,
Jun 24, 2005, 2:47:34 PM6/24/05
to
Pupeno <pup...@pupeno.com> writes:
> As I said in another message: yes, ok, you are rigth, but then, I can't
> understand why Python er Perl is much used on the industry than Lisp (maybe
> I'm seeing a different industry than you).

Well, I think a lot of it has to do with historical evolution. Perl was
written in such a way that it could be easily adopted by people
experienced with Bourne, sed and awk. The expansion of regular
expressions also helped. This led to its quick adoption as the system
administration scripting language to be used after Bourne and bash. So
in a rather quick period of time, there was a pretty large volume of
perl scripts running around.

So perl was, in many ways, the right language for a large number of
tasks, at the right place, in the right time of UNIX systems
development, and built on earlier systems.

Later on, the limitations and redundancy of perl became a problem.
Meanwhile, you have this large base of education and industry using
"object oriented" as a buzzword, and perl's object orientation was not
up to the task. So then, cpython and ruby entered the scene as
"scripting languages" with a strong "object oriented" approach to
design, and similarities to C++ and java.

I don't think that the standardization is as much of a problem. After
all, C, (and I think C++) are also both ANSI standardized. And yet, we
still see tons of innovative development built on C and C++
libraries. To my memory those standards are pretty minimal, with many of
the issues discussed in this thread bootstrapped from a core of the
language.

Rainer Joswig

unread,
Jun 24, 2005, 2:50:16 PM6/24/05
to
In article <d9hhpd$kbn$1...@domitilla.aioe.org>,
Pupeno <pup...@pupeno.com> wrote:

> Matthias Buelow wrote:
> > Onay Urfalioglu <on...@gmx.net> writes:
> >
> >>If there were only ONE CL-implementation, there would be no requirement
> >>for a standard... this would lead to
> > [...]
> >
> > IMHO there're two models. The python/perl/ruby etc. model lends itself
> > to hobbyist, amateur and general "hackish" programming (in the
> > positive sense). While fixed standards benefit industrial programming
> > and the development of large systems by large teams, over several
> > years, especially when several high-quality, commercial
> > implementations are available. With standards comes planning security
> > and choice (of competing vendors), something that is more important in
> > an industrial environment than neat features of a single
> > implementation.
> As I said in another message: yes, ok, you are rigth, but then, I can't
> understand why Python er Perl is much used on the industry than Lisp (maybe
> I'm seeing a different industry than you).

Cars are more used than trucks.

CL and Python are very different. Different purpose, different audience, ...

Tayssir John Gabbour

unread,
Jun 24, 2005, 4:26:12 PM6/24/05
to
Pupeno wrote:
> Tayssir John Gabbour wrote:
> > Further, innovation motive can clearly conflict with the commercial
> > motive, since some customers don't want to recompile and retest apps
> > built on evolving platforms. And you almost get proof from Microsoft
> > who endlessly repeats "innovation" because that's one of its weaknesses
> > -- customers apparently want solutions far more than tech.
>
> Having said that someone could argue that nobody is stopped anyone to start
> a new Lisp governed by implementation instead of standard. True, but nobody
> is doing in seriously either (there are only toy implementations that are
> not CL, or othres like Scheme, elisp, etc). If there is, please tell me, I
> am interested. The only reason I am not doing it myself is because I don't
> know how (something which may change eventually, for which I already
> started talking notes).
> To not make just a rant I invite all of those that are here claiming that
> the standard is harmfull to start another implementation not governed by
> the standard (yes, I'd help, as much as I can, which might not be much
> now).

The assumption though is that people care about innovation. ;) But some
people don't.

It is like the notion of "strength." Regular expressions are not very
strong, but are often used in preference to stronger languages.
Strength and innovation do not necessarily mean better. Sometimes it
means worse.

Now, looking at Henry Baker's slides, it may appear that the loss of
innovation is bad. But that doesn't mean we have to do anything. It's
just a historical datapoint. If you're in a position to do something
about it, as with say Erlisp and Qi, great.

Many things in the world are suboptimal. I'm grateful that someone like
Baker pointed out the suboptimality of Common Lisp, as it takes unusual
honesty and even courage.


Tayssir

Jimka

unread,
Jun 24, 2005, 5:03:33 PM6/24/05
to
Unfortunately far too much code stays around for a lot longer than 10
years. It is usually the code that should have been rewritten a long
time ago.

Matthew D Swank

unread,
Jun 24, 2005, 5:04:10 PM6/24/05
to
On Fri, 24 Jun 2005 20:50:16 +0200, Rainer Joswig wrote:

>
> CL and Python are very different. Different purpose, different audience, ...
>

Though it sounds like McCarthy is not in CL's audience (anymore), and
perhaps (with respect to Python) neither is Peter Norvig.

Matt
--
"You do not really understand something unless you can
explain it to your grandmother." — Albert Einstein.

Fred Gilham

unread,
Jun 24, 2005, 5:17:36 PM6/24/05
to

alex goldman <he...@spamm.er> writes:

> Peter Seibel wrote:
>
> > Interlisp (with it's
> > structure editor)
>
> What's that structure editor? I'd like to see some screenshots, or
> play with it.

Look for the LFG system, which runs using the ENVOS Interlisp
implementation. Here's the link to their page. Look for the LFG
software on this page.

http://www2.parc.com/istl/groups/nltt/medley/

Once you get this running, get an Interlisp lisp listener and type
(SEDIT:SEDIT). At this point you will become completely lost. This
means you did everything right so far. You will be unable to do
anything until you find some documentation. I'm sure there's some out
there somewhere.

--
Fred Gilham gil...@csl.sri.com
The PTPL (People's Trotskyist Programming League) believes that
hackers are elitist and that all software should be created by the
masses flailing away at millions of keyboards. I didn't have the
heart to tell them that this has already been tried and the result is
called Linux.

lin8080

unread,
Jun 24, 2005, 5:45:25 PM6/24/05
to

Sashank Varma schrieb:

> Another possibility is that some other force is holding us back. As
> Lispers, the invention of new programming language constructs is our
> particular forte. So what's stopping us? Not standardization. What
> then?

The correct answer is: Lisp is a secret weapon.

Remember, once Apple had a very fast machine (guess it was G5), and soon
something unexpected happend (no export). Or, in May 2005 mathematics
celebrate a new record, RSA200 was defined (200 digits prim), but the
secret was, a us-firm had done this long before. So, as they say, this
age is called "Informations Age", and what is the best way to collect
infos? (ask goggle (aha, they do something new)).

Again. Lisp is a secret weapon. Better keep an eye on that, right?

stefan

not enough? this thread has too many postings, eh?

lin8080

unread,
Jun 24, 2005, 6:49:57 PM6/24/05
to

Onay Urfalioglu schrieb:


> If there were only ONE CL-implementation, there would be no requirement for
> a standard... this would lead to

* a compatibility package as a new standard

stefan

Jack Unrue

unread,
Jun 24, 2005, 8:32:42 PM6/24/05
to
On Fri, 24 Jun 2005 19:44:41 +0200, Pascal Bourguignon <p...@informatimago.com> wrote:
>
> JVM is a good step toward long-term survival of (Java) software.
> Hardware will change, but a simple virtual machine is all you need to
> keep your software running.

I don't know how much of a step the JVM really is (and I don't mean to
bash Java just because I'm posting to c.l.l., because I like it and
programming in Java pays my bills).

I think the survival of Java software is as much or more a function of
how hard Sun keeps striving for backwards compatibility in the class file
format, the JVM, and the standard libraries, as anything else. I would
cite:

- the longstanding existence of @deprecated and the fact that many if not
most so-called "deprecated" standard library functions have not yet
actually been removed even since the 1.1 days (check out the list of
deprecated interfaces/classes/etc in the JDK docs and see how many are
hold-overs from 1.1)

- the compromises made in implementing new language features in Java 5
(c.f. type erasure, which has led some people to question just how
"generic" Java 5 generics really are)

- javac's -source and -target options as well as java.exe's -version:<value>
option, which are certainly good features but which I think support my
point that Sun has put in effort in this

- the sheer weight of the Java community that has developed over time

One could imagine an alternate universe where backwards compatibility
was not such a major underlying tenant of Java, and one could imagine
the Java in that alternate universe not being so popular. Sun had
a chance to make major changes (in the 1.0.x - 1.1 transition) and they
took it. I don't think they believe they could get away with that
nowadays.

Also, Java as a platform is highly dependent on native code libraries to
supply functionality that real-world apps need.

> The survival of lisp software would be improved if more
> implementations used a lisp virtual machine.

Here's a question -- does anyone think that the development of a Lisp
VM (whether based on the one in clisp or not) would proceed any differently
from the development of Lisp itself, taking into account the history of Lisp
dialects and the Lisp culture?

I don't think there would be much difference (not that that's necessarily bad,
it's just speculation on my part).

--
Jack


Sashank Varma

unread,
Jun 24, 2005, 9:56:11 PM6/24/05
to
Matthias Buelow wrote:

> Plus, programming language research has moved on to languages more
> "fruitful" in theoretical results, i.e., functional languages like ML
> and Haskell, with strong type systems, where there are quite a few
> open problems still.

You are revealing a severe mathematical bias. Sticking to functional
languages purely because it is easy to prove theorems about their
programs is like a drunk looking for his keys not where he lost them,
but by the lamp post because that's where the light is best. This
attitude has turned Artifical Intelligence into a sad little branch of
applied mathematics -- a wholescale retreat from its original goals.
Sad to see it is also corroding your part of the programming languages
world.

> Perhaps Lisp simply has become too boring for
> research with no really interesting problems left?

Lisp is only boring relative to the goal of getting theorems.

> And you apparently cannot
> mathematically formalize a dynamic type system as well as a strict,
> inferential one, and this alone would make it quite unattractive for
> use in research papers.

Oh, I get it. Lisp is only boring relative to the goal of getting
*easy* theorems.

Steve

unread,
Jun 24, 2005, 10:00:29 PM6/24/05
to
Zaninsk wrote:
> ...

> Yes but if you are serious about performance you'll likely implement a JIT
> engine for X, Y, Z processor. Why not cut out the midle man and compile
> directly to your real machine? If performance is not a point then yes,
> virtual machines are a good advantage.

ANSI C essentially defines a UNIX virtual machine and is relatively
easy to port to new architectures. A Lisp which compiles to C like GCL
gains both portability and performance.

Barry Margolin

unread,
Jun 24, 2005, 11:37:42 PM6/24/05
to
In article <uk6kk9...@news.dtpq.com>,
cst...@news.dtpq.com (Christopher C. Stacy) wrote:

> Besides, I don't see anyone stopping anyone else from
> inventing their own versions of Lisp.

Nothing's stopping them, but it's effectively discouraged. If someone
tries to promote their own version, many Lisp devotees will point out
all the important CL features that it's missing, or explain how one
could accomplish the same results using CL, etc. I think it would be
very difficult for a new Lisp dialect to gain a foothold these days.

--
Barry Margolin, bar...@alum.mit.edu
Arlington, MA
*** PLEASE post questions in newsgroups, not directly to me ***

Paul F. Dietz

unread,
Jun 24, 2005, 11:59:12 PM6/24/05
to
Barry Margolin wrote:

> Nothing's stopping them, but it's effectively discouraged. If someone
> tries to promote their own version, many Lisp devotees will point out
> all the important CL features that it's missing, or explain how one
> could accomplish the same results using CL, etc. I think it would be
> very difficult for a new Lisp dialect to gain a foothold these days.

I don't know if the Lisp devotees per se are the impediment here.
The new lisp would have to have some decisive advantage in some
way in order to compensate for its lower maturity, smaller
community, and arguably lower chance of survival.

So what's one of those advantages? How about immutable types
with hash consing? Systems like ACL2 would benefit from this.
I'd like to see how that could be integrated into CL, perhaps
by subclassing CONS with immutable cells.

Paul

Christopher C. Stacy

unread,
Jun 25, 2005, 12:24:28 AM6/25/05
to
Barry Margolin <bar...@alum.mit.edu> writes:

> In article <uk6kk9...@news.dtpq.com>,
> cst...@news.dtpq.com (Christopher C. Stacy) wrote:
>
> > Besides, I don't see anyone stopping anyone else from
> > inventing their own versions of Lisp.
>
> Nothing's stopping them, but it's effectively discouraged. If someone
> tries to promote their own version, many Lisp devotees will point out
> all the important CL features that it's missing, or explain how one
> could accomplish the same results using CL, etc. I think it would be
> very difficult for a new Lisp dialect to gain a foothold these days.

That's because the Common Lisp community is composed
mainly of people who are trying to solve problems,
and Common Lisp is a good enough base to allow them
to do that. These people are not very interested in
designing new languages - they already have a language
that is good enough for what they want to do.
Lisp did not evolve in a vacuum - it evolved to suit a
particular (if very general) set of users.

So even though Lisp obviously can be the base for
something else, nobody has proposed anything else
of real interest to the user community.

Who is it that would be interested in a new language?

I think this whole thing about Lisp not evolving due
to Common Lisp as largely malarky. For one thing,
evolutionary progress did not stop with Common Lisp.
It had already pretty much stopped years before that.
Common Lisp was about gathering the resulting disarray
of stuff together into something that would suit some
particular technical and political needs.

Nothing prevents people from coming up with ideas
and proposing them. I just don't see anyone coming
up with very many good new ideas for Lisp; Certainly
no well-developed ones.

I don't feel much need for a better language.
I mean, I can imagine a few things, but I don't personally
have time to work on figuring out whether they are very
good ideas. I have work to do, and unfortunately it's not
fiddling around with new languages.

The people who are fiddling around with new languages are
mostly not using Lisp, but they haven't shown me anything
terribly interesting, either. I don't think that the pace
of evolution has anything to do with Common Lisp.

It never had anything to do with Lisp.
It had to do with solving problems,
and Lisp was merely the vehicle.
Apparently the complaint is: "Problem solved".

Christopher C. Stacy

unread,
Jun 25, 2005, 12:30:04 AM6/25/05
to
"Paul F. Dietz" <di...@dls.net> writes:

> How about immutable types with hash consing? Systems like ACL2
> would benefit from this. I'd like to see how that could be
> integrated into CL, perhaps by subclassing CONS with immutable cells.

Sure, okay -- so what's the problem that is
impeding anybody from trying this out?

(I think we agree that it isn't the existance of Common Lisp.)

Tayssir John Gabbour

unread,
Jun 25, 2005, 12:42:23 AM6/25/05
to

Did McCarthy give a nuanced reason?

I would guess it's something like: Lisp's standardization closed off a
lot of research money because it was "completed" in some way. Pure
guess though.

Tayssir

Kent M Pitman

unread,
Jun 25, 2005, 12:59:28 AM6/25/05
to
Kenny Tilton <kti...@nyc.rr.com> writes:

...
> Dr. McCarthy joined with Henry Baker, his predecessor at the
> microphone, in bemoaning the standardization of Common Lisp as
> stultifying if not mortifying, in that it ended innovation.
...

I wish I could have been there to debate this with him.

Nothing about the standardization of Common Lisp has precluded in the
slightest way other innovation. Indeed, the very size and fixed
nature of Common Lisp has been sufficient barrier to new entrants into
the implementation camp that the opportunity has been wide open for
someone to come in with something either smaller or different IF it
were either too big to implement or too inflexible to accomodate change.

1. Since 1985, when the ANSI process began, the market has changed
substantially. The business climate itself has changed substantially.
Companies used to do lots of "long arc" planning and now are focused
on the very next quarter's bottom line. The market just doesn't have
the free cash to be taking as many flights of fancy as it once did.

2. The Scheme language, by staying small, has attracted lots of people who
have wanted to make new implementations and dialects. But this has
arguably just frittered away valuable talent re-implementing past ideas
rather than pressing on to new ones. After a while, some of us had seen
a LOT of Lisp dialects and came to think that perhaps there was more to
life than merely making new ones. Like actually writing programs.

3. The modern world is very heterogeneous. Expanding your own design by
seeking the perfect language through continuous refinement is a barrier
both to new entry to the language, and also to connecting the language
to new systems. A lot of recent effort has been on connecting Lisp to
other technologies. I don't think that effort is wasted. I like McCarthy
and enjoy his talks, but my sense is that he would make these same comments
unless there was a "return" to a quest for a pure or novel dialect.
And I don't think that's what you'd get if you did a re-implementation.
You'd more likely get more dialects that were C- or C++ or Perl or Java
compatible, and that actually LOST rather than GAINED flexibility because
the pressure would be to add features from those languages that don't mix
well with Lisp. That, at least, was the fate of Dylan. I'm not saying
that there's no value in being able to intermix with those language, but
I'm saying that making Lisp more C++-ish or Java-ish is not the way to do
that. And the pressure would be there, if there were a re-design, to do
that.

4. I think McCarthy places too much blame at the door of the language. The
days of "large government" (where implementors outnumber users) are gone,
and the burden is no longer on implementors to make motion move forward.
We are now in the era of "the people" (where users outnumber implementors).
For things to move in this or that direction, there must be users who want
it to happen. You can't blame CL for the lack of user-commitment to other
things. Build another language (ARC?) and see if people flock to it. At
some point, you have to blame the implementors (or would-be implementors)
of those other dialects (or would-be dialects) for not attracting things.

Obligatory Political Analogy: Blaming Common Lisp for there not being
other Lisp dialects is like blaming the Republicans for Kerry having
lost to Bush in the last US presidential election. The Democrats lost
because they ran a lousy campaign. I'd even push the analogy to say
that the election results don't even prove that Bush was a good
candidate as much as it proves that Kerry didn't offer a credible
alternative; likewise, even if you don't like Common Lisp, the burden
is still on you to provide something more credible. I like the
Democrats but feel they have poorly articulated their message; Howard
Dean is doing good things fixing that. You can like or dislike CL,
but at least it's got a coherent message that implementors can use as
a guide and users can do likewise, yielding productive programs.
Other attempts have been made, e.g., ISLISP, but it's not CL's fault
they have fallen short.

I wish McCarthy would spend more time articulating what he wants to
see happen and how it might be done, than talking about how he doesn't
like what does happen. This is not because I want him to shut up. I
just don't know how to respond to his criticism. Should we
unstandardize CL? Should we stop selling existing implementations?
That makes no sense. The only thing one can do is blunder forth. So
McCarthy ought, IMO, be offering us suggestions about what he wants in
a new Lisp that would make the effort and cost of discarding CL
worthwhile... (In fact, I think the burden is even on him to show that
it's even NECESSARY to discard CL; that is, that the features and
effects he wants can't simply be accomodated by CL. Of course, it's
easy to design a feature incompatible with CL, but it's harder to
design a legitimate need not served by CL that can't be addressed by
adding something to CL. I'm not saying it's impossible, but I think
CL has stood for a while exactly because it is "good enough" for a lot
of what needs doing.)

I basically don't want to get in the position of putting McCarthy
down. I have great respect for the man. He has contributed greatly
to us. And I think he still has things of merit to say. I try to
listen carefully when he speaks because I hate to waste that resource.
BUT I find the remarks, at least as paraphrased here, as falling
short, in that they offer non-constructive criticism (by which I mean
"criticism that cannot be acted", NOT "criticism spoken in a
mean-spirited way") rather than a roadmap ahead or even a picture of
what we'd find at the end of the road if we would just hack our way
through the jungle without a map. And so I feel like he's somewhat
asking me to waste the availability of the wisdom he might have to
share if it's not framed in a way I can figure out how to act upon.

(But then, maybe he did say more about this and it just got lost in
translation when summarized here? One can always hope...)

Kent M Pitman

unread,
Jun 25, 2005, 1:10:37 AM6/25/05
to
Onay Urfalioglu <on...@gmx.net> writes:

> If there were only ONE CL-implementation, there would be no requirement for
> a standard... this would lead to

There are numerous points in time in the past where if there had been
only one implementation, the bottom would have fallen out of the
market. In the days where there were only commercial implementations,
"second sourcing" was ESSENTIAL to customer willingness to invest a large
amount of money in Lisp.

Now you might argue that times have changed (and I might make my usual
lamentations about it having happened) due to Free Software. But even
with all that, you're left with the practical fact that there now ARE
multiple implementations. What are you advocating? That all but one
lay down their arms and die? It's hard to kill a free implementation,
and it's hard to tell a commercial implementation to stop caring.

Of course, ANY implementation can simply elect to DIVERGE and hope
others will follow. That's the only REAL mechanism for making a
single-implementation Lisp. I just don't see any implementors with
that kind of hubris.

> * a much higher quality codebase since much bigger user base

- only if people follow
- only if there's funding to match what the community does

> * more and more bugfree extensions and libraries

- only because you define away bugs
- you probably lose portability or at least gain uneven support
across implementations because you rely on people "caring" for
compliance

> * each extension, once accepted, would be a de facto standard automatically
> since there is only one impl.

- you lose competition over implementation strategy
- you lose discussion about whether there are multiple ways to read
definitions in the language spec
- you permit opportunistic controllers of the source to change things on
a whim, perturbing the base of customers who have no recourse but to follow

> * an overall speedup of development and progress of CL itself since all
> developers would HAVE TO work TOGETHER (in harmony)

- or use another language. you assume a captive audience, which is far
from true. you're banking the whole future of lisp on quite a gamble.

> IMO, this is one of the strength of PL like Python, Ruby ....

i once heard the following two rules offered for how to win in the market:

- go with your gut
- be right

it's the second of these two that is problematic.

by some accounts, python and ruby followed both rules. (by some
accounts, so did lisp.) but supposing you disagree that lisp did, you
have laid out clearly how to do the first part in getting to a new
language ("eschew compatibility" -> "go with your gut"), you're more
sketchy on how to achieve the second part ("be right").

Rainer Joswig

unread,
Jun 25, 2005, 2:18:45 AM6/25/05
to
In article <pan.2005.06.24....@c.net>,

Matthew D Swank <akopa-is-very-much-...@c.net> wrote:

> On Fri, 24 Jun 2005 20:50:16 +0200, Rainer Joswig wrote:
>
> >
> > CL and Python are very different. Different purpose, different audience, ...
> >
>
> Though it sounds like McCarthy is not in CL's audience (anymore), and
> perhaps (with respect to Python) neither is Peter Norvig.
>
> Matt

Right.

Friedrich Dominicus

unread,
Jun 25, 2005, 4:39:49 AM6/25/05
to
Kirk Job Sluder <ki...@jobsluder.net> writes:

> Pupeno <pup...@pupeno.com> writes:


>
>> Friedrich Dominicus wrote:
>> personally I see lots of projects without a standard evolve faster than
>> Common Lisp (Perl, Python, Ruby, PHP). I would be all on the side of
>> dropping the standard (it doesn't help portability a lot because if you use
>> multithreading or sockets or one of those things not standarized *yet*, you
>> are screwed. But, I'm just a newbie.

I would appricate if you cite me correctly. I did not have wrote that
paragraph. And I strongly argued *against* it.

Friedrich
--
Please remove just-for-news- to reply via e-mail.

GP lisper

unread,
Jun 25, 2005, 4:31:54 AM6/25/05
to
On Fri, 24 Jun 2005 22:59:12 -0500, <di...@dls.net> wrote:
> Barry Margolin wrote:
>
>> Nothing's stopping them, but it's effectively discouraged. If someone
>> tries to promote their own version, many Lisp devotees will point out
>> all the important CL features that it's missing, or explain how one
>> could accomplish the same results using CL, etc. I think it would be
>> very difficult for a new Lisp dialect to gain a foothold these days.
>
> I don't know if the Lisp devotees per se are the impediment here.

Look into c.l.l. history for a recent request about LUSH. Went down
just as Barry describes. At some point, people did come around to the
question asked.


--
The LOOP construct is really neat, it's got a lot of knobs to turn!
Don't push the yellow one on the bottom.

Stefan Nobis

unread,
Jun 25, 2005, 5:38:06 AM6/25/05
to
Matthias <n...@spam.please> writes:

> Well, other languages were standardized by the same heavyweight
> process as CL (C, C++, SQL, Fortran). While these languages sure
> evolve slower than Perl/Python/Ruby/etc there is development. The C++
> standard is revised and extended every 5 years or so.

That's not quite correct. C++ for example has till now no new
standard version after the initial one of 1998 (the next one is
expected not before 2006 or even 2007 and changes seems to be
(very) small -- some clarifications, nearly no changes in base
language but some additions to the library, mostly copied from
boost.org; at least as far as i know).

So everything we need to be comparable to C++ in this regard is
more libraries with a peer review system like boost.org.

Another example: Ada. Last standards version 1995, next not before
2007 or 2008 (main changes are extended standards libraries: at
least a collection classes library will be added).

So it's all about libraries.

--
Stefan.

Paul F. Dietz

unread,
Jun 25, 2005, 7:09:17 AM6/25/05
to
GP lisper wrote:

>>I don't know if the Lisp devotees per se are the impediment here.
>
>
> Look into c.l.l. history for a recent request about LUSH. Went down
> just as Barry describes.

And yet, are they the impediment? Seems you're engaging
in post hoc reasoning here.

Paul

Alexander Kjeldaas

unread,
Jun 25, 2005, 8:18:57 AM6/25/05
to
Stefan Nobis wrote:
> Matthias <n...@spam.please> writes:
>
>
>>Well, other languages were standardized by the same heavyweight
>>process as CL (C, C++, SQL, Fortran). While these languages sure
>>evolve slower than Perl/Python/Ruby/etc there is development. The C++
>>standard is revised and extended every 5 years or so.
>
>
> That's not quite correct. C++ for example has till now no new
> standard version after the initial one of 1998 (the next one is
> expected not before 2006 or even 2007 and changes seems to be
> (very) small -- some clarifications, nearly no changes in base
> language but some additions to the library, mostly copied from
> boost.org; at least as far as i know).
>

Look at ftp://ftp.nuug.no/pub/dist/20050415-stroustrup.pdf for some
slides from strostrup about where c++0x is going. Strostrup gave this
talk after the Lillehammer meeting of the C++ standards committee.

Because of the popularity of template meta programming, c++0x will
probably include major changes to make template meta-programming easier.
Auto-typing, concepts (a type system for types), simple compile-time
reflection etc. are improvements in this area.
Concepts alone is a major change IMO.

> So everything we need to be comparable to C++ in this regard is
> more libraries with a peer review system like boost.org.
>
> Another example: Ada. Last standards version 1995, next not before
> 2007 or 2008 (main changes are extended standards libraries: at
> least a collection classes library will be added).
>
> So it's all about libraries.
>

The new c++0x standard is all about making it *easier* to write
libraries like the ones made by boost.org.

astor

Matthias Buelow

unread,
Jun 25, 2005, 11:38:47 AM6/25/05
to
"Sashank Varma" <sashan...@yahoo.com> writes:

>You are revealing a severe mathematical bias. Sticking to functional
>languages purely because it is easy to prove theorems about their
>programs is like a drunk looking for his keys not where he lost them,
>but by the lamp post because that's where the light is best. This
>attitude has turned Artifical Intelligence into a sad little branch of
>applied mathematics -- a wholescale retreat from its original goals.
>Sad to see it is also corroding your part of the programming languages
>world.

I'm talking about what I observe.. I might be wrong, of course. After
all, this whole stuff isn't just done for its own sake, but people are
trying to make a career on some topics, and also be able to pay some
bills from their research work, and they naturally chose areas where
there's the chance of reaping results in the near future and
publishing a few papers about it. I don't think the "mathematization",
or so, is a bad thing. Maybe AI was a bit too hippie-style vague and
nebulous 20 years ago, and then bubble burst, when it couldn't deliver
that which has been promised? That's what I suspect, I can't verify
it, not having been there in that time, so correct me if I'm wrong.
BTW., AI has little to do with Lisp. I was talking about Lisp, but you
have changed tracks. Today, apparently, most AI programming is done in
Java, as it seems.

mkb.

Rainer Joswig

unread,
Jun 25, 2005, 11:53:12 AM6/25/05
to
In article <86acleo...@drjekyll.mkbuelow.net>,
Matthias Buelow <m...@incubus.de> wrote:

Do you have any numbers?

Matthias Buelow

unread,
Jun 25, 2005, 1:04:55 PM6/25/05
to
Rainer Joswig <jos...@lisp.de> writes:

>> BTW., AI has little to do with Lisp. I was talking about Lisp, but you
>> have changed tracks. Today, apparently, most AI programming is done in
>> Java, as it seems.
>
>Do you have any numbers?

For what, for the Java hypothesis? At my university, the AI department
has made the switch a couple years ago (before 2000) and there doesn't
seem to be any Lisp left (they had used, and offered courses, on Lisp
before that). And at least in multiagent simulations, Java and C++
(either with simulation class libraries or with development shells,
like SeSAm) seem to be predominant in the field in general, as I was
told. This is probably also due to the fact that all students know
Java (since it's taught in required courses and used by most
projects), whereas you'd be hard pressed to find anyone who knows
Lisp.

mkb.

alex goldman

unread,
Jun 25, 2005, 1:16:08 PM6/25/05
to
Matthias Buelow wrote:

But do they use Java for *research* ? I know some AI researchers who do, but
I don't think Java dominates.

Matthias

unread,
Jun 25, 2005, 1:20:12 PM6/25/05
to
"Sashank Varma" <sashan...@yahoo.com> writes:

> You are revealing a severe mathematical bias. Sticking to functional
> languages purely because it is easy to prove theorems about their
> programs is like a drunk looking for his keys not where he lost them,
> but by the lamp post because that's where the light is best. This
> attitude has turned Artifical Intelligence into a sad little branch of
> applied mathematics -- a wholescale retreat from its original goals.

Actually, since AI relies more on mathematics than on mostly
unjustified heuristics things are improving a lot in terms of results.

OCR is solved, speech recognition is almost solved, machine
translation is far from solved but getting useful. Even Internet
search, the big thing, relies not on heuristic search algorithms but
on factorization of large sparse matrices.


It is loading more messages.
0 new messages