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

changing focus...

16 views
Skip to first unread message

Rainer Joswig

unread,
Nov 23, 1998, 3:00:00 AM11/23/98
to

Fred Gilham

unread,
Nov 23, 1998, 3:00:00 AM11/23/98
to

jos...@lavielle.com (Rainer Joswig) writes:

> http://www.harlequin.com/news/press/dpp_1198_1.html
>

I notice that the word `lisp' doesn't appear anywhere in the release.

I guess it's a dirty word or something---dang, it has 4 letters....
:-(

If people don't want to sell lisp, why should we buy it from them?

--
Fred Gilham gilham @ csl . sri . com
King Christ, this world is all aleak, / And life preservers there are none,
And waves that only He may walk / Who dared to call Himself a man.
-- e. e. cummings, from Jehovah Buried, Satan Dead

Chuck Fry

unread,
Nov 23, 1998, 3:00:00 AM11/23/98
to
In article <u7emqu9...@snapdragon.csl.sri.com>,

Fred Gilham <gil...@snapdragon.csl.sri.com> wrote:
>jos...@lavielle.com (Rainer Joswig) writes:
>> http://www.harlequin.com/news/press/dpp_1198_1.html
>>
>
>I notice that the word `lisp' doesn't appear anywhere in the release.

Nor do C, C++, Java, Dylan, or any other language, for that matter. Why
should they?

They did, however, mention a couple of applications in the Editors'
Notes that run on Lisp.

>If people don't want to sell lisp, why should we buy it from them?

Harlequin is perfectly willing to sell their Lisp. If you don't believe
me, call them.

Some might be disgruntled that Harlequin has laid off much of the staff
they acquired from Lucid and Symbolics when those companies met
financial trouble. But since when is any one company required to
support an entire industry's personnel single-handedly?

-- Chuck
--
Chuck Fry -- Jack of all trades, master of none
chu...@chucko.com (text only please) chuc...@home.com (MIME enabled)
Lisp bigot, mountain biker, car nut, sometime guitarist and photographer

Barry Margolin

unread,
Nov 24, 1998, 3:00:00 AM11/24/98
to
In article <joswig-2311...@194.163.195.67>,
Rainer Joswig <jos...@lavielle.com> wrote:
>
>http://www.harlequin.com/news/press/dpp_1198_1.html

I presume this explains Pitman's layoff a few weeks ago, although it seems
strange that there would be so much time between the layoff and the
announcement of the reorganization. Were all the other Dylan and Lisp
folks laid off as well?

--
Barry Margolin, bar...@bbnplanet.com
GTE Internetworking, Powered by BBN, Burlington, MA
*** DON'T SEND TECHNICAL QUESTIONS DIRECTLY TO ME, post them to newsgroups.
Don't bother cc'ing followups to me.

Jason Trenouth

unread,
Nov 24, 1998, 3:00:00 AM11/24/98
to
On Tue, 24 Nov 1998 08:49:01 GMT, Barry Margolin <bar...@bbnplanet.com> wrote:

> In article <joswig-2311...@194.163.195.67>,
> Rainer Joswig <jos...@lavielle.com> wrote:
> >
> >http://www.harlequin.com/news/press/dpp_1198_1.html
>
> I presume this explains Pitman's layoff a few weeks ago, although it seems
> strange that there would be so much time between the layoff and the
> announcement of the reorganization. Were all the other Dylan and Lisp
> folks laid off as well?

No. We're still here.

__Jason

Christopher Stacy

unread,
Nov 24, 1998, 3:00:00 AM11/24/98
to

Not ever single person is gone, but I think it's misleading for
Harlequin to suggest that there has not been a major "streamlining".

It is common knowledge that a lot of people (especially senior people)
from the Lisp and Dylan groups, both development and support,
as well as the Memory and Database group, and other areas,
were let go.

In fact, my understandng is that the Lisp and Dylan groups no longer
exist, and that the remaining people have been folded into a generic
"Languages" group.

The press release on their web site seems pretty clear that they are
no longer in the business of selling computer languages, but are
focusing on their publishing and the law enforcement products.
It is not tht they casually neglected to mention Lisp and Dylan
as products: they have deliberately excised them.

Presumably this reflects a new business plan in which those languages
are considered to be internal technologies, rather than general
products in ongoing market areas. I would be surprised if Harlequin
wouldn't sell you a copy of Lisp or Dylan, but they have certainly
made noticable reductions in their ability to develop and support them.

I don't have any inside information, and who knows what the future
will bring. I am just reading Harlequin's press release and making
the obvious inferences. People should read it for themselves.

David Bakhash

unread,
Nov 24, 1998, 3:00:00 AM11/24/98
to
If harlequin were to give up on Lisp, then that would be a major
mistake.

It's funny. I'm a grad student at BU. I was sitting beside an
undergrad in the cluster yesterday. I am a math person, so I was
working on a digital filtering problem. I saw, on the kid's screen,
C-mode, with all the font-lock stuff going on, and lots of pointers,
and something that looked like:

struct tree_node {
left blah...

}

and it just went on and on. I felt like I had to say something. So I
bother to ask him what his program was supposed to do. And, at about
2:15 am, as he was struggling just to make it compile, he told me.
then, I showed him how I would do all that with defstruct, in Lisp,
and I literally did his whole problem set in under 5 minutes. He
thought I was a genius. After I made it work, I showed him how I
could then add in declarations, etc...

Why do I mention this? It's because people learn a method of doing
something and stick with it. You don't know about something that
might be better, but you know your way around _something_, and though
painful, you're comfortable with it, and since the rest of the world
uses it, you think it must be the least painful.

All I know is that I showed that kid something just in time. I think
I made a difference to him. I think he saw that he was spending an
aweful lot of time doing something that was painful, when he could
have been thinking about more interesting things.

anyway, my theory is that software is getting far too complex, and
C/C++ will eventually die away because as complexity grows, it becomes
too painful to code in anything but Lisp (as far as I've seen, and
I've played with many languages). (can't speak for Dylan, though, and
I've read interesting things about it). One day, when Lisp is the
thing, Harlequin will painfully regret letting go of it, if that's
what they're doing.

dave

David B. Lamkins

unread,
Nov 24, 1998, 3:00:00 AM11/24/98
to
In article <1qu62.34$OP3....@burlma1-snr1.gtei.net> , Barry Margolin
<bar...@bbnplanet.com> wrote:

>In article <joswig-2311...@194.163.195.67>,
>Rainer Joswig <jos...@lavielle.com> wrote:
>>
>>http://www.harlequin.com/news/press/dpp_1198_1.html
>
>I presume this explains Pitman's layoff a few weeks ago, although it seems
>strange that there would be so much time between the layoff and the

>announcement of the reorganization. Were all the other Dylan and Lisp


>folks laid off as well?

At the LUGM in Berkely, I believe I heard that Harlequin let go _all_ of the
Lispers in the US. The remaining Lisp developers are all in the UK.

---
David B. Lamkins <http://www.teleport.com/~dlamkins/>

Dwight VandenBerghe

unread,
Nov 25, 1998, 3:00:00 AM11/25/98
to
On 24 Nov 1998 11:28:23 -0500, David Bakhash <ca...@bu.edu> wrote:
>As complexity grows, it becomes too painful to code in anything but Lisp.

Lisp has some real problems. Anything can be in any list, so you can
be seriously bit at runtime by typing errors that a language with
stronger types would have caught. The module system was pretty
poor last time I checked. And having to look at the type bits
in a variable to find out its type slows it down even more. These
are not just theoretical concerns: my copy of Dylan brings my
pentium pro 200 (NT) to its knees, much worse than excel or word
or any other language environment I know of, and it's written in
a state-of-the-art Lisp, isn't it? I really like algebraic types,
so coding in Lisp or Scheme seems like going back a couple of
decades in the way-back machine. For a big project ("as complexity
grows") I'd go for Objective Caml or maybe even SML/NJ over Lisp.
Ocaml is small, very fast, very powerful, with a great type system
and full source freely available. So that's a bit of dissention
to your comments, Dave, although I agree wholeheartedly with all
that you said about C and the student, etc.

Dwight

Pierre Mai

unread,
Nov 25, 1998, 3:00:00 AM11/25/98
to
dwi...@pentasoft.com (Dwight VandenBerghe) writes:

> poor last time I checked. And having to look at the type bits
> in a variable to find out its type slows it down even more. These
> are not just theoretical concerns: my copy of Dylan brings my
> pentium pro 200 (NT) to its knees, much worse than excel or word
> or any other language environment I know of, and it's written in
> a state-of-the-art Lisp, isn't it? I really like algebraic types,

I'm not going to argue in detail with any of your other concerns,
since I'm quite sure that others will disagree wholeheartedly with
your statements ;)

But Harlequin Dylan was implemented in Harlequin Dylan, so no Lisp is
to blame here (might be that Lispworks was involved in bootstrapping
somewhere, but those components have been purged quite some time
ago IIRC). OTOH Harlequin's Lispworks PE for NT is a true-blue Lisp
implementation from the ground up, and last time I checked, it was
much much much faster than Harlequin Dylan (all of this on a lowly
AMD5x86-133, which reaches P90 levels at most, and where Java+Swing is
much much much much much slower than even Dylan...)

With current, modern compiler-technology, Common Lisp performance is
not something I've fretted about for quite some time, and I'm in the
simulation business, where performance is not totally unimportant (and
yes, the machines that run my simulations are better than my home
machine, where I play around with Dylan ;).

Regs, Pierre.

--
Pierre Mai <pm...@acm.org> http://home.pages.de/~trillian/
"One smaller motivation which, in part, stems from altruism is Microsoft-
bashing." [Microsoft memo, see http://www.opensource.org/halloween1.html]

David Cooper

unread,
Nov 25, 1998, 3:00:00 AM11/25/98
to
Dwight VandenBerghe wrote:
>
> On 24 Nov 1998 11:28:23 -0500, David Bakhash <ca...@bu.edu> wrote:
> >As complexity grows, it becomes too painful to code in anything but Lisp.

>
> Lisp has some real problems. Anything can be in any list, so you can
> be seriously bit at runtime by typing errors that a language with
> stronger types would have caught.
>

The Usenet system has some real problems. Any moron can post to any
unmoderated newsgroup, so you can be seriously bit at read time
by idiots who obviously have little real-world experience in what
they are spouting off about, which a Usenet system with stronger
group moderation would have caught. 8>)

Steve Gonedes

unread,
Nov 25, 1998, 3:00:00 AM11/25/98
to

dwi...@pentasoft.com (Dwight VandenBerghe) writes:

< On 24 Nov 1998 11:28:23 -0500, David Bakhash <ca...@bu.edu> wrote:
< >As complexity grows, it becomes too painful to code in anything but Lisp.

< The module system was pretty poor last time I checked.

Common Lisp doesn't have a module system.

Rainer Joswig

unread,
Nov 25, 1998, 3:00:00 AM11/25/98
to
In article <365b5a83...@news.accessone.com>, dwi...@pentasoft.com
(Dwight VandenBerghe) wrote:

> On 24 Nov 1998 11:28:23 -0500, David Bakhash <ca...@bu.edu> wrote:
> >As complexity grows, it becomes too painful to code in anything but Lisp.
>

> Lisp has some real problems. Anything can be in any list, so you can
> be seriously bit at runtime by typing errors that a language with
> stronger types would have caught.

Yes and no.

> The module system was pretty
> poor last time I checked.

There is only a package system

> And having to look at the type bits
> in a variable to find out its type slows it down even more.

Objects carry types. If variables are typed the
compiler will profit from that. Two different things.

> These
> are not just theoretical concerns: my copy of Dylan brings my
> pentium pro 200 (NT) to its knees, much worse than excel or word
> or any other language environment I know of, and it's written in
> a state-of-the-art Lisp, isn't it?

It isn't. Harlequin Dylan is not written in CL.
Apple Dylan was. Ironically Apple Dylan is acceptably
on my PowerBook. ;-)

>I really like algebraic types,

> so coding in Lisp or Scheme seems like going back a couple of
> decades in the way-back machine.

No - it is a different view of design. Still if your
compiler can type check - nobody has anything against
that - even if it is a Lisp compiler.

> For a big project ("as complexity
> grows") I'd go for Objective Caml or maybe even SML/NJ over Lisp.
> Ocaml is small, very fast, very powerful, with a great type system
> and full source freely available.

This is the old difference between languages that are more
in the SM group ;-) and languages that are more expressive
like Lisp. "This has advantages for production code, but has
disadvantages for rapid prototyping and evolution
of programs." So, for even bigger projects you might
come back to Lisp.

Reread the foreword to "On Lisp" for some arguments.

--
http://www.lavielle.com/~joswig

Rainer Joswig

unread,
Nov 25, 1998, 3:00:00 AM11/25/98
to
In article <joswig-2511...@194.163.195.67>, jos...@lavielle.com
(Rainer Joswig) wrote:

> In article <365b5a83...@news.accessone.com>, dwi...@pentasoft.com
> (Dwight VandenBerghe) wrote:

> >I really like algebraic types,

...


> > For a big project ("as complexity
> > grows") I'd go for Objective Caml or maybe even SML/NJ over Lisp.
> > Ocaml is small, very fast, very powerful, with a great type system
> > and full source freely available.

Second try. I think I need to write something more polemic. ;-)
Sorry.

Which type system do you like? The one from ML? Standard ML?
Haskell? Which Haskell? Clean? Erlang? Some extended Java?
Sather? Miranda? Where are the big differences?

How painful is it to move a 100000 line program from Haskell
to Standard ML? And are the *big* differences between the two
languages? How painful is it two maintain a 100000 line
program that uses pattern matching in function definitions?

In CL a single person can write a 100000 line program in a few
months and maintain it. How much people would I need to
do it in say Haskell where the code would be three times
as big (less abstraction mechanisms available) and three
times as complicated (hey, how many
programmers can you get that have heard the word "Monad"?).
My impression is that there is going an awful amount of research
into these areas (FP) and atleast 50% is academic "masturbation"
(sorry ;-) ) creating evermore complicated mechanisms to
fix the problems of the last language generation.

When will any of these languages be so advanced that they
have something like CLOS? A MOP? Conditions? Incremental
compilers? Great interactive environments? Just
to the contrary working with the languages is like
going **way** back in time.

Note, I know there are exceptions and a really appreciate
the work people are doing - but so far I'm not that
convinced I'll must use it for work right now. If I need
functionality of that sort
- *I* just do it inside CL with a language built on top of CL.

--
http://www.lavielle.com/~joswig

Paul Rudin

unread,
Nov 25, 1998, 3:00:00 AM11/25/98
to
jos...@lavielle.com (Rainer Joswig) writes:

>
> Second try. I think I need to write something more polemic. ;-)
> Sorry.
>
> Which type system do you like? The one from ML? Standard ML?
> Haskell? Which Haskell? Clean? Erlang? Some extended Java?
> Sather? Miranda? Where are the big differences?


Don't get me wrong I like CL there are of couple of things about
types/classes that could (IMHO) be improved e.g.

It would be nice if classes and types could be intergrated.

It would be nice if methods could dispatch on higher functional types.

It is also a complication of dubious value that symbols have a number
of different pieces of data associated with them.


> times as complicated (hey, how many
> programmers can you get that have heard the word "Monad"?).

( I can even give you a accurate definition :-))


> My impression is that there is going an awful amount of research
> into these areas (FP) and atleast 50% is academic "masturbation"
> (sorry ;-) ) creating evermore complicated mechanisms to
> fix the problems of the last language generation.

No doubt lisp was once regard in this light too...

>
> When will any of these languages be so advanced that they
> have something like CLOS? A MOP? Conditions? Incremental
> compilers? Great interactive environments? Just
> to the contrary working with the languages is like
> going **way** back in time.
>

Some functional laguages have interactive enviroments and incremental
compilation. I've yet to find a language that there isn't a
half-decent emacs mode for :-). The need for classes as such is much
reduced when a type system is well designed and used. Although
Functors in ML provide a similar sort of functionality and I
understand that Erlang has a class system (although I don't speak
Erlang).

Pierre Mai

unread,
Nov 25, 1998, 3:00:00 AM11/25/98
to
Paul Rudin <pa...@shodan.demon.co.uk> writes:

> half-decent emacs mode for :-). The need for classes as such is much
> reduced when a type system is well designed and used. Although
> Functors in ML provide a similar sort of functionality and I
> understand that Erlang has a class system (although I don't speak
> Erlang).

I don't speak Erlang either, but in general, when "modern" functional
languages talk about classes, they generally mean type classes and the
like, which are not quite what the OOP crowd calls classes.

In general, modern functional languages use a very different
vocabulary from either the OOP (i.e. C++/Java + Smalltalk) crowd or
the Lisp/Scheme crowd (there are some overlapping groups of people
though ;), a vocabulary that stems mostly from an algebraic,
type-theoretic background...

Regs, Pierre (who still thinks that monad-based parsing is way
cool, but fears that monadic techniques destroy program modularity in
general).

Martin Rodgers

unread,
Nov 25, 1998, 3:00:00 AM11/25/98
to
In article <joswig-2511...@pbg3.lavielle.com>,
jos...@lavielle.com says...

> How much people would I need to

The rest of your question is deliberately omitted, as I believe this
question can applied to _any_ programming language. The answer is that it
depends on the programmers you pick. One experienced programmer could be
as productive as ten newbies.

> Note, I know there are exceptions and a really appreciate
> the work people are doing - but so far I'm not that
> convinced I'll must use it for work right now. If I need
> functionality of that sort
> - *I* just do it inside CL with a language built on top of CL.

Ahh, so your post is really only saying, "This is not for me."

Fair enough. Until a standard appears, I'd warn anyone from using Haskell
to build a large app. Even the people creating Standard Haskell will
agree - that's why they're creating it. Programmers need is stability for
a reasonable length of time, which Haskell is currently lacking.

So ANSI CL wins purely on the grounds that it changes more slowly. ;)
There are also be more implementations to choose from. Issues like the
ease of learning to use monads depend more on the number and quality of
tutorials, and again CL wins.

BTW, while ANSI C seems to have even more tutorials than ANSI CL, I'm not
so impressed by the quality of these books. I have a similar opinion of
most books about programming. While I'm generally against book burning,
there are some examples that I've had the misfortune to find in bookshops
which I'd say the world could do without.

And so we return to the programmer question; experience (may vary with
language), imagination, and of course creativity. I hope that with this
recent change of direction, the quality of Harlequin's programmers
doesn't suffer. (Dragging us back on topic?)

FWIW, I write code in languages like Lisp and Haskell for pleasure, and
usually get blank looks when I mention them in professional circles...
--
Remove insect from address to email me | You can never browse enough
will write code that writes code that writes code for food

Michael Tuchman

unread,
Nov 25, 1998, 3:00:00 AM11/25/98
to
David Cooper <dcoo...@genworks.com> writes:

> The Usenet system has some real problems. Any moron can post to any
> unmoderated newsgroup, so you can be seriously bit at read time
> by idiots who obviously have little real-world experience in what
> they are spouting off about, which a Usenet system with stronger
> group moderation would have caught. 8>)

ROFLOL

Sorry for the noise content, but I couldn't let such a brilliantly
sarcastic reply go uncongratulated. Wish I had thought of it.
--
Michael Tuchman
A Great way to avoid flame wars: all.SCORE has ("vs\\.?" -1000 nil r)

Martin Cracauer

unread,
Nov 25, 1998, 3:00:00 AM11/25/98
to
Joachim Achtzehnter <joa...@kraut.bc.ca> writes:

>If any Lisp vendors are listening: When will we see Lisp environments
>that use the available type information and warn at runtime about such
>errors?

CMUCL's compiler gives out quite some useful warnings if you try to
compile code with declarations, although this doesn't really apply to
CLOS related calls.

Martin
--
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
Martin Cracauer - for email address see a search engine.
There is a business like showbusiness: www.microsoft.com
http://www.freebsd.org/ - Where you want to go. Today.

Rainer Joswig

unread,
Nov 25, 1998, 3:00:00 AM11/25/98
to
In article <uclnkzl...@ns.mercury.bc.ca>, Joachim Achtzehnter
<joa...@kraut.bc.ca> wrote:

> Note,
> he was talking about using Lisp in practise, not about what might be
> possible in theory.

You are right.

> At least with some major Lisp implementations
> compile-time type checking is totally absent. Being involved in a
> major Lisp-based project I find it extremely frustrating to encounter
> runtime errors which would have been easily caught by any crappy C
> compiler. These errors are often encountered long after the relevant
> code was written, and worse, sometimes by end users...

How are you dealing with that currently?



> If any Lisp vendors are listening: When will we see Lisp environments
> that use the available type information and warn at runtime about such

> errors? It is about time that Lisp programming environments grow
> up. Look at what C/C++ environments let you do in terms of debugging
> support. This should all be much easier in Lisp, yet it isn't.

That's one reason some people are still using the Lisp machine.
Debugging is quite good. Some of the commercial systems are
usable.

Hopefully your vendor is listening...

--
http://www.lavielle.com/~joswig

Joachim Achtzehnter

unread,
Nov 25, 1998, 3:00:00 AM11/25/98
to
jos...@lavielle.com (Rainer Joswig) writes:
>
> In article <365b5a83...@news.accessone.com>, dwi...@pentasoft.com
> (Dwight VandenBerghe) wrote:
> >
> > Lisp has some real problems. Anything can be in any list, so you can
> > be seriously bit at runtime by typing errors that a language with
> > stronger types would have caught.
>
> Yes and no.

His message may have come across as a troll, but as far as his
particular gripe about type safety is concerned he has a point. Note,


he was talking about using Lisp in practise, not about what might be

possible in theory. At least with some major Lisp implementations


compile-time type checking is totally absent. Being involved in a
major Lisp-based project I find it extremely frustrating to encounter
runtime errors which would have been easily caught by any crappy C
compiler. These errors are often encountered long after the relevant
code was written, and worse, sometimes by end users...

If any Lisp vendors are listening: When will we see Lisp environments


that use the available type information and warn at runtime about such
errors? It is about time that Lisp programming environments grow
up. Look at what C/C++ environments let you do in terms of debugging
support. This should all be much easier in Lisp, yet it isn't.

Joachim

--
joa...@kraut.bc.ca (http://www.kraut.bc.ca)
joa...@mercury.bc.ca (http://www.mercury.bc.ca)

Erik Naggum

unread,
Nov 26, 1998, 3:00:00 AM11/26/98
to
* chu...@best.com (Chuck Fry)

| Some might be disgruntled that Harlequin has laid off much of the staff
| they acquired from Lucid and Symbolics when those companies met financial
| trouble. But since when is any one company required to support an entire
| industry's personnel single-handedly?

excuse me, but what _is_ this last sentence _really_ about? it is so far
from the actual situation in this market that it stands out as a prime
example of "disgruntled", but I can't fathom what the target really is.
care to explain?

#:Erik
--
The Microsoft Dating Program -- where do you want to crash tonight?

Erik Naggum

unread,
Nov 26, 1998, 3:00:00 AM11/26/98
to
* dwi...@pentasoft.com (Dwight VandenBerghe)

| Lisp has some real problems.

yes, it does. unfortunately, you didn't list any of them. that's also
one of the real problems Lisp has: myths, misconceptions, and prejudice.

unfortunately, the only way to get rid of that problem is to kill people,
so now we need to get Dr. Kevorkian to use Common Lisp on 60 Minutes.

Espen Vestre

unread,
Nov 26, 1998, 3:00:00 AM11/26/98
to
Erik Naggum <er...@naggum.no> writes:

> yes, it does. unfortunately, you didn't list any of them. that's also
> one of the real problems Lisp has: myths, misconceptions, and prejudice.

It's only a few days ago since I talked to an otherwise well-informed
programmer who asked the can't-stand-to-hear-anymore-question: "Isn't
lisp an interpreted language?" (and this was even a _java_ programmer...)

Sigh.

--

(espen)

Jason Trenouth

unread,
Nov 26, 1998, 3:00:00 AM11/26/98
to

In a similar vein, I recently spent some time explaining the virtues of (our
implementations of) Common Lisp, Dylan, and ML to a booth visitor at a trade
show where we were exhibiting.

The visitor currently programmed in Java and Delphi, so towards the end of the
demo and the chat, I was quizzed him about the kind of differences he found
between those two. He was a bit stuck, so I prompted that perhaps Delphi not
having a GC made a significant difference.

The visitor then said that Delphi didn't have a GC because it was a compiled
language! :-j

(And this after explaining and demonstrating the combination of native
compilation and GC just beforehand. I know my boothmanship isn't great, but
I'm pretty sure I went over that ground...)

__Jason

Gareth Jones

unread,
Nov 26, 1998, 3:00:00 AM11/26/98
to
Espen Vestre <e...@nextel.no> writes:

> It's only a few days ago since I talked to an otherwise well-informed
> programmer who asked the can't-stand-to-hear-anymore-question: "Isn't
> lisp an interpreted language?" (and this was even a _java_ programmer...)

Conversely, when I asked if there was a CL interpreter on the college lab
machines I was told that you could only get CL compilers (not that
there's *any* lisp except Emacs on those machines).

--
Gareth Jones

Gareth McCaughan

unread,
Nov 27, 1998, 3:00:00 AM11/27/98
to
James Hague wrote:

> The worst question of all is "What of note has been written in [language
> X]? For all the Java hype, there are few answers. And interestingly the
> same thing is true in the Lisp and Scheme and Forth worlds.

What about that thing (whatever it was) that Peter Norvig recently
sold to Yahoo for some vast sum? What about CL-HTTP (the web server
used by the White House)? If we're allowed to go back a bit (which
maybe isn't wise), what about Macsyma?

> If someone
> could say "very popular computer game X was written in language Y," then
> that would fix most of the conception problems.

I don't see that happening for Common Lisp or Scheme, because
they aren't designed for that kind of thing. If what you want
to do is high-speed polygon pushing then Common Lisp probably
isn't the best language for you. (Scheme would be even worse.)

Forth? Maybe, but I suspect (on the basis of no evidence at
all) that it's hard to compile to give performance as good as
you can get from C (or even a good Common Lisp) for this kind
of application. It makes for code that's very compact and quite
fast, whereas for the trendy games what you need is code that's
very very fast.

--
Gareth McCaughan Dept. of Pure Mathematics & Mathematical Statistics,
gj...@dpmms.cam.ac.uk Cambridge University, England.

Rainer Joswig

unread,
Nov 27, 1998, 3:00:00 AM11/27/98
to
In article <86ww4hq...@g.pet.cam.ac.uk>, Gareth McCaughan
<gj...@dpmms.cam.ac.uk> wrote:

> > If someone
> > could say "very popular computer game X was written in language Y," then
> > that would fix most of the conception problems.
>
> I don't see that happening for Common Lisp or Scheme, because
> they aren't designed for that kind of thing. If what you want
> to do is high-speed polygon pushing then Common Lisp probably
> isn't the best language for you.

Why that? Any particular reason?

Aren't the Nintendo characters (example: SuperMario 64)
designed by Lisp software (N-World) or isn't
Crash Bandicoot (**the** highly successful platform game
for the Sony Playstation) developed with GOOL (-> Lisp)?

--
http://www.lavielle.com/~joswig

Gareth McCaughan

unread,
Nov 27, 1998, 3:00:00 AM11/27/98
to
Rainer Joswig wrote:

[I said, about popular 3-d games]


>> I don't see that happening for Common Lisp or Scheme, because
>> they aren't designed for that kind of thing. If what you want
>> to do is high-speed polygon pushing then Common Lisp probably
>> isn't the best language for you.
>
> Why that? Any particular reason?

The Lisp systems I know about are mostly still a bit slower
than C for really intensive numerical calculations and bit-
-twiddling, both of which are crucial for the kind of game
software that sells millions. And in that context, every
cycle counts.

(I'm sure it would be possible to build a Lisp-like language
that was very good at polygon-pushing. But the question was,
as I understand it, about Common Lisp and Scheme.)

> Aren't the Nintendo characters (example: SuperMario 64)
> designed by Lisp software (N-World)

*designed by*, very likely. The person to whom I was replying
was asking for applications *written in* Lisp. Are Nintendo's
games written in Lisp? (I thought not; I'd be very happy to
be proved wrong.)

> or isn't
> Crash Bandicoot (**the** highly successful platform game
> for the Sony Playstation) developed with GOOL (-> Lisp)?

I have no idea. Again, whether this is an answer to the
question that was being asked depends on what "developed
with" means.

David Thornley

unread,
Nov 27, 1998, 3:00:00 AM11/27/98
to
In article <365b5a83...@news.accessone.com>,

Dwight VandenBerghe <dwi...@pentasoft.com> wrote:
>On 24 Nov 1998 11:28:23 -0500, David Bakhash <ca...@bu.edu> wrote:
>>As complexity grows, it becomes too painful to code in anything but Lisp.
>
>Lisp has some real problems. Anything can be in any list, so you can
>be seriously bit at runtime by typing errors that a language with
>stronger types would have caught.

Do you have any actual evidence that this is a problem, or is it just
a matter of taste and style? A recent book by Capers Jones states
that no studies have found static typing to produce fewer errors
than dynamic typing. I think the potential problems are offset by
the ability to work with something without having to define the data
type too precisely. Many times, you don't know if something should
be integer or floating-point, or how precise or large it needs to be.
In a staticly typed language, you make an arbitrary decision ahead
of time.

>a state-of-the-art Lisp, isn't it? I really like algebraic types,


>so coding in Lisp or Scheme seems like going back a couple of
>decades in the way-back machine.

What do you mean by "algebraic types"? In C, the most algebra you
can get is that the unsigned integers form a ring. If you use
any other sort of numeric type, you're not even guaranteed closure
or associativity.

For a big project ("as complexity
>grows") I'd go for Objective Caml or maybe even SML/NJ over Lisp.
>Ocaml is small, very fast, very powerful, with a great type system
>and full source freely available.

For a big project, I'd go for something that's likely to be portable
to more than one implementation of something. I haven't looked at
Ocaml (but should, probably next year sometime), but I would suspect that
it's defined by its implementation. How many systems will it run
on? Will there be a good implementation for a current system in
ten years? If so, how much would you have to bash to code?

I'm certainly not going to say Lisp has no flaws, but in my experience
it is immune to more programming pitfalls than most languages, runs
nice and fast on my desktop machines, and is especially good when I
don't quite know what I'm doing.

--
David H. Thornley | These opinions are mine. I
da...@thornley.net | do give them freely to those
http://www.thornley.net/~thornley/david/ | who run too slowly. O-

Kelly Murray

unread,
Nov 27, 1998, 3:00:00 AM11/27/98
to
Gareth McCaughan wrote:
>
> James Hague wrote:
>
> > The worst question of all is "What of note has been written in [language
> > X]? For all the Java hype, there are few answers. And interestingly the
> > same thing is true in the Lisp and Scheme and Forth worlds.
>
> What about that thing (whatever it was) that Peter Norvig recently
> sold to Yahoo for some vast sum?

You mean Paul Graham's Viaweb web-store-front editor, written
in CLISP. The company was sold for $49 million in Yahoo stock.
A definite success story for lisp.

Y'know it doesn't matter a WHOLE LOT what the lisp vendors do,
they do not define the lisp LANGUAGE.

Success stories certainly help, but the only success story
that really matters is YOUR OWN. So go forth my friend,
and make your own.

Here is my most recent "million dollar idea" for server-side
lisp web applications: Do a sales contact manager, like ACT,
but all via a web browser interface. Let people use it for free
for some small number of contacts, then some small fee thereafter.
I may very well do it myself because I need such a thing.

-Kelly Murray k...@intellimarket.com http://www.intellimarket.com/

Rainer Joswig

unread,
Nov 27, 1998, 3:00:00 AM11/27/98
to
In article <8667c1q...@g.pet.cam.ac.uk>, Gareth McCaughan
<gj...@dpmms.cam.ac.uk> wrote:

> Rainer Joswig wrote:
>
> [I said, about popular 3-d games]
> >> I don't see that happening for Common Lisp or Scheme, because
> >> they aren't designed for that kind of thing. If what you want
> >> to do is high-speed polygon pushing then Common Lisp probably
> >> isn't the best language for you.
> >
> > Why that? Any particular reason?
>
> The Lisp systems I know about are mostly still a bit slower
> than C for really intensive numerical calculations and bit-
> -twiddling, both of which are crucial for the kind of game
> software that sells millions. And in that context, every
> cycle counts.

There is a lot of graphics software written in Lisp and
you really don't need to use C to be fast. But
you need to do some platform specific stuff, you
need to drive the hardware, etc. If your Lisp uses
OpenGL libraries and you have ultra-fast OpenGL
hardware, then you absolutely in the game.
At one point in history the Symbolics platform
was **the** machine for highres broadcast-quality
3d animation.

> *designed by*, very likely. The person to whom I was replying
> was asking for applications *written in* Lisp. Are Nintendo's
> games written in Lisp? (I thought not; I'd be very happy to
> be proved wrong.)

Not. But actually I think this could be a very hot
market for a Lisp system. You need:

- a development environment running on some host
- a tiny Lisp kernel on the game platform
- interfaces to the hardware and the libraries on
the machine (you need to be able to move with
what is happening there)

Stuff like that has been done for other purposes
already (robots).

I wonder if anybody has tried such things for
example for the Sony Playstation (there is
a special lowcost developer system available
from Sony with interfaces and libraries.
Development takes place with Metrowerks tools
on a PC).

> > or isn't
> > Crash Bandicoot (**the** highly successful platform game
> > for the Sony Playstation) developed with GOOL (-> Lisp)?
>
> I have no idea. Again, whether this is an answer to the
> question that was being asked depends on what "developed
> with" means.

I don't know. Here is what you can find on the Internet
about that:

See http://www.franz.com/apps/gd/crash.main.html or

Quote 2:

With over 1.5 million units sold worldwide, it's safe
to assume that Crash Bandicoot has been accepted into
the elite circle of action/platform stars. Nintendo has
Mario as their spokesman, Sega has Sonic, and now Sony
has Crash. While Crash Bandicoot is actually a
second-party title, with Naughty Dog supplying the
wicked development, we've seen Sony exploit this
marsupial into various PlayStation commercials and all
sorts of Sony propaganda. This November, Crash
Bandicoot 2: Cortex Strikes Back will take the
PlayStation by storm. While Sony denies that Crash is
their mascot, we believe that with this sequel (coming
just a little over a year after the first release)
Crash will be heralded as the one and only PS-X
friendly face. Any newcomers will immediately be
exhaled and marked as impostors.

Crash 2 is going through its final stages of
development as we speak (or type), and Naughty Dog has
done their part to make this sequel even more
impressive than the original. In Crash, Andy Gavin
(Naughty Dog's brain-boy) designed a programming
language called GOOL (a Game Oriented Object LISP),
which was used to create the characters and gameplay in
Crash. Now Naughty Dog is using the revamped GOOL 2, a
similar tool that allows for faster gameplay, more
on-screen objects, more room for animation, and quicker
development. Thus, Crash 2 will present extremely
detailed environments (even more so than the original),
tons of new character animations, longer levels, and
loads of new features.

Another:

For a perspective on AI language code, there was a
lecture at the 1997 CGDC titled "Making the Solution
Fit the Problem: AI and Character Control in Crash
Bandicoot", by Andrew Gavin (a...@naughtydog.com). He
makes a case for the use of a Lisp-like language over C
and assembly for game AI, and he designed his own
language, called GOOL (Game-Oriented Object Lisp). I
missed his lecture, but it's in the procedings, and I
imagine on the CD, which may be still available from
Miller Freeman.

--
http://www.lavielle.com/~joswig

Eugene Zaikonnikov

unread,
Nov 27, 1998, 3:00:00 AM11/27/98
to

Gareth McCaughan wrote in message <86ww4hq...@g.pet.cam.ac.uk>...
[snip]

>
>I don't see that happening for Common Lisp or Scheme, because
>they aren't designed for that kind of thing. If what you want
>to do is high-speed polygon pushing then Common Lisp probably
>isn't the best language for you. (Scheme would be even worse.)
>

AutoLisp, maybe? :)


Eugene Zaikonnikov

Eugene Zaikonnikov

unread,
Nov 27, 1998, 3:00:00 AM11/27/98
to
Espen Vestre wrote in message ...

>Erik Naggum <er...@naggum.no> writes:
>
>> yes, it does. unfortunately, you didn't list any of them. that's also
>> one of the real problems Lisp has: myths, misconceptions, and
prejudice.
>
>It's only a few days ago since I talked to an otherwise well-informed
>programmer who asked the can't-stand-to-hear-anymore-question: "Isn't
>lisp an interpreted language?" (and this was even a _java_ programmer...)
>


Even stranger things are possible. The person who taught me Lisp at the
university course wrote quite sophisticated VHDL simulator in muLisp, but he
didn't even heard about possibility of Lisp compilation.

Cheers,
Eugene Zaikonnikov


Eugene Zaikonnikov

unread,
Nov 27, 1998, 3:00:00 AM11/27/98
to

Martin Rodgers

unread,
Nov 27, 1998, 3:00:00 AM11/27/98
to
In article <86ww4hq...@g.pet.cam.ac.uk>, gj...@dpmms.cam.ac.uk
says...

> I don't see that happening for Common Lisp or Scheme, because
> they aren't designed for that kind of thing. If what you want
> to do is high-speed polygon pushing then Common Lisp probably
> isn't the best language for you. (Scheme would be even worse.)

ISTR a computer animated TV commercial that was done on a Symbolics
machine, all written in Common Lisp. Ok, not realtime, but realworld.,
but I suspect it _may_ have used polygons. ;)

My limited experience of computer animation suggests that performance is
critical. How many days are you - or your client - prepared to wait for a
render? So, at least one company has found that Lisp was fast enough and
demonstrated it in the harsh world of TV advertising.

The commercial was bloody impressive, too! Rainer likes the Whitehouse
using CL-HTTP, but my example was seen at primetime on TV sets all over
the UK. So, when someone asks me "What of note has been written in
Lisp?", I can ask them if they remember that Smarties commercial.

Rainer Joswig

unread,
Nov 27, 1998, 3:00:00 AM11/27/98
to
In article <MPG.10c91865a...@news.demon.co.uk>,
m...@wildcard.butterfly.demon.co.uk (Martin Rodgers) wrote:

> In article <86ww4hq...@g.pet.cam.ac.uk>, gj...@dpmms.cam.ac.uk
> says...
>
> > I don't see that happening for Common Lisp or Scheme, because
> > they aren't designed for that kind of thing. If what you want
> > to do is high-speed polygon pushing then Common Lisp probably
> > isn't the best language for you. (Scheme would be even worse.)
>
> ISTR a computer animated TV commercial that was done on a Symbolics
> machine, all written in Common Lisp. Ok, not realtime, but realworld.,
> but I suspect it _may_ have used polygons. ;)
>
> My limited experience of computer animation suggests that performance is
> critical. How many days are you - or your client - prepared to wait for a
> render? So, at least one company has found that Lisp was fast enough and
> demonstrated it in the harsh world of TV advertising.

I once talked to a guy from finland. Years ago he was working
for a company doing 3d animations. They used the Symbolics
system (3650) to do the broadcast 3d animated logo stuff for
a TV station. Because they have written a specialized very effective
system, they used it years later when much faster systems
were available. Rendering took a long time, but the
results were very predictable.

--
http://www.lavielle.com/~joswig

David Steuber The Interloper

unread,
Nov 28, 1998, 3:00:00 AM11/28/98
to
On 27 Nov 1998 13:47:54 +0000, Gareth McCaughan
<gj...@dpmms.cam.ac.uk> claimed or asked:

% I don't see that happening for Common Lisp or Scheme, because
% they aren't designed for that kind of thing. If what you want
% to do is high-speed polygon pushing then Common Lisp probably
% isn't the best language for you. (Scheme would be even worse.)

Just curious. Why wouldn't Lisp be good for polygon pushing? CMUCL
has a C interface, so there is no problem with hardware assist.
Either Lisp is fast, or it isn't.

I am not a complete idiot. Some parts are missing. Attribute
unknown.

--
David Steuber (ver 1.31.3a)
http://www.david-steuber.com
To reply by e-mail, replace trashcan with david.

May the source be with you...

Martin Rodgers

unread,
Nov 28, 1998, 3:00:00 AM11/28/98
to
In article <joswig-2711...@pbg3.lavielle.com>,
jos...@lavielle.com says...

> Rendering took a long time, but the
> results were very predictable.

I bet it was easy to build tools to assist with repetitive tasks. That
can also help make the results predictable. From what I've seen, it looks
like building the model and animating it is where the most time is spent.
This is where Lisp can really win big.

Today, you can buy more speed by adding machines to your render farm.

my-las...@mediaone.net

unread,
Nov 28, 1998, 3:00:00 AM11/28/98
to
jha...@dadgum.com (James Hague) wrote:

>Espen Vestre wrote:
>> Erik Naggum <er...@naggum.no> writes:
>>
>> > yes, it does. unfortunately, you didn't list any of them. that's also
>> > one of the real problems Lisp has: myths, misconceptions, and prejudice.
>>
>> It's only a few days ago since I talked to an otherwise well-informed
>> programmer who asked the can't-stand-to-hear-anymore-question: "Isn't
>> lisp an interpreted language?" (and this was even a _java_ programmer...)
>

>The worst question of all is "What of note has been written in [language
>X]? For all the Java hype, there are few answers. And interestingly the

>same thing is true in the Lisp and Scheme and Forth worlds. You can name
>some names, especially for Forth, but they're almost always big,
>industrial, embedded applications that don't ring a bell. If someone


>could say "very popular computer game X was written in language Y," then
>that would fix most of the conception problems.
>

>(For the record, at least two games use Lisp-like languages for scripting,
>but I wouldn't say most of those games were written in Lisp.)

Lisp and games: trigger fired, core dumped:

On a personal lisp note, I've implemented two games in lisp which have been
played by hundreds of people over the last decade. A hobby, small peanuts,
definitely not a commercial success. But I got what I wanted, two very fun
games to play.

The first game was my first dabbling in Play-by-email games. Not being terribly
proficient in lisp, it still took me only 6 weeks of spare time to go from
minimal concept to working (playable) prototype. The first game was a rather
kludgy not-quite-discrete event simulator, but was loads of fun. Over the years
it's performed flawlessly and made many people happy, with zero bug reports over
the last 8 years it ran (though there were plenty of new feature requests, but
development of that game had officially ceased, the point being lisp helped
deliver a very robust application).

The second game was supposed to be my "premier game work". A highly detailed
game with a robust discrete event simulation engine. You could build pyramids
of objects which all knew how to work with each other.

I originally spent 4 years of my spare time writing this game in Objective-C on
a NeXT box. The problem was that after 4 years of (spare time) work and about
70,000 lines of production quality Objective-C code, the game wasn't anywhere
near far enough along to be played! [FYI: I consider Objective-C to be vastly
more productive than C++ at that time] Not only was a time to play the game
still not in sight, but had I deployed a prototype, I still would have had to
roll an environment in which to debug the universe when it was corrupted or
simply misbehaving.

So I junked all my Objective-C code, and rewrote the second game in lisp. I had
the first prototype game going in 1 & 1/4 years (spare time). The
read-eval-print loop is a great environment in which to perform interactive
database (universe) debugging. A lambda here, a loop or map there, and bang,
you have a good query/update language.

The lisp game ran the machine, the simulator, dialing out to an ISP at
preprogrammed times, reading POP mail and sending SMTP replies, basically it
provided full computer moderated game hosting.

Lisp made it possible by giving me the most bang for my time buck.
The downside was the performance, since the simulator was very compute
intensive. But it was tractable, and I'm sure would improve vastly if I ported
it from the ACLPC 3.0.2 version it uses to the ACL5 implementation, since I
suspect ACL5 has many more optimizations (and it definitely has bigger fixnums,
which I needed desparately, 16 bit fixnums were not sufficient, 29 bit fixnums
would have been adequate for most of my simulator needs).

If it were me (and I was optimizing for smaller development team/time and better
feature/maintenance capabilities), I wouldn't hesitate to use lisp for an Age of
Empires type of game simulator. The problems mostly arise in UI generation
(i.e. making it look like every other Windows-based game these day in terms of
accepted UI/3D look and feel). For the conventional windows UI, I'd avoid lisp.
These days, I'd probably be more apt to use lisp to be a web-based game server,
so that the UI is java or other browser compatible stuff, and lisp can be used
at what it does best, the complex inards of the product. 80% of what is done by
the MSN gaming zone (www.zone.com) would probably have been vastly simpler as a
lisp application.

Of course, if you have the money to force 10,000 monkeys to write for 10,000
years at 10,000 lines of C code a day, and you are Microsoft, and you don't care
for lisp or java, instead preferring COM, COM+, DCOM, ad absurdum, then I
suppose the point is pretty moot. You can deliver an equivalent solution which
probably performs better, even if it costs 10x as much to develop and enhance.
However not everybody the luxury of all that time and money.

A point not in lisp's favor is the lack of development momentum. For instance,
in my 'zone' example, there are more tools (prepackaged components) for scalable
java servers to be used than there are for lisp-based solutions, and the
momentum is clearly with Java. So if you have a problem solved by off-the-shelf
components, lisp becomes less and less attractive. But if you're trying to
innovate some new solution, or something which is simply of sufficient
complexity, then lisp is nice. And there's nothing preclusing making lisp and
java work together, so that each can be used for what it does best.

That there is a dearth of lisp success stories is unfortunate, but it remains my
choice for making my time count. There are many instances where lisp
successfully enabled complex projects but isn't cited as an enabler for reasons
of "marketing stigma", or because the project fails for other reasons.
Respective examples might include the Yahoo! Store (marketing stigma), and
Microsoft "Bob" (lisp was beind the character generation for "Bob", enabling
product development, though the product flopped).

If (and I mean *if*, since I can't tell from the announcements what's happening)
Harlequin is about to shift back it's lisp product activity, that's very
unfortunate. Another nail in Lisp's coffin for commercial use, since commercial
users often require multiple vendors (at least in theory) to argue that all your
development eggs aren't in one basket. On the theory that "what doesn't kill
you makes you stronger", perhaps lisp will survive. And perhaps the money tree
I planted in my front yard will someday grow.

Hope that wasn't too off-topic. Just wanted to relay a personal (even if not
financial) lisp success story since James brought up lisp and games.
D. Tenny
my-las...@mediaone.net - no spam please

Sashank Varma

unread,
Nov 28, 1998, 3:00:00 AM11/28/98
to
In article <owC72.1181$764.4...@ptah.visi.com>, thor...@visi.com
(David Thornley) wrote:

> In article <365b5a83...@news.accessone.com>,
> Dwight VandenBerghe <dwi...@pentasoft.com> wrote:
> >On 24 Nov 1998 11:28:23 -0500, David Bakhash <ca...@bu.edu> wrote:
> >>As complexity grows, it becomes too painful to code in anything but Lisp.
> >
> >Lisp has some real problems. Anything can be in any list, so you can
> >be seriously bit at runtime by typing errors that a language with
> >stronger types would have caught.
>
> Do you have any actual evidence that this is a problem, or is it just
> a matter of taste and style? A recent book by Capers Jones states
> that no studies have found static typing to produce fewer errors
> than dynamic typing. I think the potential problems are offset by
> the ability to work with something without having to define the data
> type too precisely.

i've had several programmers ask me over the years how it feels
programming without a type-checking safety net at compile time
in common lisp. i'm sure my experience -- that it's no big deal --
jibes with everyone else's on this newsgroup.

its seems like the real question behind this question is "isn't
it dangerous to omit the implicit documentation of the types of
parameters?". this seems a valid point, for we common lisp
programmers typically use 'optional' features such as comments or
documentation strings to record such information, and these optional
tags are often omitted, making reading someone else's code (or one's
own code a few years later) difficult.

of course, we can always add declarations to make the expected types
of parameters clear to the human reader and lisp compiler. but
declarations seem to my eyes disjoint from lambda parameter lists.

this brings me to my question: does anyone use methods for the
purpose of documenting parameter types? to my eyes,

(defmethod foo ((x fixnum) (y string)) ...)

provides the same level of documentation of parameter types as
the syntax of C or pascal.

> Many times, you don't know if something should
> be integer or floating-point, or how precise or large it needs to be.
> In a staticly typed language, you make an arbitrary decision ahead
> of time.

[snip!]

using my scheme, we can tolerate uncertainty about x's type early
in development

(defmethod foo ((x number) (y string)) ...)
^^^^^^
and specialize it incrementally as we pin down its exact type.

just curious if anyone else shares this view.

sashank

my-las...@mediaone.net

unread,
Nov 30, 1998, 3:00:00 AM11/30/98
to
jha...@dadgum.com (James Hague) wrote:

>my-las...@mediaone.net wrote:
>
>> The
>> read-eval-print loop is a great environment in which to perform interactive
>> database (universe) debugging. A lambda here, a loop or map there, and bang,
>> you have a good query/update language.
>

>Thanks for a very interesting reply!
>
>I'm curious: could you elaborate on the benefits of Lisp for your project,
>aside from the interactive nature?
>
>When I program in *any* interactive language (Forth, Lisp, Scheme, Pop-11,
>Prolog, or even a simple BASIC), my productivity is way up compared to
>working in a batch compiled language. The benefit is so great, in fact,
>that I find it difficult to determine how much of a benefit I'm obtaining
>from other language features. In Forth, for example, there's no garbage
>collection, yet manual memory management doesn't seem like much of a chore
>when I can (1) write short "obviously correct" definitions, and (2) test
>them interactively.

When comparing interactive languages, I suppose then the tradeoffs become more
focused upon the following features which are undoubtedly a matter of personal
preference. These are my reasons for using lisp:

1) CLOS, macros, and other lisp constructs such as dynamic/lexical constructs
make lisp the most expressive language for me. I simply feel I can achieve the
most bang per line of code with lisp. A real delight after a day of writing C++
or Java.

I confess to being one of those people who find single inheritance limiting.
Even interfaces in Java in Objective C I find to be a pain. I like mixin style
inheritance. It saves me lots of trouble (and code) in modeling complex
problems. At least Objective-C had message forwarding, Java lacks even that.
So all those interfaces require me to code my own manual forwarding (embed
pointer to object which will handle the message, and implement all the
interfaces to do the fowarding, yuck, what a waste of my time).

Multiple inheritance is a fickle thing. After some fair experience with other
(not necessarily model) MI languages like C++ and Trellis, to me, CLOS is the
only MI implementation which I find truly useful. The more strongly typed
implementations are nice, I'd use them if offered, but I find them considerably
more constraining (and time consuming) than lisp.

2) For me, there's no substitute for a supported product with a strong
performance ethic and highly optimizing compiler. [Commercial] Lisp fits the
bill here for me. (Not that other languages might not, again, personal
preference).

I'll take the highly optimized bitvector and other things which have evolved in
the last 20 years of lisp compiler implementations over Java's implementation
(for performance) any day. Also true of things like GC, where lisp vendors have
spent more time on generational and ephemeral GC techniques (sorely missing in
many JVM's and a problem with application servers stalling for big GC's).

I'm glad Java is bringing GC to the mainstream, it has been unfairly maligned
for so long. But Java had better upgrade the GC so it doesn't get a bad
reputation this time around. They're probably working on it.

3) Dynamic types: I love 'em. Subjective preference. But I'm most productive
with them. Maybe it's my defensive coding style, but I also don't have much
problem with bugs in deployed apps that static typing would have fixed. Sure,
short term, while debugging testing, I run across problems a statically typed
language would have helped me avoid. But lisp also helps me resolve them
quickly.

[Note to my lisp vendor (you know who you are :-) I *hate* your stepper. Come
on folks, it's a lisp throw-back to the 60's. ACLPC did a better job, and it
wasn't much to write home about. Yes, I've filed an official request. If I
tried to get a Visual Dev Studio user to use a lisp/emacs stepper, they'd
probably run me over in the parking lot after work. Fix it!].

4) Interactive debugger in deployed apps. When something breaks, I like to be
able to get into the debugger any time, or have a customer do it for me.
Worlds more useful to quickly diagnose and fix a bug than just getting a stack
trace or "null pointer exception".

5) I already know lisp, which undoubtedly flavors my opinions and certainly give
it an edge in my preferences :-) Though I've certainly spent time with Basic
and some other things, the expressive power and capabilities of lisp still give
me the most bang for my coding buck. Even the simple elegance of WITH-OPEN-FILE
is missed every time I use a language without macros. Instead it becomes an
open-coded TRY/CATCH mish-mash in Java and C++, obfuscating the real intent of
my code for the sake of mundane housekeeping.

Don't get me wrong. Even my current lisp application uses Java as well. I use
whatever works for my needs. But when possible I like using Lisp for the
complex aspects of server development. C, C++, DEC Bliss, 370 Assembler, and
all those other grungy languages had their uses too, and unfortunately will
probably have their uses again (though I shudder at the thought of some of
them).

Jason Karney

unread,
Nov 30, 1998, 3:00:00 AM11/30/98
to

Rainer Joswig wrote:

> Aren't the Nintendo characters (example: SuperMario 64)

> designed by Lisp software (N-World) or isn't


> Crash Bandicoot (**the** highly successful platform game
> for the Sony Playstation) developed with GOOL (-> Lisp)?
>

> --
> http://www.lavielle.com/~joswig

Correct on both accounts. There was an interesting article in the Periodical
Formerly Known as Object Magazine on both of these products (I forget which
issue; I have it at home).

One of the founders of Crash's company, Naughy Dog, was a PhD at MIT: thus the
Lisp bent. He wrote the "Game Object Oriented Language," a specialized and tight
Lisp game-writing system. If I'm not mistaken, GOOL was developed using Franz
Lisp (I don't think that was in the article, but I vaguely remember reading it
somewhere).

If you want more details, check out the article. It was worth the read.

--->Jason


my-las...@mediaone.net

unread,
Nov 30, 1998, 3:00:00 AM11/30/98
to
Oh yea, one more thing I like about CLOS from a OO standpoint exclusive of
multiple inheritance:

Method combination. :AROUND, :BEFORE, :AFTER, PROGN, AND, etc..
which nicely and automatically support common practices which must be maintained
by hand on other languages.

There've been an awful lot of times I've seen people flub remembering to
implementing cascading [super xxx] calls in C++, even though they know that's
the protocol for some method.

Gareth McCaughan

unread,
Nov 30, 1998, 3:00:00 AM11/30/98
to
> % I don't see that happening for Common Lisp or Scheme, because
> % they aren't designed for that kind of thing. If what you want
> % to do is high-speed polygon pushing then Common Lisp probably
> % isn't the best language for you. (Scheme would be even worse.)
>
> Just curious. Why wouldn't Lisp be good for polygon pushing? CMUCL
> has a C interface, so there is no problem with hardware assist.
> Either Lisp is fast, or it isn't.

Probably I should have said "existing implementations of
Common Lisp and Scheme" rather than just "Common Lisp and
Scheme". I can't think of any very convincing reason why
one couldn't make a CL implementation with special facilities
for this kind of stuff. But, so far as I know, there isn't
one at the moment.

Yes, you could do just fine using the FFI and writing the
really speed-critical parts in assembler (or C, if it turned
out to be fast enough). I wonder whether it would buy much
for the Lisp world to say "Such-and-such a really successful
game was written in Lisp, except that all the speed-critical
bits were in assembler". It would reinforce the idea that
Lisp is Terribly Slow.

I suppose all I'm saying could be said with equal propriety
about C. Or could it? C is sufficiently like assembler in
what it does that combining assembler and C works rather
well[1]; with Lisp I would expect the "impedance mismatch"
to hurt more. But I haven't ever tried to do this myself;
how efficient are typical CL FFIs? (If they're inefficient,
of course it's not the end of the world; it just means you
have to implement a larger fraction of your code in a
lower-level language, so you get less of the advantage of
writing in Lisp.).


[1] I don't say it's *pleasant*, of course...

Rainer Joswig

unread,
Nov 30, 1998, 3:00:00 AM11/30/98
to
In article <86yaotq...@g.pet.cam.ac.uk>, Gareth McCaughan
<gj...@dpmms.cam.ac.uk> wrote:

> Yes, you could do just fine using the FFI and writing the
> really speed-critical parts in assembler (or C, if it turned
> out to be fast enough). I wonder whether it would buy much
> for the Lisp world to say "Such-and-such a really successful
> game was written in Lisp, except that all the speed-critical
> bits were in assembler". It would reinforce the idea that
> Lisp is Terribly Slow.

I guess most the speed critical things in games are written in
assembler.

> what it does that combining assembler and C works rather
> well[1]; with Lisp I would expect the "impedance mismatch"
> to hurt more.

Why that? You can do inline PowerPC assembler in MCL.

> But I haven't ever tried to do this myself;
> how efficient are typical CL FFIs?

MCL for example has a relatively complete integration
into the MacOS. That is you can call almost all
the low-level stuff you want. MCL has all the
creator and accessor functions for C/Pascal datastructures,
etc. So the typical platform dependant Lisp code is
a mixture of Lisp and calls to the OS using OS data.
The usual multimedia applications that for example
are using things like Quickdraw, Quicktime or
even Quickdraw 3d can be written directly in Lisp.
And this stuff is really fast on the new G3 Macs.

--
http://www.lavielle.com/~joswig

Vassili Bykov

unread,
Nov 30, 1998, 3:00:00 AM11/30/98
to
Gareth McCaughan wrote in message <86yaotq...@g.pet.cam.ac.uk>...

>Probably I should have said "existing implementations of
>Common Lisp and Scheme" rather than just "Common Lisp and
>Scheme". I can't think of any very convincing reason why
>one couldn't make a CL implementation with special facilities
>for this kind of stuff. But, so far as I know, there isn't
>one at the moment.


Have you seen Corman Lisp? (http://www.corman.net/CormanLisp.html)


Gareth McCaughan

unread,
Dec 1, 1998, 3:00:00 AM12/1/98
to
Rainer Joswig wrote:

>> Yes, you could do just fine using the FFI and writing the
>> really speed-critical parts in assembler (or C, if it turned
>> out to be fast enough). I wonder whether it would buy much
>> for the Lisp world to say "Such-and-such a really successful
>> game was written in Lisp, except that all the speed-critical
>> bits were in assembler". It would reinforce the idea that
>> Lisp is Terribly Slow.
>
> I guess most the speed critical things in games are written in
> assembler.

Of course. But because everyone thinks "C is fast and Lisp is slow",
if you say "We wrote this in Lisp and assembler" it's likely to
reinforce that opinion even though saying "We wrote this in C
and assembler" won't change it. Alas.

>> what it does that combining assembler and C works rather
>> well[1]; with Lisp I would expect the "impedance mismatch"
>> to hurt more.
>
> Why that? You can do inline PowerPC assembler in MCL.

OK; maybe I'm entirely wrong. I'm very glad to hear it. :-)

>> But I haven't ever tried to do this myself;
>> how efficient are typical CL FFIs?
>
> MCL for example has a relatively complete integration
> into the MacOS. That is you can call almost all
> the low-level stuff you want.

What I meant was: how much overhead is there in doing FF
calls? For instance, if you know the thing you're calling
isn't going to do anything that interacts evilly with CL's
memory management etc, can an FF call be basically just a
few register save/restore pairs and a branch-with-link
instruction?

(The question isn't meant to imply the answer "no". I hope
the answer *is* "no".)

Raymond Toy

unread,
Dec 1, 1998, 3:00:00 AM12/1/98
to
>>>>> "Gareth" == Gareth McCaughan <gj...@dpmms.cam.ac.uk> writes:
>>> what it does that combining assembler and C works rather
>>> well[1]; with Lisp I would expect the "impedance mismatch"
>>> to hurt more.
>>
>> Why that? You can do inline PowerPC assembler in MCL.

Gareth> OK; maybe I'm entirely wrong. I'm very glad to hear it. :-)

I think the same is true for CMUCL. Many of the "built-in" functions
are written in assembly.

>>> But I haven't ever tried to do this myself;
>>> how efficient are typical CL FFIs?
>>
>> MCL for example has a relatively complete integration
>> into the MacOS. That is you can call almost all
>> the low-level stuff you want.

Gareth> What I meant was: how much overhead is there in doing FF
Gareth> calls? For instance, if you know the thing you're calling
Gareth> isn't going to do anything that interacts evilly with CL's
Gareth> memory management etc, can an FF call be basically just a
Gareth> few register save/restore pairs and a branch-with-link
Gareth> instruction?

I think this is true for CMUCL. The comments about calling the C math
library says that foreign call is not more costly than a simple lisp
function call. The code looks quite simple too.

Ray

RCCraine

unread,
Dec 2, 1998, 3:00:00 AM12/2/98
to
Gareth wrote:
>Of course. But because everyone thinks "C is fast and Lisp is slow",
>if you say "We wrote this in Lisp and assembler" it's likely to
>reinforce that opinion even though saying "We wrote this in C
>and assembler" won't change it. Alas.
>

Geeez I'm old. At one time the mark of a professional was to code your program
in whatever language then go and speed the pokey parts up with well placed
assembler . If indeed someone wrote the whole program in a 3GL, you know they
were an amateur. Guess with all the clock speed we got these days it doesn't
matter any more. Still it's kinda ashame we sure learned alot about making
things work and how they really worked.

Old dog with new tricks (lazy code and faster 'puters)
rusty


Andrew Shalit

unread,
Dec 3, 1998, 3:00:00 AM12/3/98
to
thor...@visi.com (David Thornley) writes:

> A recent book by Capers Jones states
> that no studies have found static typing to produce fewer errors
> than dynamic typing. I think the potential problems are offset by
> the ability to work with something without having to define the data

> type too precisely. Many times, you don't know if something should


> be integer or floating-point, or how precise or large it needs to be.
> In a staticly typed language, you make an arbitrary decision ahead
> of time.

I'd be very interested in a more complete reference for the
Capers Jones claim, if you have it handy.

Rob Warnock

unread,
Dec 4, 1998, 3:00:00 AM12/4/98
to
Andrew Shalit <al...@shore.net> wrote:
+---------------

| thor...@visi.com (David Thornley) writes:
| > A recent book by Capers Jones states that no studies have found
| > static typing to produce fewer errors than dynamic typing...

|
| I'd be very interested in a more complete reference for the
| Capers Jones claim, if you have it handy.
+---------------

I don't have that one, but there was a *very* old paper by Bill Wulf
at CMU about an analysis of observed user errors in the BLISS language
(truly typeless data), which claimed that "type errors" were found in
practice to be almost non-existent (compared to other errors such as
misplaced semicolons, misplaced or missing "." [the BLISS deferencing
operator], etc.). Part of this was that BLISS had a superb macro facility
(although not as nice as Lisp's!) and a very generic user-programmable
"structure" facility (syntactically an array-definition, but the access
method could be any BLISS expression), and the two worked together
*extremely* well.


-Rob

-----
Rob Warnock, 8L-855 rp...@sgi.com
Applied Networking http://reality.sgi.com/rpw3/
Silicon Graphics, Inc. Phone: 650-933-1673
2011 N. Shoreline Blvd. FAX: 650-964-0811
Mountain View, CA 94043 PP-ASEL-IA

Dr. James McCarron

unread,
Dec 6, 1998, 3:00:00 AM12/6/98
to
In article <86ww4hq...@g.pet.cam.ac.uk>,
Gareth McCaughan <gj...@dpmms.cam.ac.uk> wrote:

>James Hague wrote:
>
>> The worst question of all is "What of note has been written in [language
>> X]? For all the Java hype, there are few answers. And interestingly the
>> same thing is true in the Lisp and Scheme and Forth worlds.
>
>What about that thing (whatever it was) that Peter Norvig recently
>sold to Yahoo for some vast sum? What about CL-HTTP (the web server
>used by the White House)? If we're allowed to go back a bit (which
>maybe isn't wise), what about Macsyma?
[...]

>--
>Gareth McCaughan Dept. of Pure Mathematics & Mathematical Statistics,
>gj...@dpmms.cam.ac.uk Cambridge University, England.


Macsyma still appears to be very much alive. Computer algebra
systems like Macsyma are a major application area for lisp.
What about nqthm and acl2 (theorem provers)? I also heard
mumblings (a few years ago) that a rewrite of TeX in lisp
was being considered. Anyone know what happened to that idea?

Cheers,

James

--
Dr. James McCarron
<jmcc...@world.std.com>

Steve Gonedes

unread,
Dec 7, 1998, 3:00:00 AM12/7/98
to

jmcc...@world.std.com (Dr. James McCarron) writes:

< Macsyma still appears to be very much alive. Computer algebra
< systems like Macsyma are a major application area for lisp.
< What about nqthm and acl2 (theorem provers)? I also heard
< mumblings (a few years ago) that a rewrite of TeX in lisp
< was being considered. Anyone know what happened to that idea?

I believe it was going to be called NTS (for new typesetting system).
I read a FAQ I found burried (they have a home page, can be found from
http://www.dante.de/projekte/nts/NTS.html, and
http://www.loria.fr/services/tex/english/moteurs.html) and it said
something like they finished the kerning/ligature algorithms but
didn't feel like translating the common lisp into Web (?). Anyway, I
believe that they switched to Java or something.

I think they were going to use CLOS - which seems weird since TeX is
not very programming-language like, no types (objects) and therefor no
state for those non-existsing objects. Eveything seems to be a macro
(shudder), as if no evaluation would be every be necessary?

So if it fails the trip test - it's not TeX, but this doesn't mean
it's not a good typesetting system. It's unfortunate that people can
actually read the Web sources but don't finish translating it into a
suitable language (like a programming language or maybe even some
spoken language)...

Nice output though. Too bad no one can improve it (the philosophy of
imortality through obsurity I suppose), (like make some TeX algorithms
into modules for use in some program without shell scripts, etc.)
There's always lout, but it doesn't look as nice (output wise of
course, the name (lout vs TeX) makes no difference to me ...) ...


Matt Curtin

unread,
Dec 8, 1998, 3:00:00 AM12/8/98
to
Barry Margolin <bar...@bbnplanet.com> writes:

> Were all the other Dylan and Lisp folks laid off as well?

JonL wrote to tell me that he had been laid off. In fact, the Menlo
Park office has been closed.

--
Matt Curtin cmcu...@interhack.net http://www.interhack.net/people/cmcurtin/

James McCarron

unread,
Dec 9, 1998, 3:00:00 AM12/9/98
to
In article <m2vhjoq...@KludgeUnix.com>,

Steve Gonedes <jgon...@worldnet.att.net> wrote:
>
>
>jmcc...@world.std.com (Dr. James McCarron) writes:
>
>< Macsyma still appears to be very much alive. Computer algebra
>< systems like Macsyma are a major application area for lisp.
>< What about nqthm and acl2 (theorem provers)? I also heard
>< mumblings (a few years ago) that a rewrite of TeX in lisp
>< was being considered. Anyone know what happened to that idea?
>
>I believe it was going to be called NTS (for new typesetting system).
>I read a FAQ I found burried (they have a home page, can be found from
>http://www.dante.de/projekte/nts/NTS.html, and
>http://www.loria.fr/services/tex/english/moteurs.html) and it said
>something like they finished the kerning/ligature algorithms but
>didn't feel like translating the common lisp into Web (?). Anyway, I
>believe that they switched to Java or something.

Pity. Thanks for the URLs. I'll check it out (curiosity...)

>I think they were going to use CLOS - which seems weird since TeX is
>not very programming-language like, no types (objects) and therefor no
>state for those non-existsing objects. Eveything seems to be a macro
>(shudder), as if no evaluation would be every be necessary?

On the other hand, if you look at the structure of alot of TeX macros,
it is full of "tail calls".... Besides, TeX is written in a general purpose
programming language (Pascal). CL/CLOS is another general purpose
programming language. Why not?

>So if it fails the trip test - it's not TeX, but this doesn't mean
>it's not a good typesetting system. It's unfortunate that people can
>actually read the Web sources but don't finish translating it into a
>suitable language (like a programming language or maybe even some
>spoken language)...

Sorry, I'm not following you here at all.

>Nice output though. Too bad no one can improve it (the philosophy of
>imortality through obsurity I suppose), (like make some TeX algorithms
>into modules for use in some program without shell scripts, etc.)
>There's always lout, but it doesn't look as nice (output wise of
>course, the name (lout vs TeX) makes no difference to me ...) ...

Sure. Lout is nice too. It seems to have some performance
issues to overcome, though. But it definitely has potential.
(On the other hand, I like troff, so take anything I say
with that in mind. :-)

Cheers,

James

--
James McCarron
cat(``,op(zip(cat,[seq(_,_="Js nte al akr")],[seq(_,_="utAohrMpeHce ")])));

0 new messages