Can I use Lisp?

64 views
Skip to first unread message

anon...@nosuchisp.com

unread,
Oct 24, 2000, 12:00:12 AM10/24/00
to
If a Lisp vendor does not allow distribution of the Lisp compiler with
runtimes, is there some other way to translate a special purpose programming
language to Lisp and execute the result? Could the result be made as fast as
C++ for handling large amounts of simple data?

I've been told not to continue considering Lisp, because of considerations
such as the above. I would like to have some good arguments available, just
in case I get a chance to argue in favor of Lisp again. The hardest point to
argue against is that the fastest Lisp, Allegro, does not allow distribution
of the compiler with runtimes, and the 2nd fastest Lisp, Xanalys, is several
times slower.

I'm omitting my name because one of my coworkers has a nasty habit of doing
global searches to see what each of us is posting about, and my name is
unique enough to be easy to search on. I don't have a blind box handy for
replies, so please post them. Thanks in advance.

Rainer Joswig

unread,
Oct 24, 2000, 1:00:02 AM10/24/00
to
In article <a21avscr983i8112j...@4ax.com>,
anon...@nosuchisp.com wrote:

> If a Lisp vendor does not allow distribution of the Lisp compiler with
> runtimes, is there some other way to translate a special purpose programming
> language to Lisp and execute the result? Could the result be made as fast as
> C++ for handling large amounts of simple data?

- one could use some of the CL->C compilers, compile
the Lisp code to C and link the compiled code into the running
Lisp system

- use a self-written (in Lisp) compiler (your language -> C) and
link the resulting code to your running Lisp (this is the way
a sound synthesis program written in Lisp works)

- maybe use CMU CL

> I've been told not to continue considering Lisp, because of considerations
> such as the above. I would like to have some good arguments available, just
> in case I get a chance to argue in favor of Lisp again. The hardest point to
> argue against is that the fastest Lisp, Allegro, does not allow distribution
> of the compiler with runtimes,

I think you can get a license from Franz for doing that - it may be
expensive, though.

> and the 2nd fastest Lisp, Xanalys, is several
> times slower.

Contact Xanalys with some simple benchmarks. In general I found LispWorks
to be quite fast - maybe you need to change the code a bit to make it perform
better (this is not unusual). Lisp compiler usually have different
ideas of how and when to optimize. CMU CL at full verbosity gives
a lot of ideas where code can be improved - its compiler tells
you what kind of optimization it does and which not (and why not). The
Lisp machine's compiler, for example, ignores almost all declarations -
but there are plenty special tools to speed up execution.
I guess, Xanalys would be happy to improve their compiler,
in case there is a real problem.

--
Rainer Joswig, Hamburg, Germany
Email: mailto:jos...@corporate-world.lisp.de
Web: http://corporate-world.lisp.de/

Friedrich Dominicus

unread,
Oct 24, 2000, 12:59:21 AM10/24/00
to
anon...@nosuchisp.com writes:

>
> I'm omitting my name because one of my coworkers has a nasty habit of doing
> global searches to see what each of us is posting about, and my name is
> unique enough to be easy to search on. I don't have a blind box handy for
> replies, so please post them. Thanks in advance.

This is the most redicoulous stuff I ever have written. Why do you
care about a co-worker. It's your life and you're opinion. Times of
slavery should have gone forever, and if you don't stand up, then
resign. And search for a more open minded environment.

Why do you post this question here and do not ask the vendors
directly? I'm quite sure that one can find an agreement which suits
both sided.

And for the speed of C++ please have a look at:
http://www-aig.jpl.nasa.gov/public/home/gat/lisp-study.html

just really good C Programmers get it faster than C++ programs. So at
least in this study Lisp beats hand down.

And nowhere did you mention what kind of problem you're working on. So
how should anyone have an idea if Common Lisp would suit the
requirements?

Friedrich

--
for e-mail reply remove all after .com

Tim Bradshaw

unread,
Oct 24, 2000, 3:00:00 AM10/24/00
to
anon...@nosuchisp.com writes:

> If a Lisp vendor does not allow distribution of the Lisp compiler with
> runtimes, is there some other way to translate a special purpose programming
> language to Lisp and execute the result? Could the result be made as fast as
> C++ for handling large amounts of simple data?
>

I think that if you want native code compilation at some stage in the
process, then you need the compiler, so your choice is really either
to have the compiler or live with an interpreter. Of course the
interpreter may be faster than C++...

> I've been told not to continue considering Lisp, because of considerations
> such as the above. I would like to have some good arguments available, just
> in case I get a chance to argue in favor of Lisp again. The hardest point to
> argue against is that the fastest Lisp, Allegro, does not allow distribution
> of the compiler with runtimes, and the 2nd fastest Lisp, Xanalys, is several
> times slower.
>

There are other lisp systems which allow distributiion of the compiler
and can certainly be competitive in terms of performance. CMUCL is
often pretty good. As far as I'm aware none of the free systems
competes very well with the commercial ones in terms of overall
quality, support, completeness of implementation and number of
platforms supported, but this is only a problem if you need these
things. Significant commercial applications (yahoo store) have
been written using noncommercial lisps.

--tim

Erik Naggum

unread,
Oct 24, 2000, 3:00:00 AM10/24/00
to
* anon...@nosuchisp.com

| If a Lisp vendor does not allow distribution of the Lisp compiler
| with runtimes, ...

Then the right approach is to ask that vendor what it would take to
get permission to do that. All vendors allow distribution of the
Lisp compiler with runtimes, but at different terms than without.

| I've been told not to continue considering Lisp, because of
| considerations such as the above.

Most likely, you will be told not to continue to consider Lisp after
this issue has been resolved, because it is so obviously bogus.

You can most probably do without the compiler. Provided that you
compile enough of the support system, the interpreter can be used to
process a higher-level language in such a way that more than 90% of
the processing time is still spent in compiled code. This means
designing your own application-level language, but that's part of
the fun with programming in a powerful language.

| The hardest point to argue against is that the fastest Lisp,
| Allegro, does not allow distribution of the compiler with runtimes,

This is fortunately just plain wrong. Just call them and ask.

| I'm omitting my name because one of my coworkers has a nasty habit
| of doing global searches to see what each of us is posting about,
| and my name is unique enough to be easy to search on.

Please accept my sympathies. Cow-orkers like that should be shot.
(Now, if anyone of mine does the same, he sure won't tell anyone. :)

#:Erik
--
I agree with everything you say, but I would
attack to death your right to say it.
-- Tom Stoppard

Fernando Rodríguez

unread,
Oct 24, 2000, 3:00:00 AM10/24/00
to
On 24 Oct 2000 10:27:59 +0100, Tim Bradshaw <t...@tfeb.org> wrote:

>anon...@nosuchisp.com writes:

>things. Significant commercial applications (yahoo store) have
>been written using noncommercial lisps.

Do you know what lisp was used for Yahoo store? O:-) Just curious...


//-----------------------------------------------
// Fernando Rodriguez Romero
//
// frr at mindless dot com
//------------------------------------------------

Tim Bradshaw

unread,
Oct 24, 2000, 3:00:00 AM10/24/00
to
Fernando Rodríguez <spa...@must.die> writes:

> Do you know what lisp was used for Yahoo store? O:-) Just curious...
>

CLISP (at least this was true sometime in late 98, when Paul Graham
gave his LUGM talk on it)

--tim

glauber

unread,
Oct 24, 2000, 3:00:00 AM10/24/00
to
In article <nkjr956...@tfeb.org>,


In my (limited) experience, CLISP is often fast enough. In the PC, well
optimized code often runs as fast compiled in CLISP as it does in Corman Lisp
(a machine-language compiler). Corman beats CLISP easily on sloppy code,
though...

Corman is also a very good option for Windows machines. It's not free, but
it's not very expensive either (at $200 it's just about $100 more than what i
want to spend now). Still, Roger Corman is very nice to allow you to use the
bare-bones character environment for free.

glauber

--
Glauber Ribeiro
thegl...@my-deja.com http://www.myvehiclehistoryreport.com
"Opinions stated are my own and not representative of Experian"


Sent via Deja.com http://www.deja.com/
Before you buy.

Erik Naggum

unread,
Oct 24, 2000, 3:00:00 AM10/24/00
to
* glauber <thegl...@my-deja.com>

| In my (limited) experience, CLISP is often fast enough. In the PC, well
| optimized code often runs as fast compiled in CLISP as it does in Corman Lisp
| (a machine-language compiler). Corman beats CLISP easily on sloppy code,
| though...

CLISP is often good enough as long as you do not write any functions
of your own that implement any abstractions that require multiple
calls to user-land functions. CLISP's performance dichotomy between
its C-implemented compiled runtime functions and your byte-compiled
Lisp functions leads programmers to optimize at a low abstraction
level because they are penalized for their abstractions. This is
not a good thing for a Lisp environment, where we want to encourage
function calls and make abstractions as inexpensive as possible. We
don't want people _not_ to use Common Lisp because of performance
issues or to think that only built-ins are fast because they are
written in C. Approach CLISP as a good toy implementation of Common
Lisp, and move on to a real compiler if you ever plan to investigate
performance issues.

Paolo Amoroso

unread,
Oct 24, 2000, 3:00:00 AM10/24/00
to
On 24 Oct 2000 14:32:46 +0100, Tim Bradshaw <t...@tfeb.org> wrote:

> CLISP (at least this was true sometime in late 98, when Paul Graham
> gave his LUGM talk on it)

Which subsystems of Yahoo! Store were developed with CLISP?


Paolo
--
EncyCMUCLopedia * Extensive collection of CMU Common Lisp documentation
http://cvs2.cons.org:8000/cmucl/doc/EncyCMUCLopedia/

Will Hartung

unread,
Oct 24, 2000, 3:00:00 AM10/24/00
to
Paolo Amoroso wrote in message ...

>On 24 Oct 2000 14:32:46 +0100, Tim Bradshaw <t...@tfeb.org> wrote:
>
>> CLISP (at least this was true sometime in late 98, when Paul Graham
>> gave his LUGM talk on it)
>
>Which subsystems of Yahoo! Store were developed with CLISP?


It is my understanding that there is an, essentially, batch process in CLISP
that is used to create the pages for the individual stores. CLISP isn't used
to actually "run" the site, but rather to generate a set of related static
pages.

Somewhere, perhaps PG's home page (not that I have the URL, mind you), is
his enumerations about "Web Success". In them he frowns on server generated
HTML pages, so this would fit in quite well philisophically.

It's also interesting because people have to be thinking "How the heck is
Yahoo! driving a web site with CLISP?!?!??".

Simple, it isn't!

While everyone discusses the how to write web servers in Lisp, here's an
application that simply punts on the entire issue.

Of course, not every web application can be met with a block of static
pages, but many can.

Regards,

Will Hartung
(will.h...@havasint.com)


Christopher Browne

unread,
Oct 24, 2000, 10:44:40 PM10/24/00
to
In our last episode (Tue, 24 Oct 2000 18:00:09 -0700),

the artist formerly known as Will Hartung said:
>Paolo Amoroso wrote in message ...
>>On 24 Oct 2000 14:32:46 +0100, Tim Bradshaw <t...@tfeb.org> wrote:
>>
>>> CLISP (at least this was true sometime in late 98, when Paul Graham
>>> gave his LUGM talk on it)
>>
>>Which subsystems of Yahoo! Store were developed with CLISP?
>
>It is my understanding that there is an, essentially, batch process in CLISP
>that is used to create the pages for the individual stores. CLISP isn't used
>to actually "run" the site, but rather to generate a set of related static
>pages.
>
>Somewhere, perhaps PG's home page (not that I have the URL, mind you), is
>his enumerations about "Web Success". In them he frowns on server generated
>HTML pages, so this would fit in quite well philisophically.

<http://www.paulgraham.com/mistakes.html>

The thing that seems most relevant:
Dynamically generated HTML is bad, because search engines ignore it.

And he comments that slow loading of pages is bad, and static generation
certainly means that there's no "runtime" cost to a lot of this...

>It's also interesting because people have to be thinking "How the heck
>is Yahoo! driving a web site with CLISP?!?!??".
>
>Simple, it isn't!
>
>While everyone discusses the how to write web servers in Lisp, here's an
>application that simply punts on the entire issue.

If it gets too slow, they need only spawn a few more CLISP processes to
do batch work. It doesn't forcibly hurt the runtime behaviour. Which is
pretty cool.

It's not particularly visible in looking at some of the HTML that is
generated; they don't have any <meta name="generator" content="CLISP">
tags :-). The HTML is very vaguely reminiscent in style to what is
generated by the application in his book "Common Lisp"

>Of course, not every web application can be met with a block of static
>pages, but many can.

This is in effect the same idea as the decision between:
a) Resolving code at compile time, using macros, versus
b) Resolving behaviour at runtime via some sort of dispatching.

Work that is done at compile time need never be done at runtime,
obviously saving that bit of CPU then. It doesn't too much matter how
slow CLISP is if the code is run at "compile" time.

In a sense, this application represents the opposite to the way
people tend to promote Lisp; "Lisp as Dynamic Language."

And I fairly heartily agree.
a) Search Engines Are Your Friend.
b) Web Apps tend to make Really Stupid Use of dynamic evaluation.
When they use JavaScript to do things that would be just as nicely
represented by static links, That's Really Stupid.
--
cbbr...@acm.org - <http://www.hex.net/~cbbrowne/linux.html>
(THASSERT (PLANNER RG))
-- Example of HACKER statement.

Robert Monfera

unread,
Oct 24, 2000, 11:01:15 PM10/24/00
to
glauber wrote:

> In my (limited) experience, CLISP is often fast enough. In the PC,
> well optimized code often runs as fast compiled in CLISP as it does in
> Corman Lisp (a machine-language compiler). Corman beats CLISP easily

> on sloppy code though...

My limited experience with Corman Lisp tells that undeclared, general
code runs quite fast on it relative to other implementations (though
declarations don't make much difference). I would not call undeclared
code sloppy, and probably it's not what you have meant, so I'm wondering
about the meaning of "sloppyness" that favors one implementation over
the other. Any specifics?

Robert

Rob Warnock

unread,
Oct 25, 2000, 1:37:26 AM10/25/00
to
Christopher Browne <cbbr...@hex.net> wrote:
+---------------

| Will Hartung said:
| >Somewhere, perhaps PG's home page (not that I have the URL, mind you), is
| >his enumerations about "Web Success". In them he frowns on server generated
| >HTML pages, so this would fit in quite well philisophically.
|
| <http://www.paulgraham.com/mistakes.html>
| The thing that seems most relevant:
| Dynamically generated HTML is bad, because search engines ignore it.
+---------------

Also see Philip Greenspun's comments on this issue, and his solution:

<URL:http://www.arsdigita.com/books/panda/publicizing>
[...skip down 2/3 of the way...]
Hiding Your Content from Search Engines (By Mistake)
...
I built a question and answer forum...all the postings were
stored in a relational database. ... The URLs end up looking
like "http://photo.net/bboard/fetch-msg.tcl?msg_id=000037".
...
AltaVista comes along and says, "Look at that question mark.
Look at the strange .tcl extension. This looks like a CGI script
to me. I'm going to be nice and not follow this link even though
there is no robots.txt file to discourage me."

Then WebCrawler says the same thing.

Then Lycos.

I achieved oblivion.

Briefly, his solution was:

Write another AOLServer TCL program that presents all the messages
from URLs that look like static files, e.g., "/fetch-msg-000037.html"
and point the search engines to a huge page of links like that.
The text of the Q&A forum postings will get indexed out of these
pseudo-static files and yet I can retain the user pages with their
*.tcl URLs.
...
(see my discussion of why the AOLserver *.tcl URLs are so good in
the chapters on Web programming; see http://photo.net/wtr/thebook/
bboard-for-search-engines.txt for the source code).

[Greenspun uses Tcl where many of us would choose Lisp (or even Scheme).]


-Rob

-----
Rob Warnock, 31-2-510 rp...@sgi.com
Network Engineering http://reality.sgi.com/rpw3/
Silicon Graphics, Inc. Phone: 650-933-1673
1600 Amphitheatre Pkwy. PP-ASEL-IA
Mountain View, CA 94043

Fernando Rodríguez

unread,
Oct 25, 2000, 3:00:00 AM10/25/00
to
On Wed, 25 Oct 2000 02:44:40 GMT, cbbr...@knuth.brownes.org (Christopher
Browne) wrote:


>The thing that seems most relevant:
> Dynamically generated HTML is bad, because search engines ignore it.

As long as your link doesn't look like a cgi script, you may fool a
robot into following it and indexing it, but usually it's not a good idea (for
you and the search engine).

Christian Nybų

unread,
Oct 25, 2000, 3:00:00 AM10/25/00
to
Fernando Rodríguez <spa...@must.die> writes:

> As long as your link doesn't look like a cgi script, you may fool a
> robot into following it and indexing it, but usually it's not a good
> idea (for you and the search engine).

Why? As long as my site provides a finite number of resources, I
don't see how it's anyone else's business how the pages were
generated.
--
chr

Fernando Rodríguez

unread,
Oct 25, 2000, 3:00:00 AM10/25/00
to

As long as your contents is limited its ok, but systematically
following cgi scripts could end up dumping huge databases into the index as
well putting too much load on your server.

Eric Marsden

unread,
Oct 25, 2000, 3:00:00 AM10/25/00
to
>>>>> "en" == Erik Naggum <er...@naggum.net> writes:

en> CLISP is often good enough as long as you do not write any
en> functions of your own that implement any abstractions that
en> require multiple calls to user-land functions.

en> Approach CLISP as a good toy implementation of Common Lisp, and
en> move on to a real compiler if you ever plan to investigate
en> performance issues.

I agree with your second statement, but don't see any justification
for the first, unless you implicitly assume that every programmer is
interested in performance on each problem. If I am not particularly
concerned about performance, I will not notice the slowdown from
user-defined functions, so I will not be discouraged from using
abstraction.

--
Eric Marsden <URL:http://www.laas.fr/~emarsden/>

Erik Naggum

unread,
Oct 25, 2000, 3:00:00 AM10/25/00
to
* Eric Marsden <emar...@mail.dotcom.fr>

| I agree with your second statement, but don't see any justification
| for the first, unless you implicitly assume that every programmer is
| interested in performance on each problem. If I am not particularly
| concerned about performance, I will not notice the slowdown from
| user-defined functions, so I will not be discouraged from using
| abstraction.

This is a good point. I tend to stress that CLISP is not suitable
if your goal is performance, anyhow, so I should also argue that
it's good enough as long as you don't prioritize performance.

_However_, my experience is that even though you ignore performance
(as long as you get your answers within a reasonable amount of time),
a large number of programmers will want to know the "expensiveness"
of what they do and then soon discover that builtins in CLISP are
very fast (especially bignums) while their own code runs much, much
slower. Even if you ignore performance consciously, I don't think
you can completely ignore the effect of _observing_ that some things
are much faster than others even if you did not set out to find out
about this to begin with.

Hence my cautions. If you know about them and are aware of the
conditions under which CLISP is and is not good enough, I don't
think CLISP is a bad choice (as long as you use the ANSI mode with
the -a option, but that that's not the default is another gripe).

glauber

unread,
Oct 25, 2000, 3:00:00 AM10/25/00
to
In article <31814771...@naggum.net>,
Erik Naggum <er...@naggum.net> wrote:
[...]

> Hence my cautions. If you know about them and are aware of the
> conditions under which CLISP is and is not good enough, I don't
> think CLISP is a bad choice (as long as you use the ANSI mode with
> the -a option, but that that's not the default is another gripe).


Erik, i'm curious to know if you have a favorite among the free Unix Common
Lisp implementations.

Erik Naggum

unread,
Oct 25, 2000, 11:02:11 PM10/25/00
to
* glauber <thegl...@my-deja.com>

| Erik, i'm curious to know if you have a favorite among the free Unix
| Common Lisp implementations.

When I looked around for Common Lisp environments back in late 1993
so I could program in a programming language instead of killing
myself with C++, I tried a number of languages, including Ada,
Smalltalk, Scheme and Common Lisp, all of which have reasonably good
free implementations. (MIT Scheme was excellent, but Scheme is one
of those languages that are OK only as long as you live in a dorm
room and are unaware that you will eventually want to buy a house.)

Common Lisp implementations included CLISP and CMUCL at the time and
CLISP was immature and nearly useless at the time, even worse than
KCL, which a friend got his hands on sometime in 1987. CMUCL has
been excellent all the time I have used it, but I was unimpressed
with the CLOS (PCL) performance and hence did not work a lot with
that part of CL until I got Allegro CL. I still have a complete
CMUCL system installed on my system and occasionally use it to
ensure that I know which parts of my code are portable to it, but I
no longer use it in any "production system" sense.

glauber

unread,
Oct 26, 2000, 9:55:53 AM10/26/00
to
In article <31815181...@naggum.net>,

Erik Naggum <er...@naggum.net> wrote:
> * glauber <thegl...@my-deja.com>
> | Erik, i'm curious to know if you have a favorite among the free Unix
> | Common Lisp implementations.
>
> When I looked around for Common Lisp environments back in late 1993
> so I could program in a programming language instead of killing
> myself with C++, I tried a number of languages, including Ada,
> Smalltalk, Scheme and Common Lisp, all of which have reasonably good
> free implementations. (MIT Scheme was excellent, but Scheme is one
> of those languages that are OK only as long as you live in a dorm
> room and are unaware that you will eventually want to buy a house.)


:-)

It's really nice, and it makes you reinvent the wheel each time, but hey,
it's so easy to reinvent the wheel in Scheme that many people don't care.
Some people apparently have a lot of free time.


> Common Lisp implementations included CLISP and CMUCL at the time and
> CLISP was immature and nearly useless at the time, even worse than
> KCL, which a friend got his hands on sometime in 1987. CMUCL has
> been excellent all the time I have used it, but I was unimpressed
> with the CLOS (PCL) performance and hence did not work a lot with
> that part of CL until I got Allegro CL. I still have a complete
> CMUCL system installed on my system and occasionally use it to
> ensure that I know which parts of my code are portable to it, but I
> no longer use it in any "production system" sense.


I downloaded CMUCL thinking maybe i could get it to compile for AIX and
Windows (the platforms i currently work in), but it looks like setting it up
is a daunting task.

CLISP has some pretty strange C source, but it compiled fine in AIX and had a
pre-made Windows binary. I'm glad for CLISP, because if it wasn't for it i
wouldn't have tried to learn Common Lisp (i'd probably be using some version
of Scheme instead). I think it's nice of Franz to let people have a limited
version of Allegro for free, but it's too limited for my needs and i'm just
not going to pay for the full system. So i guess i'll be using "CLISP -a" for
the time being until i have justification to buy a commercial system.

Incidentally, it seems that there's a lot more interest in developing free
Scheme systems than Lisp. I guess it's to be expected, since Scheme is
designed to be simple to implement.

Fernando Rodríguez

unread,
Oct 26, 2000, 1:11:16 PM10/26/00
to
On Thu, 26 Oct 2000 13:55:53 GMT, glauber <thegl...@my-deja.com> wrote:

>In article <31815181...@naggum.net>,
> Erik Naggum <er...@naggum.net> wrote:
>> * glauber <thegl...@my-deja.com>
>> | Erik, i'm curious to know if you have a favorite among the free Unix
>> | Common Lisp implementations.
>>
>> When I looked around for Common Lisp environments back in late 1993
>> so I could program in a programming language instead of killing
>> myself with C++, I tried a number of languages, including Ada,
>> Smalltalk, Scheme and Common Lisp, all of which have reasonably good
>> free implementations. (MIT Scheme was excellent, but Scheme is one
>> of those languages that are OK only as long as you live in a dorm
>> room and are unaware that you will eventually want to buy a house.)
>
>
>:-)
>
>It's really nice, and it makes you reinvent the wheel each time, but hey,
>it's so easy to reinvent the wheel in Scheme that many people don't care.
>Some people apparently have a lot of free time.

You're missing the point: Scheme was designed as a teaching and
investigation tool, not for "real world" programming. As a learning language
it has been far more successful that CL as a general purpose language. :-P

Rainer Joswig

unread,
Oct 26, 2000, 1:22:26 PM10/26/00
to
In article <9dlgvskf0q2aia8hl...@4ax.com>, Fernando
Rodr?guez <spa...@must.die> wrote:

> On Thu, 26 Oct 2000 13:55:53 GMT, glauber <thegl...@my-deja.com> wrote:
>
> >In article <31815181...@naggum.net>,
> > Erik Naggum <er...@naggum.net> wrote:
> >> * glauber <thegl...@my-deja.com>
> >> | Erik, i'm curious to know if you have a favorite among the free Unix
> >> | Common Lisp implementations.
> >>
> >> When I looked around for Common Lisp environments back in late 1993
> >> so I could program in a programming language instead of killing
> >> myself with C++, I tried a number of languages, including Ada,
> >> Smalltalk, Scheme and Common Lisp, all of which have reasonably good
> >> free implementations. (MIT Scheme was excellent, but Scheme is one
> >> of those languages that are OK only as long as you live in a dorm
> >> room and are unaware that you will eventually want to buy a house.)
> >
> >
> >:-)
> >
> >It's really nice, and it makes you reinvent the wheel each time, but hey,
> >it's so easy to reinvent the wheel in Scheme that many people don't care.
> >Some people apparently have a lot of free time.
>
> You're missing the point: Scheme was designed as a teaching and
> investigation tool, not for "real world" programming. As a learning language
> it has been far more successful that CL as a general purpose language. :-P

When is a general purpose language successful? How much
in software sales would that be for example?

Pierre R. Mai

unread,
Oct 26, 2000, 12:46:30 PM10/26/00
to
glauber <thegl...@my-deja.com> writes:

> I downloaded CMUCL thinking maybe i could get it to compile for AIX and
> Windows (the platforms i currently work in), but it looks like setting it up
> is a daunting task.

Since Windows is not a supported OS, you'd have to write low-level
support for the OS (e.g. signal handling code), etc. first. With AIX
the situation is even worse, since CMUCL has neither support for AIX,
nor a compiler back-end for the POWER processor.

In any case you'd need access to a platform that has a working CMUCL
first, for the cross-compilation.

Regs, Pierre.

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

glauber

unread,
Oct 26, 2000, 6:49:48 PM10/26/00
to
In article <87og07t...@orion.bln.pmsf.de>,

"Pierre R. Mai" <pm...@acm.org> wrote:
> glauber <thegl...@my-deja.com> writes:
>
> > I downloaded CMUCL thinking maybe i could get it to compile for AIX and
> > Windows (the platforms i currently work in), but it looks like setting it up
> > is a daunting task.
>
> Since Windows is not a supported OS, you'd have to write low-level
> support for the OS (e.g. signal handling code), etc. first. With AIX
> the situation is even worse, since CMUCL has neither support for AIX,
> nor a compiler back-end for the POWER processor.
>
> In any case you'd need access to a platform that has a working CMUCL
> first, for the cross-compilation.


Thanks!

That's exactly what it looked like to me, and i decided to stay away for now.

g

Erik Naggum

unread,
Oct 26, 2000, 7:46:59 PM10/26/00
to
* Fernando Rodríguez -> glauber

| Scheme was designed as a teaching and investigation tool, not for
| "real world" programming.

The problem with tools that are only good for the teaching/learning
process is that they are actually teaching many very bad things
amidst all the good stuff. It is good to learn how to build your
own tools. It is bad to learn that you have to, meaning that you
are more likely to spend a lot of time building something that is
already out there rather than try to understand it and use it. It
is good to learn recursion instead of iteration because it expands
the way you think in ways those who don't grasp recursion cannot
fathom. It is bad _not_ to learn iteration and when it is a good
thing, when it is more readable and understandable than recursion,
and above all, when recursion would kill you performance-wise and
iteration would not. It's just like the irrational gotophobia that
some students of programming have (no real programmer _fears_ goto)
because they have never actually seen the hell and spaghetti code
that they have been saved from by structured programming.

| As a learning language it has been far more successful that CL as a
| general purpose language. :-P

Hmpf! But this probably _is_ true. Scheme succeeds because it is
easy to teach to bright people and fun to implement. Hence, we have
about a million implementations of Scheme, and only one of them is
good for anything more than teaching others how to implement Scheme.

Christopher Browne

unread,
Oct 27, 2000, 12:06:38 AM10/27/00
to
Centuries ago, Nostradamus foresaw a time when Erik Naggum would say:

>* Fernando Rodríguez -> glauber
>| Scheme was designed as a teaching and investigation tool, not for
>| "real world" programming.
>
> The problem with tools that are only good for the teaching/learning
> process is that they are actually teaching many very bad things
> amidst all the good stuff. It is good to learn how to build your
> own tools. It is bad to learn that you have to, meaning that you
> are more likely to spend a lot of time building something that is
> already out there rather than try to understand it and use it. It
> is good to learn recursion instead of iteration because it expands
> the way you think in ways those who don't grasp recursion cannot
> fathom. It is bad _not_ to learn iteration and when it is a good
> thing, when it is more readable and understandable than recursion,
> and above all, when recursion would kill you performance-wise and
> iteration would not. It's just like the irrational gotophobia that
> some students of programming have (no real programmer _fears_ goto)
> because they have never actually seen the hell and spaghetti code
> that they have been saved from by structured programming.

I would submit that if Common Lisp was used instead of Scheme,
instead of the modules using:

(define (reverse lst)
(if (pair? lst)
(append (reverse (cdr lst)) (list (car lst)))
lst))

They would instead spend three weeks demonstrating recursion using:

(defun reverse (list)
(if (consp list)
(append (reverse (cdr list)) (list (car list)))
list))

Instead of spending a couple weeks ignoring the Scheme DO form, they
would spend a couple weeks ignoring DO and LOOP and all the other
iterative functions of CL.

Courses generally don't seem to present the more "advanced" structures
of Scheme, such as hash tables, macros, and records/structures. I
would question why you'd expect them to teach more about CL.
--
aa...@freenet.carleton.ca - <http://www.hex.net/~cbbrowne/lsf.html>
History of Epistemology in One Lesson
"First Hume said "We can't really know anything", but nobody believed
him, including Hume. Then Popper said "Hume was right, but here's what
you can do instead...". Bartley then debugged Popper's code."
-- Mark Miller

Erik Naggum

unread,
Oct 27, 2000, 1:14:26 AM10/27/00
to
* Christopher Browne

| Courses generally don't seem to present the more "advanced" structures
| of Scheme, such as hash tables, macros, and records/structures. I
| would question why you'd expect them to teach more about CL.

I made no comments to that effect. Why do you think I expect that?
I don't _compare_ the two languages -- I'm simply pointing out
serious flaws in Scheme and how it is taught and used. Since we
don't have any data on how CL would be taught if it were where
Scheme is, I fail to see how I could be thought to _expect_ any
improvements just by changing the language being taught.

#:Erik
--
Does anyone remember where I parked Air Force One?
-- George W. Bush

Fernando Rodríguez

unread,
Oct 27, 2000, 4:47:16 AM10/27/00
to
On Thu, 26 Oct 2000 19:22:26 +0200, Rainer Joswig
<jos...@corporate-world.lisp.de> wrote:


>>
>> You're missing the point: Scheme was designed as a teaching and
>> investigation tool, not for "real world" programming. As a learning language
>> it has been far more successful that CL as a general purpose language. :-P
>
>When is a general purpose language successful? How much
>in software sales would that be for example?

Don't take me wrong, I like Cl and I hope that growing usage of scheme
in colleges will benefit CL: some of the students that were introduced to
scheme might turn to CL when looking for something more powerful.

Rainer Joswig

unread,
Oct 27, 2000, 5:41:26 AM10/27/00
to
In article <i8givss0fresr7bi0...@4ax.com>, Fernando
Rodr?guez <spa...@must.die> wrote:

> On Thu, 26 Oct 2000 19:22:26 +0200, Rainer Joswig
> <jos...@corporate-world.lisp.de> wrote:
>
>
> >>
> >> You're missing the point: Scheme was designed as a teaching and
> >> investigation tool, not for "real world" programming. As a learning language
> >> it has been far more successful that CL as a general purpose language. :-P
> >
> >When is a general purpose language successful? How much
> >in software sales would that be for example?
>
> Don't take me wrong, I like Cl and I hope that growing usage of scheme
> in colleges will benefit CL:

Usage of Lisp at Schools/Colleges/Universities is **crucial** for
the success and survival of Lisp. This is the number one source for
contacts with Lisp technology (another being the
GNU/Linux/Free Software/Open Source movements).

> some of the students that were introduced to
> scheme

"Introduced to Scheme" doesn't mean they are doing something useful
(-> writing software that's being used by somebody) with it.
I have seen "academic exercises" ("write a routine that reverses a list" -
Common Lisp spoiled the party, since half of the exercises are
already standard in CL and many others got trivial).
So Scheme is often not taught as an introduction to "Scheme and
software development", but as an introduction to Computer Science
and as a kind of academic puzzle. CS students are often
not introduced to the idea that there is a customer for
the software, that he has a problem that has to be solved
and that he might have limited time and money.

> might turn to CL when looking for something more powerful.

Since often Scheme has not been used "useful", students later will
not look for Common Lisp, but for the obvious C++ and friends.
I think students take Common Lisp because they have to.
It is more of a tradtion question. Instructors often use Scheme
in basic courses and in their research projects Common Lisp
becomes an option. They can select the better students and
in multi-year, multi-university projects Common Lisp often is
(was?) a viable solution.

How could one make CL even more successful in Universities?

- all students should get access to the best Lisp environment around.
Many universities have site licenses for Lisp on their
Unix clusters. This should be extended to PCs/Macs/Linux/... .

- Enable application delivery in Lisp (it is technical possible,
but it needs to be painless -> costs? license? distribution options?
platforms? compiler distribution? downloading software?
application toolkits?), so students will learn that
writing APPLICATIONS in Lisp is a viable option.

- provide introductory material, so that students quickly can move on
from Scheme to CL. What are the differences to Scheme? The student
might have seen SICP, how does she apply this knowledge
to CL?

- follow research trends so that Lisp stays an option for research
projects

- somebody has to explain how to actually develop software with
Common Lisp, what the tools are and why they are the way they
are. Nice books were/are "LISP Style and Design" (Miller, Molly M.,
and Eric Benson, Digital Press, no longer available - sigh)
and "Lisp Lore: A Guide to Programming the Lisp Machine"
(Bromley/Lamson, still available I guess, but expensive).

Like somebody explained how one might develop software
using Smalltalk in a commercial environment (-> XP).

- make sure the Lisp software developed in Universities are
as accessible as possible for the public. Others might
want to use it or learn from it.

Kent M Pitman

unread,
Oct 27, 2000, 5:41:25 AM10/27/00
to
Erik Naggum <er...@naggum.net> writes:

> * Christopher Browne
> | Courses generally don't seem to present the more "advanced" structures
> | of Scheme, such as hash tables, macros, and records/structures. I
> | would question why you'd expect them to teach more about CL.

First, while these may be the "advanced structures" of Scheme, they are hardly
advanced by today's standards. This, fundamentally, is the challenge that
faces Lisp today. When I graduated from college, now too many years ago to
remember, it was exactly as Christopher says here, I had special knowledge of
the advanced fabric of computation that would get me farther and faster than
anyone else--I knew how to use Lisp and Lisp gave me a leg up on the kinds of
computations that I'd need to be doing. While others (say, C programmers)
were going to need hash tables in their computations, they had to remember
details of their implementation. Not so with Lisp--I could just ask for a
hash table because I wanted its big-O computational properties for storage
and access and immediately move to the business of USING hash tables. Ditto,
it was a big deal thing to have "records/structures" to help me organize my
thoughts back then. Ideas like inheritance of methods and structure were new
and just knowing them was a leap ahead. No longer so.

Lisp provides considerable computational power, but without continual tracking
of what people today think are "advanced structures", we're hosed. This is
why I have made a big point to any Lisp vendor who would listen of saying that
you must not charge for "connective tissue" to other languages. An RMI
interface is essential right now, and nobody better charge for it. In the
meantime, it's a darned shame they're charging for CORBA. Maybe if there were
both it would be ok to charge for CORBA, but the problem is that right now
the modern functionality that people think in terms of is jpegs and gifs,
audio streams, http servers, html and xml data, fonts and font metrics, and so
on. These are programming tasks to the Lisp world, as hash tables were
programming tasks to the C world of my generation, but they are library
operations to Java and well should be to Lisp. If Lisp could access Java for
free, it could leverage all the good work that people have done in library
creation in Java and on top of all that good work could add a rational
language connective glue because Java truly sucks. However, for as much as
Java sucks for programming, as long as it keeps producing high quality
libraries, the amount of coding you have to do in that sucky language in order
to get work done is, relatively speaking, small in order not to do the
visionary things Lisp people want to do but in order to stay far enough ahead
of competition to make money. And so Java succeeds while Lisp fails, even
though Lisp has tons to teach Java.

Java people do not talk about record structures as advanced. They might
talk about macros as advanced if only the language had them, but only for a
short while I suspect. Those are glue issues and must never have the word
advanced in front of them because they are the fundamental building blocks of
thought. If teachers of languages don't teach people how to use the building
blocks and insist to people that this is basic stuff, there is no hope people
will ever get to the advanced stuff because they'll rest on their laurels
having achieved the faux superiority of understanding record structures.

Now, back to Erik's comment about the quote above...

> I made no comments to that effect. Why do you think I expect that?
> I don't _compare_ the two languages -- I'm simply pointing out
> serious flaws in Scheme and how it is taught and used. Since we
> don't have any data on how CL would be taught if it were where
> Scheme is, I fail to see how I could be thought to _expect_ any
> improvements just by changing the language being taught.

I'm not entirely sure I agree with Erik here. The way I'd say it is that
the languages are structured in a way that leads naturally to a certain
teaching. Scheme is ABOUT being spartan. It is about saying that the
langauge eschews libraries and in some ways barely tolerates, as an
orderly addition, syntactic abstraction. It is entirely about a teaching
order in which people learn to think in the language without abstraction
and then learn to think of the abstraction as an "add-on".

Lisp, taught properly, is about the more democratic (as Erik called it
earlier) and less orderly notion that macros are really in there from
the getgo, and even though one can go back and retroactively explain the
bootstrap order in terms of simpler and more complicated mechanisms, the
fact is that the intended way for people to THINK is to say that macros are
always there, and record structures are always there, and inheritance is
always there, and hash tables are always there. These are not library
structures. A conscious decision was made not to go the ANSI C way of saying
there is the language and there is a library but there might be other libraries
because that leads to deviation of thinking. A conscious decision was made to
say "it's just all there to start with and the whole language/library issue
is purely an issue of efficiency of implementation, subprimitive to the
language itself".

A teacher of Lisp can, and teachers routinely do, confuse CL with Lisp 1.5
and insist that people need to learn to program in terms of car/cdr/cons
and recursion, but those are not acceptable production solutions for commercial
quality CL programmers, and there had better be repair later. I prefer to
think that the problem is that people confuse "algorithms courses" (learning
how to build up useful abstractions from more primitive list and vector
abstractions) with "lisp courses" which should be about using, not
implementing, lisp. The whole POINT of modern lisp which distinguishes it
from early lisp is that it is a USER commodity, designed to hide from the
casual user the horror of implementing COUNT or SEARCH or POSITION or even
LOOP. Those things are not "cheating"--they are what you are intended to do.
And so courses that teach you that their use is wrong are not teaching LISP,
or at least certainly are not teaching CL, they are teaching algorithms and
doing CL the disservice of saying that just because it is computationally
powerful enough to implement low-level algorithms, that it itself is offered
by we the designers and/or implementors FOR that purpose (and often, it is
falsely suggested, either implicitly or explicitly, for no other).

What I do agree with Erik on is the second of his assertions--which is that
we don't have huge amounts of data about how people would teach CL if it had
books that were as popular as Structure and Interpretation of Computer
Programming (S&ICP). I have personally never liked S&ICP, and have never
recommended it to the up and coming reader in spite of its being packed with
very important insights, primarily because it promotes a horrendous programming
style. Historically, and it even seemed so at the time, I believe the reason
was that there was so much "Fortran-esque" indoctrination that people got that
S&ICP intended merely to offer "balance" to the world. However, in offering
balance it did not preach balance. Like the adversarial court system of the
US, it assumed that balance would naturally arise from two people saying the
opposite things--the Fortran people saying that iteration was a process of
stepping through something n times, the Scheme people saying that iteration
was a process of doing something once and then recursing into the problem
with one fewer times needing for it to be done. It amounts to the same. And
a BALANCED approach would teach RESPECT for both approaches. But S&ICP never
went back and did that, and most Scheme courses graduate either people who
have no idea what they learned and hate Lisp/Scheme for being so obtuse or else
zealots who think they have been taught that Fortran-esque iteration is a
confusion to be left aside as foolhardy. Neither of these is a useful outcome.

Like all things in life, good teaching should be monotonic, adding to what
one already knows and providing additional options, not evangelical, replacing
"bad thought" with so-called "good thought". Sometimes, the result of good
teaching will be that the learner will decide they can get away with collapsing
out two ways of thinking about something and using only one, but that should
be a personal choice of the learner, not a choice of the teacher. The teacher
should provide options.

CL is about options. Within it, it provides multiple ways to do
something. The Schemers often hate that. My impression is that they
see any form of redundancy as a weakness. (I think that's why they don't
like our two namespace system, too.) I see it as a strength, and
as a form of tolerance and enlightenment...

glauber

unread,
Oct 27, 2000, 8:01:07 AM10/27/00
to
In article <31815928...@naggum.net>,
Erik Naggum <er...@naggum.net> wrote:
[...]

> Scheme succeeds because it is
> easy to teach to bright people and fun to implement. Hence, we have
> about a million implementations of Scheme, and only one of them is
> good for anything more than teaching others how to implement Scheme.


OK, i'll ask. Which one?

g.

John David Stone

unread,
Oct 27, 2000, 10:18:38 AM10/27/00
to
cbbr...@salesman.brownes.org (Christopher Browne) writes:

> I would submit that if Common Lisp was used instead of Scheme, ...


>
> Instead of spending a couple weeks ignoring the Scheme DO form, they
> would spend a couple weeks ignoring DO and LOOP and all the other
> iterative functions of CL.
>
> Courses generally don't seem to present the more "advanced" structures
> of Scheme, such as hash tables, macros, and records/structures. I
> would question why you'd expect them to teach more about CL.

I haven't done a survey, but I'm skeptical about the generalization
being offered here. At my institution, Scheme is used in the first
course in computer science
(http://www.cs.grinnell.edu/~stone/courses/scheme/), and we present the DO
form (http://www.cs.grinnell.edu/~stone/courses/scheme/iteration.xhtml),
records (http://www.cs.grinnell.edu/~stone/courses/scheme/records.xhtml),
and some other topics that might be considered advanced: multiple values
(http://www.cs.grinnell.edu/~stone/courses/scheme/multiple-valued-procedures.xhtml)
and quasiquotation
(http://www.cs.grinnell.edu/~stone/courses/scheme/metaprogramming.xhtml),
for instance. I have to admit that we save hash tables for our second
course (and leave out CASE-expressions, continuations, and EVAL -- but
those aren't really what programmers are most likely to need, are they?).

--
John David Stone - Lecturer in Computer Science and Philosophy
Manager of the Mathematics Local-Area Network
Grinnell College - Grinnell, Iowa 50112 - USA
st...@cs.grinnell.edu - http://www.cs.grinnell.edu/~stone/

Erik Naggum

unread,
Oct 27, 2000, 6:20:17 AM10/27/00
to
* Rainer Joswig <jos...@corporate-world.lisp.de>

| How could one make CL even more successful in Universities?

Many excellent points omitted, but I suspect one point was omitted
by accident:

- secure funding for all of the above.

Erik Naggum

unread,
Oct 27, 2000, 11:26:39 AM10/27/00
to
* glauber <thegl...@my-deja.com>

| OK, i'll ask. Which one?

Please. I would have been a little happier if you had asked about
the million implementations and had recognized "only one of them" as
the obvious hyperbole.

Wade Humeniuk

unread,
Oct 27, 2000, 11:47:16 AM10/27/00
to
>
> Like all things in life, good teaching should be monotonic, adding to what
> one already knows and providing additional options, not evangelical, replacing
> "bad thought" with so-called "good thought". Sometimes, the result of good
> teaching will be that the learner will decide they can get away with collapsing
> out two ways of thinking about something and using only one, but that should
> be a personal choice of the learner, not a choice of the teacher. The teacher
> should provide options.
>
> CL is about options. Within it, it provides multiple ways to do
> something. The Schemers often hate that. My impression is that they
> see any form of redundancy as a weakness. (I think that's why they don't
> like our two namespace system, too.) I see it as a strength, and
> as a form of tolerance and enlightenment...

Its been about 20 years since I first heard about Lisp. It was at
university and I was talking to a CS major who was taking a course on
compiler and language design. He showed me an example of creating a
Lisp compiler in Lisp. It took about a page and half. I remember being
intrigued by the expressibility of the language, though it was in an
older dialect of Lisp with hardly any indentation. The language stayed
in the back of my mind and I went on to program in Assembler, Pascal, C,
C++ and various other sundry languages.

Then I saw a special edition from the ACM on Lisp. It described
applications it was used for, one of which I was working on at the
time. I decided to learn the language and see if what was said was
true. I started with Scheme, why?, because I had a Mac at home and I
could get my hands on MacScheme. Though no finished program or product
came out of the experience I was hooked on the language. I kept looking
for places to use Scheme on the job and it helped that I had supportive
bosses (who had actually programmed in Lisp). Though the bosses were
sympathetic to programming in Lisp the work still went forward in
C/C++. Most of my co-workers didn't want to learn a new language.

After trying to apply Scheme for a few years, with some successes I
found myself wondering why I was programming in other languages? Most
of the programs I was working on were dead and lifeless. What my
programs ware doing was hidden in so much verbiage that it took too long
to understand (let alone someone else's programs).

I thus decided that Lisp was the way to go and I went with Common Lisp.
I thought with what I had seen so far and the accumulated experience
that had gone into developing CL that it was the right language. I have
not been disappointed!!

Things that were so hard in other languages were easy in Lisp. The
whole development process is so smooth. I could start out programming a
problem in an ad hoc natural fashion and gradually fill in the details.
Traditional waterfall development techniques involve separation of
specification, analysis, design, coding, testing and delivery. With
Lisp I found I could specify, design, code, test all with one language.
No SDL, No high level design docs, no low-level design docs, no testing
docs. Just Lisp code, which when well written was very readable by
other people (even those who do not understand Lisp). This is where I
find that Lisp's main strength is, the idea of the list and its simple
syntax. Then using the language (like english) to write the problem and
its solution. Usually people rely on english to state the problem and
solution in english and then translate it into code. But it ends up
being ambiguous and error prone (not to mention an unnecessary step). A
programmer has to specify the problem and the solution precisely
eventually, so why not from the beginning of the process?

And then using the rich functionality of the language (which was
obviously well thought out when you use CL for awhile) you can get the
computer to automate the solution.

Would this problem->solution approach be a good teaching method? Leave
the discussions about recursion, iterations, conditionals, hash tables
till later. Focus on getting your ideas to work on the computer. I have
seen this in how my kids learn. It works best for them when they wish
to accomplish something and then they learn things they need on the way
to getting it done. They learn much more effectively when what they are
learning is pertinent. Focus on how Lisp does not get in the way but
can be an effective tool in accomplishing things. The teacher is there
to guide the way that has been travelled before. The student is there
to find the way.

Wade

Kent M Pitman

unread,
Oct 27, 2000, 12:22:39 PM10/27/00
to
glauber <thegl...@my-deja.com> writes:

> Incidentally, it seems that there's a lot more interest in developing free
> Scheme systems than Lisp. I guess it's to be expected, since Scheme is
> designed to be simple to implement.

[Reacting to the words I've quoted out of context here, without regard to
whether glauber meant them in the way they read.]

In what other industry is the presence of free implementations a mark of
success? Does the vacuum cleaner industry survive on the wealth of free
implementations for those who can't afford a commercial one?

When the number of implementations of Scheme is so plentiful, you'd hope
the number of USERS was proportionally even more plentiful, but I don't
see that as true. There is SOME serious work in Scheme, but most serious
users don't waste their time implementing scheme, they get right to the
business of using it and focusing on business, and for that they don't need
a plentiful array of free Schemes, they just need one or two committed to
their success.

I've frankly never understood why people think a multitude of free
implementations is a sign of health. It seems more to me a sign of
self-obsession.

Emacs has only a couple of free implementations and is perfectly healthy.
It would be an utter waste of everyone's time for there to be more, each
building incompatible libraries that do essentially the same sets of things,
rather than having just one or two that are moving forward on the shoulders
of others' contributions.

CL has more than enough free implementations, I think.

Moreover, it's an unspoken thesis of CL that simple to implement is not a
criterion. The idea is that everyone needs the same robust common core and
that it's not supposed to be simple to implement. That way, when you get it
you really have something. If implementing it takes only a day, then it
really hasn't saved you much programming. Java and CL agree on this point,
at least, even if Java has a better set of libraries for modern practical
work. And a paucity of free implementations of Java doesn't seem to be
hurting Java any...

Duane Rettig

unread,
Oct 27, 2000, 12:05:29 PM10/27/00
to
Kent M Pitman <pit...@world.std.com> writes:

> Like all things in life, good teaching should be monotonic, adding to what
> one already knows and providing additional options, not evangelical, replacing
> "bad thought" with so-called "good thought". Sometimes, the result of good
> teaching will be that the learner will decide they can get away with collapsing
> out two ways of thinking about something and using only one, but that should
> be a personal choice of the learner, not a choice of the teacher. The teacher
> should provide options.

While I agree with most of what what said in this article, I heartily
disagree with this paragraph. It is sometimes impossible to replace
"bad thought" with "good thought", because replacement involves removing
the old and adding the new. If the old "bad thought" is deeply ingrained
in the student's head by previous teaching, it is likely to be perceived
by the student to be "good thought", and thus there will be resistance
to the new "good thought". The teaching must indeed sometimes be
evangelical.

This is why I don't like the progression of one language to another
in lisp-like languages; when scheme or logo are taught in schools,
the tendency is to not realize that there is something more powerful
out there; either the student gets turned off to lisp and never looks
at CL, or else the student becomes enamored with the beauty of their
simple, elegant language (sort of a first-language syndrome) and takes
a very long time to learn CL and even then, it takes a lot of relearning
to delete some of the older habits of their (scheming) years. Note that
I don't say that either scheme or logo are bad languages; it is in fact
precisely because they are good within themselves for learning that
they become so insidious wrt the eventual learning of CL.

I _do_ agree that teaching can be monotonic iff there are no bad thoughts
to unlearn. To that end, we should be promoting the teaching of CL
in schools, as an alternative to scheme or logo. The vendors should of
course do their parts, and I think we do try. But the CL community must
also do its part:

I have seen outcries for many things that are or are not available in
the CL standard to be standardized (e.g. foreign interface, multiprocessing,
defsystem, etc), but I have never heard anyone crying out for a standard
teaching curriculum and/or interface in CL. Logo and scheme don't need
such a standard, because they already have mechanisms that are amenable
to learning. Scheme is purportedly simple and thus the learning of the
core of scheme is within the scope of a class or two in college. Logo
has turtles, and its defining forms and turtle commands are mnemonic.
But CL is larger than can be fit into one ot two introductory courses in
college, and even harder to teach in pre-college schools.

It would be nice to have a "recommended course of study" for CL, as part
of the standard. This would give teachers something to present to
students that would not blow them away and turn them off. It would
also allow teachers to start with CL directly, rather than starting
with something "simpler" but "different".

To standardize this, a meeting of minds of those teachers of CL who
have been successful in CL could take place, and the outlines drawn
up as to how to teach CL _and_ how not to teach CL.

[Personal note: I am sorry to say that I won't be able to continue this
conversation after today; though I am not sorry for the reason: I am
leaving early tomorrow for a cruise with my wife for two weeks; so if
I don't respond to any particular articles for a while, it's only
because I haven't read them...]

--
Duane Rettig Franz Inc. http://www.franz.com/ (www)
1995 University Ave Suite 275 Berkeley, CA 94704
Phone: (510) 548-3600; FAX: (510) 548-8253 du...@Franz.COM (internet)

vsync

unread,
Oct 27, 2000, 2:03:47 PM10/27/00
to
Rainer Joswig <jos...@corporate-world.lisp.de> writes:

> Usage of Lisp at Schools/Colleges/Universities is **crucial** for
> the success and survival of Lisp. This is the number one source for
> contacts with Lisp technology (another being the
> GNU/Linux/Free Software/Open Source movements).

Well, whenever I mention Lisp, I get the same response, almost
word-for-word. "Lisp?! I had to learn that in college. Why would
you use that? It's slow and interpreted..." They might also toss in
that [Language X] is better because it is "object oriented".

--
vsync
http://quadium.net/ - last updated Sat Oct 7 18:53:10 PDT 2000
(cons (cons (car (cons 'c 'r)) (cdr (cons 'a 'o))) ; Orjner
(cons (cons (car (cons 'n 'c)) (cdr (cons nil 's))) nil))

Arne Knut Roev

unread,
Oct 27, 2000, 1:52:30 PM10/27/00
to
Duane Rettig <du...@franz.com> wrote:
> [Personal note: I am sorry to say that I won't be able to continue this
> conversation after today; though I am not sorry for the reason: I am
> leaving early tomorrow for a cruise with my wife for two weeks; so if
> I don't respond to any particular articles for a while, it's only
> because I haven't read them...]

Bon Voyage!

(and welcome back...)

--
Arne Knut Roev <akr...@online.no> Snail: N-6141 ROVDE, Norway
=
The Gates of Hell shall not prevail:
Darkness now; then Light!

Duane Rettig

unread,
Oct 27, 2000, 2:42:51 PM10/27/00
to
vsync <vs...@quadium.net> writes:

> Rainer Joswig <jos...@corporate-world.lisp.de> writes:
>
> > Usage of Lisp at Schools/Colleges/Universities is **crucial** for
> > the success and survival of Lisp. This is the number one source for
> > contacts with Lisp technology (another being the
> > GNU/Linux/Free Software/Open Source movements).
>
> Well, whenever I mention Lisp, I get the same response, almost
> word-for-word. "Lisp?! I had to learn that in college. Why would
> you use that? It's slow and interpreted..." They might also toss in
> that [Language X] is better because it is "object oriented".

There's a high probability that if you do some correlations, you
would find by coincidence that those who responded in that manner
are likely to have gone to a college which doesn't teach Lisp as
a programming language, but instead as an oddity - "Lisp is good with
recursions, so let's teach recursion in Lisp." - "Lisp is interactive,
so let's show this odd behavior in Lisp, and nevermind bothering with
the built-in compiler." It's this kind of teaching that breeds into
students the attitude that Lisp is not a language for real work, but
just an odd language for doing odd things inefficiently. (and yes,
Lisp is powerful enough that you can even do things as inefficiently
as you wish :-)

What is needed is for teachers to provide a vision for what Lisp
really is, and what it is good for, not just the ways in which it
is different than other languages.

Mike McDonald

unread,
Oct 27, 2000, 4:55:22 PM10/27/00
to
In article <joswig-1D9C9B....@news.is-europe.net>,
Rainer Joswig <jos...@corporate-world.lisp.de> writes:

> How could one make CL even more successful in Universities?

You forgot the most important one: BAN "Intro to AI"!

Mike McDonald
mik...@mikemac.com

Rainer Joswig

unread,
Oct 27, 2000, 5:12:03 PM10/27/00
to
In article <_YlK5.7378$Qz2.1...@typhoon.aracnet.com>,
mik...@mikemac.com wrote:

Why? Because they use Java for that nowadays?

glauber

unread,
Oct 27, 2000, 5:33:40 PM10/27/00
to
In article <31816491...@naggum.net>,

Erik Naggum <er...@naggum.net> wrote:
> * glauber <thegl...@my-deja.com>
> | OK, i'll ask. Which one?
>
> Please. I would have been a little happier if you had asked about
> the million implementations and had recognized "only one of them" as
> the obvious hyperbole.

I thought of that, but i was afraid you'd attach the full list.

glauber

unread,
Oct 27, 2000, 5:57:34 PM10/27/00
to
In article <sfwog06...@world.std.com>,


It's not a sign of success, but it's one sign of interest and vitality.
Scheme is a young language, while Lisp is mature. Common Lisp has found
its niches and lives there, but unless it finds a way to interest new
programmers, it may not live longer than the current generation of
programmers and the applications they wrote. So, part of the reason why
there are so many Schemes out there is probably the enthusiasm
generated by novelty. In the days when C was young there were also a
bunch of free and cheap compilers available (that's how i learned C).

One way to interest new programmers is to make a good free
implementation available. Good examples are Perl, Python, TCL and Java!

The only 2 usable free implementations of Common Lisp i know of are
CLISP and CMUCL. CLISP is the only one that you can actually take and
compile yourself.

In contrast, look at Kawa, for example, which does seamless integration
of Scheme and Java. Think of the hype potential, or think that if you
are "forced" to program in Java, you can still use Kawa and do your
coding in Scheme. Think of the possibilities, you have the clean syntax
from Scheme and the powerful pre-written libraries from Java. Wow, now
i almost convinced myself to go learn Scheme.


Anyway, i'm not disagreeing with you and this is not meant to say that
C.L. is "better" or "worse" than Scheme, Perl, Python, Java or C.

Erik Naggum

unread,
Oct 27, 2000, 1:39:58 PM10/27/00
to
* Wade Humeniuk <hume...@cadvision.com>

| Would this problem->solution approach be a good teaching method?
| Leave the discussions about recursion, iterations, conditionals,
| hash tables till later. Focus on getting your ideas to work on the
| computer. I have seen this in how my kids learn. It works best for
| them when they wish to accomplish something and then they learn
| things they need on the way to getting it done. They learn much
| more effectively when what they are learning is pertinent. Focus on
| how Lisp does not get in the way but can be an effective tool in
| accomplishing things. The teacher is there to guide the way that
| has been travelled before. The student is there to find the way.

This sounds very much like the Problem-Oriented Learning methodology
now popular in many medical schools. Due to the enormous mass of
knowledge to learn and sheer amounts of information to memorize
(more or less), many ways to motivate students have been tried.
Bringing attention to problems that a (good) teacher can pose in
such a way as to fit the students' expected level of understanding
and skills, means that there is a feeling of mastering problems all
the time. It is reported harder work than the older styles with
lectures and mainly reading several thousand pages of literature,
but that seems to be because students actually do the work, as
opposed to skipping the incredibl boring parts.

I keep thinking the level of attention to detail and the necessity
to learn a tremendous amount of "stuff" for modern programmers is
closer to very established professions like medicine and law than
some of the undereducated punks would dream of in a nightmare. Most
of the CS education I have come across, both my own and what I have
read about elsewhere, has been in uninspiring theory and too little
actually rewarding work, especially as the theories get more and
more advanced and the poor student has _no_ idea whence they all
came, simply because of lack of programming experience. No wonder
today's dot-com coders think they need no education. *Sigh*

Kent M Pitman

unread,
Oct 27, 2000, 6:31:32 PM10/27/00
to
Duane Rettig <du...@franz.com> writes:

> Kent M Pitman <pit...@world.std.com> writes:
>

> > ... good teaching should be monotonic ...


>
> While I agree with most of what what said in this article, I heartily
> disagree with this paragraph. It is sometimes impossible to replace
> "bad thought" with "good thought",

I actually have a personal computational model of the brain that says that
says that you don't ever end up getting to do this. That in fact what
learning does is only to cons a new block of something, and that the
only way something "goes away" is by gc, not by explicit dropping of
pointer. All the attempts at forced dropping pointers more likely just
create convoluted, unmotivated paths around something, losing the "good"
in what was there because the area has been marked "off limits" and may
in some cases create gc-protection for ideas that ought have been naturally
gc'd if left alone. Just a theory. But that's where the term monotonic
came from here.

> because replacement involves removing the old and adding the new.
> If the old "bad thought" is deeply ingrained in the student's head
> by previous teaching, it is likely to be perceived by the student to
> be "good thought", and thus there will be resistance to the new
> "good thought". The teaching must indeed sometimes be evangelical.

I'm not so sure. The reason is that the teacher cannot know the whole of
what is to be replaced. The teacher can only know the shape of some patterns
to be looked for, but not the entirety of the patterns in context. Indeed,
even if the second teacher was there for the first teaching, the second
teacher cannot know, since the teacher knows only what was projected, not
how it was received and incorporated. If person A says to me
"people with green noses are untrustworthy", I might not learn that as such;
I might learn it as "on-such-and-so date, people with green noses were
thought to be untrustworthy" or "there are people who distrust people with
green noses" or any of a variety of other things that you didn't say, perhaps
in order to keep the teaching consistent with some theory I already have
that green noses are irrelevant to trustworthiness. Now if teacher 2 comes
along and says "anything anyone has taught you about green noses is false"
then am I to believe or disbleive? Personally, I'd find that to be just as
bad data as the first thing, since the second teacher is saying something
that on the meta appears absurd. What I have been taught is as much a product
of me as of the first teacher, so when someone tells me that things that are
the product of me are false, I learn to discount them, too. Or else I don't,
and that is worse. Because now I believe it's false that "at a certain date,
people with green noses were untrustworthy" or it's false that "some people
distrust green noses" or ... Hence, I think an evangelical approach--one
that I'll define as being "negative assertions about something one imagines
has been taught before" is bad.

Rather, I think monotonicity is achieved by merely teaching someone something
new and teaching them how to recognize the set of processes and facts that
this, by its nature and not by some assertion of truth, aubsumes. Then they,
not me the teacher, can develop their own patterns for finding and updating
prior pointers to facts, and more importantly can update related concepts to
bypass the old wisdom. Hence, rather than a network that looks like:

xref1 xref2
\ /
explaind-by explained-by
\ /
\ /
fact1 <---- supersedes --- fact2

you end up with a network like:

xref1
/ \
explained explained
by by
| |
v v
fact1 fact2
A A
| |
explained explained
by by
\ /
xref2

If the fact2 gets independent confirmation of being a stronger item,
eventually fact1 will just not be able to compete of its own accord
but in the meantime, the original structure of the two theories will not
be perturbed, can be compared, etc. This is what I mean by monotonic, in
any case. In a sense, both involve the incremental addition of links, but
only the second is culturally consistent with monotonicity in the sense that
the resulting graph actively represents (and doesn't just imply) the
thing learned. Part of my problem with evangelical thought is that I think
it ends up with lots of fuzzy-logic "supersedes" links randomly attached
to things without regard to what the logical implication is of perturbing a
random isolated factoid in a large complex network, and I think this does
damage to people's understanding of the world.

> This is why I don't like the progression of one language to another
> in lisp-like languages; when scheme or logo are taught in schools,
> the tendency is to not realize that there is something more powerful
> out there; either the student gets turned off to lisp and never looks
> at CL, or else the student becomes enamored with the beauty of their
> simple, elegant language (sort of a first-language syndrome) and takes
> a very long time to learn CL and even then, it takes a lot of relearning
> to delete some of the older habits of their (scheming) years.

I see this as less a problem of progression of languages and more a
problem of belief that all languages use the same skills. I was
taught early on that in order to understand "Programming" one must
understand it from many different points of view and then select from
what works in a given case. I was given a list of kinds of languages
(which I think I've since augmented) and told to learn one of each, so
that I could see how patterns of thought vary among them. Learn a
straight-line language (e.g., assembly or fortran), a functional
language (e.g., scheme), a block-structured language (like Algol, Pascal,
C++, or Java), a line-noise language (one with small amounts
of text and heavyweight operators, like teco or apl), an AI language
(like amord or emycin or prolog), a domain-specialized language (like
visual basic or hypertalk or tex or postscript, somewhat coincidental
that most of the domains are "display domains" here in the examples,
but i mean languages where the operators are heavy on support of some
specific domain; i suppose CAD could be another), a text processing
language (like snobol or teco or perl), a markup language (like scribe
or html), an object-oriented language (like lisp or smalltalk, not the
latter day pretenders like C++ or Java which are overly static), a
bit-twiddly language (like C or assembly), and so on. From these,
collect a quiver of all the tools of thought you might want to apply
to a problem, and then regardless of which language you choose to
implement your solution, at least conceptualize the problem like you
were going to use a language appropriate to the task you had at hand.
Moving from language to language isn't a process of unlearning, it's a
process of allowing yourself not to be burdened by the constraints of
the previous--only to be enabled by the power of the previous when that
serves your need, and to understand the whole point of moving to the new
language was to be enabled by new virtues.

> Note that
> I don't say that either scheme or logo are bad languages; it is in fact
> precisely because they are good within themselves for learning that
> they become so insidious wrt the eventual learning of CL.

I think more because they implicitly preach an evangelical "this is right,
others are wrong" as part of their curriculum and because it's that mantra,
not the technical aspects, which you have to overcome. If they instead
taught "this is one way of thinking and other languages will teach you
other valued ways of thinking" you'd not have the problem switching.
Because they choose to be evangelical, you often find yourself fighting
fire with fire because there are random little meta tags in people's brains
saying "good"/"bad" that have to be combatted where they should not have to.
But that doesn't mean that's a good way to start.

In 6.035 (the MIT course on compiler design at the time I went to school
as an undergrad there), our mid-term had a question "gotos are (a) good
(b) bad". This is what I mean by evangelism, and it has no place in
teaching. Things are only good or bad in a context, and people should be
teaching contexts, not universal truths.

> I _do_ agree that teaching can be monotonic iff there are no bad thoughts
> to unlearn.

I'm torn on this. This is perhaps the eternal conundrum of how to design
teaching, only here we are talking about how to teach teaching. Do you build
in the pragmatics or do you teach ideals? Do I say "nuclear arms are bad"
or do I say "nuclear arms are necessary if someone else develops them first".
Do I say "evangelism is bad" or do I say "some amount of corrective evangelism
is needed to correct prior evangelical effects". I think the important point
is to focus on not abusing a superior position. Evangelism seems to me to have
as its goal achieving the ideological upper hand; I'm advocating merely
achieving a posture of "live and let live" as far as ideologies go. If the
student isn't capable of getting to the point of evaluating competing theories
for himself/herself, then lisp vs scheme is the least of their problems.
They at that point need a course in how to think, evaluate, judge competing
theories, whehter about programming or about politics or science or whatever.
What causes people to reject "creation science" and either accept (or at least
tentiavely tolerate, pending something better) "darwinism" had better be more
than someone having the upper hand in debate. It should be that one system
favors itself over the other in the face of side-by-side scientific scrutiny
by the learner, not just in emphasis by the teacher.

> To that end, we should be promoting the teaching of CL
> in schools, as an alternative to scheme or logo.

I don't have any moral opposition to Scheme or Logo being taught with Lisp.
I think the argument you want to make here is a shelf space argument.
Syntactically, the school is going to tolerate only so much programming, and
of that an even smaller amount of programming in a language that isn't in
every job offer everywhere. We want CL in that set. Whether anything else
is there depends on whether it fits. But I'd rather have Scheme or Logo
there than Pascal, given that Java will almost certainly teach someone
whatever they need.

[Phew. Now after all that we come to the part of your message that I actually
had meant to reply to. I'll try to be more brief as I plow ahead:]

> The vendors should of
> course do their parts, and I think we do try. But the CL community must
> also do its part:
>
> I have seen outcries for many things that are or are not available in
> the CL standard to be standardized (e.g. foreign interface, multiprocessing,
> defsystem, etc), but I have never heard anyone crying out for a standard
> teaching curriculum and/or interface in CL.

The notion of a "teaching subset" came up in the discussion of what
X3J13 should do. I can't remember if it was during the charter
discussion (because it didn't end up in the charter) or afterward. It
was finally pointed out by one of the teachers among us that no singularly
determined useful subset for teaching was possible, since each teacher would
have their own interests and focus and none agreed. He managed to convince
us of this. We also talked about things that would likely get subsetted
and convinced us that the things one would leave out for teaching were not
things that would make implementations materially smaller, so we decided
not to proceed toward a subset for the purpose of guiding implementors.

We didn't talk about a standardized teaching curriculum, but the
issues seem materially similar. If someone comes up with any
curriculum that works, why does it need to be standard? If there are
two that work, why vote on which is best? The market can sort this
out.

> It would be nice to have a "recommended course of study" for CL, as part
> of the standard.

Standards are too inflexible, too hard to add new ideas, fix bugs,
pursue new thoughts to keep focused on the market.

I suggest this is something the ALU could usefully do. An ALU-endorsed
curriculum or even a set of principles that, if a curriculum conformed to,
would allow endorsement...

Kent M Pitman

unread,
Oct 27, 2000, 7:05:36 PM10/27/00
to
glauber <thegl...@my-deja.com> writes:

> The only 2 usable free implementations of Common Lisp i know of are
> CLISP and CMUCL. CLISP is the only one that you can actually take and
> compile yourself.

Depends on whether you use that weird patented meaning of "free" that people
have forced onto many of us who don't like it. In the ordinary meaning of
free ("gratis"), you'll find excellent implementations from Harlequin/Xanalys
and from Franz. Also, Cormon Common Lisp, last I checked, had a very low
cost or free implementation. And certainly GNU CL (formerly KCL) is free
even in the bizarro sense. See the ALU web page to see if this is complete;
it might still not be. The ALU web page is a better source of authority.

Mike McDonald

unread,
Oct 27, 2000, 7:14:06 PM10/27/00
to
In article <joswig-23966F....@news.is-europe.net>,

Rainer Joswig <jos...@corporate-world.lisp.de> writes:
> In article <_YlK5.7378$Qz2.1...@typhoon.aracnet.com>,
> mik...@mikemac.com wrote:
>
>> In article <joswig-1D9C9B....@news.is-europe.net>,
>> Rainer Joswig <jos...@corporate-world.lisp.de> writes:
>>
>> > How could one make CL even more successful in Universities?
>>
>> You forgot the most important one: BAN "Intro to AI"!
>>
>> Mike McDonald
>> mik...@mikemac.com
>
> Why? Because they use Java for that nowadays?
>

No, because it does the most harm to both CS students and Lisp, IMNSOHO. For
a lot of CS students, this is their only exposure to Lisp. The problems solved
in "Intro to AI" classes are so rinky dink as to turn the students off to both
AI and Lisp. If the class progresses really quickly, they might get to write a
Lisp program that plays tic-tac-toe by the end of the semester. In my
experience, they come away thinking Lisp is only good for wierd toy problems
and that AI is a joke.

Mike McDonald
mik...@mikemac.com

Rainer Joswig

unread,
Oct 27, 2000, 8:20:01 PM10/27/00
to
In article <8tctob$d4h$1...@nnrp1.deja.com>, glauber
<thegl...@my-deja.com> wrote:

> One way to interest new programmers is to make a good free
> implementation available. Good examples are Perl, Python, TCL and Java!

How many usable and used "free" implementations do they have?

They might not even have one commercial implementation.

Actually I think an Lisp system like Macintosh Common Lisp
LispWorks, Genera, you name it, is so productive, that
I don't mind to pay for it a reasonable price. If you
are working professionally this is well worth
the money. Especially if the support is right - which
usually is quite good with Lisp companies.

> The only 2 usable free implementations of Common Lisp i know of are
> CLISP and CMUCL. CLISP is the only one that you can actually take and
> compile yourself.

Common Lisp is a bit more complicated than Scheme. Especially
if you want a real implementation with facilities like
generational incremental GC, FFI, threads, callable from
the OS, native code compiler, OS interfce, GUI toolkit, IDE,
networking, application delivery, tree shaker, etc.

I really urge everyone to think twice whether he/she wants to
spend a few years of their life to write a new Lisp
implementation. Sure new Lisp implementations can be
worthwile and Lisp technology has not reached nirvana -
just make sure you have the resources to really do
something new. There is are many areas where existing
implementations can be improved. Both CLisp and CMUCL
are very interesting and useful implementations -
study those and help the maintainers. It is hard
enough to move CMUCL forward (port it to other
platforms, improve the CLOS implementation,
robust modern incremental GC, robust threading, ...).
It's for example not enough to just introduce
threads and then thinking that's it. Is the Lisp
thread-safe? Is CLOS thread-safe?

The real challenge is to focus on application development.
What are cool Lisp systems worth, if you can't demonstrate
their ability to write equally cool applications.
Finally you have to deal with users (Lisp devevelopers
writing applications) and then you have enough to do,
to make the Lisp implementation really robust, reliable
and equipped with the right feature set. This is
the reason why Lisp has commercial vendors. There
are customers who have mission critical applications
and they need a certain level of quality.

It can't be said often enough: working on the existing
free implementations is a good thing for everyone
interested in "free" software. Writing Lisp applications
and libraries is another area. Finally http://www.lisp.org/
is only good and up to date, when volunteers are maintaining
the site.

Rainer Joswig

unread,
Oct 27, 2000, 8:22:50 PM10/27/00
to
In article <2%nK5.7389$Qz2.1...@typhoon.aracnet.com>,
mik...@mikemac.com wrote:

> In article <joswig-23966F....@news.is-europe.net>,
> Rainer Joswig <jos...@corporate-world.lisp.de> writes:
> > In article <_YlK5.7378$Qz2.1...@typhoon.aracnet.com>,
> > mik...@mikemac.com wrote:
> >
> >> In article <joswig-1D9C9B....@news.is-europe.net>,
> >> Rainer Joswig <jos...@corporate-world.lisp.de> writes:
> >>
> >> > How could one make CL even more successful in Universities?
> >>
> >> You forgot the most important one: BAN "Intro to AI"!
> >>
> >> Mike McDonald
> >> mik...@mikemac.com
> >
> > Why? Because they use Java for that nowadays?
> >
>
> No, because it does the most harm to both CS students and Lisp, IMNSOHO. For
> a lot of CS students, this is their only exposure to Lisp. The problems solved
> in "Intro to AI" classes are so rinky dink as to turn the students off to both
> AI and Lisp. If the class progresses really quickly, they might get to write a
> Lisp program that plays tic-tac-toe by the end of the semester. In my
> experience, they come away thinking Lisp is only good for wierd toy problems
> and that AI is a joke.

So let them use Java. ;-)

jos...@corporate-world.lisp.de

unread,
Oct 27, 2000, 8:48:22 PM10/27/00
to
In article <31816308...@naggum.net>,

Erik Naggum <er...@naggum.net> wrote:
> * Rainer Joswig <jos...@corporate-world.lisp.de>
> | How could one make CL even more successful in Universities?
>
> Many excellent points omitted, but I suspect one point was omitted
> by accident:

Well, somehow. ;-)

> - secure funding for all of the above.

Quite a lot of Universities have site licenses for
commercial Lisp systems and those Lisp systems are
installed on the main computing clusters for general
usage. I guess Lisp companies want to see renewal
of the maintenance contracts? They might even
want to sell new major versions of their Lisp
systems? They might also want to sell support and licenses
to University-near research labs, spin-offs, start-ups?
How does a University justify spending money on Lisp?
Lisp has to be good for introductory courses (Computer Science,
AI, Music, Psychology, ...), for research projects, ...
What does the customer need to make successful usage out
of the Lisp system? As a Lisp vendor I might even make
sure the Lisp system's setup is done right on the computer
cluster and give them a package including out-of-the-box
documentation/tutorials that easily integrates into the
University's intranet.

Tim Bradshaw

unread,
Oct 27, 2000, 8:40:43 PM10/27/00
to
* glauber wrote:

> The only 2 usable free implementations of Common Lisp i know of are
> CLISP and CMUCL. CLISP is the only one that you can actually take and
> compile yourself.

However there is only *one* free implementation of perl. It seems to
be sufficient.

--tim

C Matthew Curtin

unread,
Oct 28, 2000, 7:44:18 AM10/28/00
to
>>>>> "Rainer" == Rainer Joswig <jos...@corporate-world.lisp.de> writes:

Rainer> I think students take Common Lisp because they have to.

This is interesting. I wonder what a survey would show.

At my university (Ohio State), C++ is part of the requirement, and
Common Lisp is an option. Many students get through the entire
undergraduate program without ever writing a Common Lisp program.
"Programming in Common Lisp" is listed as 459.31 and a 459.xx is
required for graduation. Many people opt for the C, C++, or Java
versions of 459; some, primarily business students, opt for Cobol.
The 459s are focused on the languages themselves, not some other
problem domain where the language needs to be used for the
assignments.

Our 459.31 isn't highly popular. The first time I taught it two years
ago, by the second or third week of the term, roughly half of the
class was empty. Meanwhile, there were multiple sections of other
459s, with huge wait lists. The C, C++, and Java courses are taught
every quarter, while the Lisp course is taught only once per year.

The good news is that a fairly significant number of those who did
stick with it turned out really to like it and to want to continue
using it. That introduced another problem, in that there aren't other
courses where one can really use a lot of Lisp. The current
recommendation is that I point interested students in the direction of
the AI courses. In some sense, that contradicts most of what I had
been talking about all quarter: that Common Lisp really is a general
purpose language.

Last year, the enrollment in 459.31 was up, a significant number of
the students being there because their friends who had taken the
course the previous year recommended it. This time, even more
students -- both absolutely and relatively -- asked me about
continuing in the use of Lisp.

This year, I'm hoping that we'll fill the class completely. Students
are now talking about Lisp with each other and are using it on their
own. We have an open source club, a student group, with lots of
budding Lisp programmers. In fact, a series of three talks on Lisp is
being given this quarter to any students who will attend. The club is
buying pizza and soda for all comers, which is usually a pretty good
way to attract a significant following. I should add that this is all
the idea of the students in the club. Although I agreed to give the
third talk in the series, I didn't have any idea what was happening
until after the master plan was put together, with the speakers lined
up.

My company, Interhack, is also sponsoring a Lisp programming contest.
More correctly stated, it's a contest to create a version of decss.c
that will be understood by CMU CL but also convey something to the
human reader. In any case, we're offering $250, $100, and $50 cash
prizes, which also seems to be a good way to stir up some more
interest.

And of course, word being out that we're looking for clueful student
Lisp programmers doesn't seem to hurt. :-)

I'm guessing that Rainer's statement about students taking Lisp
because they're required is largely true, perhaps even generally true.
However, there are places -- at least one, but I would also guess
there are others -- where the opposite is true. They're taking C++
because they must and using Lisp when they want to do something
productive or fun.

I think getting a survey that shows what the different camps are at
universities and in what proportions they're to be found. (Actually
taking the survey would probably be difficult, though, because at
least in our case, if you ask the people you'd think that it would
make sense to ask, you'll get a view of the world that agrees with the
curriculum more than what largish-and-growing groups of students are
doing in their free time...)

--
Matt Curtin, Founder Interhack Corporation http://www.interhack.net/
"Building the Internet, Securely." research | development | consulting

Tim Bradshaw

unread,
Oct 28, 2000, 8:53:35 AM10/28/00
to
* Rainer Joswig wrote:

> I really urge everyone to think twice whether he/she wants to
> spend a few years of their life to write a new Lisp
> implementation. Sure new Lisp implementations can be
> worthwile and Lisp technology has not reached nirvana -
> just make sure you have the resources to really do
> something new. There is are many areas where existing
> implementations can be improved. Both CLisp and CMUCL
> are very interesting and useful implementations -
> study those and help the maintainers. It is hard
> enough to move CMUCL forward (port it to other
> platforms, improve the CLOS implementation,
> robust modern incremental GC, robust threading, ...).
> It's for example not enough to just introduce
> threads and then thinking that's it. Is the Lisp
> thread-safe? Is CLOS thread-safe?

I can't agree with this too much. As I said in another post in this
thread, perl does just fine with precisely *one* implementation. while
there are certainly several free C/C++ implementations, one (gcc) is
enormously dominant: I've never used another as far as I can recall.

There is just no correlation between multiplicity of (free)
implementations of a language and success of that language. In fact
if there is a correlation it's probably the reverse of what you might
expect: the more implementations the less successful!

I can't help suspecting that the people who feel that they need to
write a new implementation of a language before they can do anything
useful are actually trying to avoid the awful truth that they don't
have anything useful they want to do. Certainly reimplementing CL is
a good way of ensuring that you have plenty of stuff to do for a good
long while before you get anything useful done.

If people want to contribute to free (in whatever sense we have to use
that word this week) Lisp systems I think it would be much better for
them to spend their time improving one of the existing systems. There
are obvious huge lacunae in most of them. Taking CMUCL as an example:

* CLOS. The current PCL-based implementation has sufficiently low
performance that it discourages CLOS-based programming. An
integrated `native' CLOS is needed.

* Better GC.

* 64bitness (maybe very hard).

* Multithreading (already (partly) done on x86).

* Native multithreading so it can use multiprocessors (undoubtedly
involves GC, and is very hard).

The combination of the last four of these is pretty interesting I
think, and is perhaps the kind of thing that some research-type
institution could get funding to undertake: there must be PhDs in it!

Not only that, but it's a commercially interesting proposition. The
big Unix vendors are making really a lot of money out of large 64bit
shared-memory (or effectively shared-memory in the case of SGI's
ccNUMA machines and probably Sun's E10k followup which is also meant
to be a ccNUMA machine). Lisp is *good* at large systems with complex
sharing of large data objects: it should be a really good match for
these machines. And applications on these machines sell for *really*
high unit costs -- millions of pounds -- so a language implementation
which could make writing such applications less painful than it is in
C (it will always be painful) could really win. But the commercial
lisp vendors are too timid, poor or (perhaps) stupid to take advantage
of this opportunity: even though I think there are 64bit
implementations arriving, there doesn't seem to be any sign of
something that can do native multithreading.

I'm working for a client right now which is likely to move away from
Lisp because they're going to hit the 32bit limit in a year (perhaps
less), and because they can't use the processors they can buy without
essentially converting the machines into a very expensive COW (Cluster
Of Workstations). It's really a tragedy because the advice I must
give them is that they are *right* so to do, even though the
reimplementation effort may be appalling, they just have no
choice. Bizarrely enough, the Boehm GC[1] for C now has parallel
variants (I don't know how scalable they are), so it may be that
*C*[2] will be the first language which offers a garbage-collected,
64bit, native-multithreaded implementation for these large machines.
That's a tragedy as this is high ground that Lisp could gain, if only
Lisp people had the vision to take it instead of trying to beat a
massively established system like Java, or sell Lisp as a language for
the web or whatever it is they think it would be cool to do four
years too late this week.

Well, Enough ranting, I'm sure I'm wrong.

--tim


Footnotes:
[1] http://www.hpl.hp.com/personal/Hans_Boehm/gc/

[2] Interestingly Java is not a candidate as far as I can see: it's
(I think) specified mostly as a 32bit system, and Sun's
`enterprise java' or whatever they call it with it's vastly
improved GC is actually just offering a generational collector
which doesn't look pll to me so will rapidly throttle the system
on multiprocessors.

Tim Bradshaw

unread,
Oct 28, 2000, 10:25:44 AM10/28/00