Common Lisp from a Unix perspective - barriers to using CL

57 views
Skip to first unread message

Ian Jackson

unread,
Dec 4, 2006, 8:08:23 PM12/4/06
to
As an experienced programmer, I've heard a lot about how good Lisp is,
and I like getting to grips with new languages. After conversations
with friend who's keen I decided I should learn Common Lisp.

I thought I'd share some of my experiences here. While much of what
I'm going to say is critical, I'd like to emphasize that I'm not
giving up on Lisp. I like what I've seen so far, and the hurdles are
more entrance barriers than they are problems for serious work - but
they are quite time-consuming, and nowadays we are all in a hurry.

So without futher ado, let me summarise my key point:

* Documentation for introducing Lisp to existing programmers is poor;
existing tutorials are old or at least outdated.

A comprehensive resource aimed at contemporary non-Lisp programmers
is urgently needed. I was going to started an article on the CLiki
with some pointers and discussion, but as I've written this article
I've realised that the answers I have found are not really usefully
transferrable to other people new to Lisp unless they have
circumstances very like my own.

Secondarily:

* Infrastructure for performing tasks which are routine in
modern programming is often lacking and/or hard to find.

* Support for Common Lisp development in Debian stable is
surprisingly poor, given how mature the Lisp world is.


Below I'll try to justify these assertions, but first here's a list of
questions that current `Lisp tutorials' fail to address. I think that
the world needs someone who knows more about this than I do to write a
single opinionated introduction that answers at least these questions:

Q. If I am using a modern Unix system, which Common Lisp
implementation should I choose ? Do I need to be using a
particular operating system to get a good CL development
environment ? What if I prefer a different OS (or have
a different version) ?
Q. Which development tools should I be using ? Summary of the
key features of SLIME. What if I'm a vi (vim) user ?
Q. Quick introduction to installing the relevant development tools
and libraries (eg, list of Debian packages to install). If this
turns into a list of instructions of the form `compile this',
`edit the system definition' etc., then the answer is wrong.
Q. Which tutorial on the Common Lisp language itself, and which
reference, should I be using ? Answer: one tutorial book or
webpage (I don't know what would be good to recommend) and one
reference (the Hyperspec, obviously). Provide only one answer to
each, not any lists; the web is full of lists of Lisp
information.
Q. Which libraries should I definitely be looking at using, and what
are they generally good for ?
Q. How do I turn my program into an executable ? NB that most Lisp
FAQs seem to answer this question with either a blank space (!)
or with some waffle. The answer seems to be: "Sorry, this is not
properly supported by anything yet; you must write a wrapper
script. Here is an example."
Q. How do I package my program in such a way that non-Lisp people
will not be freaked out by the installation instructions ?

I stress that *I don't need the answers to these questions any more*
because I have struggled through without (and will be able to solve
the remaining problems myself if need be, I'm sure).


I promised some justification for my assertions. This is probably
best done in a narrative style, which will demonstrate the
difficulties I faced and how I overcame them. This will naturally
make the result rather disjointed in terms of the relationship to my
suggestions above.


When I first settled on learning CL I thought I would read a standard
reference work. This is my usual way of approaching new programming
languages - I'm one of the minority of people who find they get on very
well with reference manuals, and find tutorials distressingly vague
about details.

A Lisp-using friend lent me their copy of CLtL2, and I started reading
through that. I quickly gave up because of Guy Steele's absurd habit
of writing `and the thingum does the wossname to the doobry - no wait,
it doesn't, in 1987 X3J13 voted that in fact the thingum does
something completely different'. This is all very well once or twice
but constantly reading, understanding and internalising complex
descriptions, only to be told in the next paragraph that it's all
false and I had to forget it all again, was too much like hard work.
(There are some typographical indications but they are too weak to
interrupt the flow of concentrated reading and in any case the text
only does original-version-and-diff rather than an integrated
description.)

My next approach was to try to read the Hyperspec through. Well, I'm
still doing that - but the Hyperspec is poorly structured for this.
The number of forward references is much higher than for most other
language specifications. It's possible that a different reading order
for the Hyperspec would improve this but I suppose since most people
prefer to learn languages from tutorials I'm probably out of luck.

It was evident that attempting to find a spec to just read wasn't
going to be very fruitful. Since I've used Lisp variants before on
occasion, I decided it would be better to pick some project and
just write a program.


Quickly, I encountered a suitable project: a non hideously broken
ip-over-http implementation. Given the way it has to fit into my
existing arrangements, this requires a single-process webserver
extensible to implement additional functionality. Ie, similar to CGI
programs, but my additional code has to run in the same process
because all the URL serving needs to share state, file descriptors,
etc. Some quick research showed that the standard approaches to
webservers in most scripting languages weren't ideal (Python might
have worked but I have lately got very annoyed with Python), and I
didn't want to have to patch one of the written-in-C webservers. My
searches led me to AllegroServe, of which a portable implementation is
available in Debian. A browse of the documentation in the cl-aserve
package suggested that it could do what I wanted so I decided to
write my application in Common Lisp.

So, now I wanted to actually write some programs in Lisp, a
precondition was getting as far as being able to run `hello world' and
test my basic understanding of use of the extension packages. I also
wanted a reasonable development environment, and my Lisp advocate
friend had mentioned the Emacs mode SLIME, so I knew I would want
that.

First I thought I'd try starting my favourite lisp and playing with
the REPL like many of the online tutorials suggest. This was all very
well but it all seemed very primitive. Several of the lisps I ended
up trying didn't have command line editing by default in Debian
stable. Absurd !

Also, there were evidently many useful CL packages in Debian, some of
which I wanted to use, but it seemed difficult to get documentation
for them. For example, I installed cl-md5, and I could say (require
'md5) and have it work, but what to do next ? I wrote a one-liner to
list the symbols in the package and then extracted their docstrings
but it was a total pain. Surely, I thought, people can't really go
about things this way in this day and age ? (I wouldn't even have
thought of this approach if I wasn't so familiar with Emacs's builtin
documentation system.)

There was also this nagging question: which lisp did I want to use ?
Debian stable comes with cmucl, sbcl, clisp and gcl. Etch (Debian
testing) has ecl too; non-free has an installer for some acl variant.
But this turned out to be less of a problem because bu then I knew
that I needed one which 1. worked with SLIME and 2. worked with
cl-aserve, and I wanted it on Debian stable.

So I decided I needed to try out SLIME. Note that SLIME isn't in
Debian stable. Being an experienced Debian developer made solving
this situation straightforward for me (if slightly tedious) but for
many people it would have been hard or even impossible. (I have no
idea what the situation is like on other Linux distributions, let
alone on non-GNU systems.)

I tried out various lisps at random, applying a shotgun debugging
approach; I compiled (and recompiled) packages to try to generate
appropriate backports. I ended up deciding that sbcl would be a good
answer (I can't remember why). One particularly silly situation was
that the sbcl in Debian stable was too old for unstable's slime and
the sbcl in Debian unstable had a build-dependency only satisfiable by
the sbcl in unstable ! I was able to solve this by bootstrapping with
an sbcl binary package from backports.org.

With this technique, and one source code change to deal with a renamed
symbol (I had to change disable-process to process-disable in a few
files in cl-portable-aserve-1.2.42+cvs.2006.04.24-dfsg-1), I was able
to procure working and compatible versions of sbcl, cl-aserve and
slime. This allowed me to start actually programming - obviously
beginning by playing about with the pieces I knew I would need and
making them work for me.

SLIME is a fantastically useful tool - although of course I don't know
how people who go without it solve the same problems. In particular,
tab completion over symbol names and easy docstring and arglist lookup
seem indispensible.

But I still find myself amazed at obvious things that appear to be
missing from the CL standard and the libraries I was using:

I had to write a function to convert a string of bytes (as produced by
cl-md5) to hex. Newer (non-broken!) hash functions and so on don't
seem to be available at all. I couldn't find a library for
manipulating IP address ranges and masks, and when I tried to write
the code myself I found that there wasn't even a standard function for
splitting a string into substrings based on a delimiter ! There is a
cornucopia of functionality available for meddling with the innards of
lisp, but hardly any of the pieces used for solving the kinds of
problems encountered in the modern Internet.

I presume that other people have already written much of the necessary
code, but it is really hard to know where to look. Debian is
well-supplied with CL packages and the infrastructure for loading them
is good, but it's obviously only of limited use when choosing which
one I should use.


Finally, one problem that I still haven't tackled: Lisp systems all
seem to have the idea that the way to run lisp programs is to invoke
the lisp interpreter and type some runes into the REPL; they also
think that this is the way to compile them too.

For someone who has been working with Unix, the inability to turn a
small lisp program into a proper executable, quickly and easily, is
like returning to the stone age (or to Windows, heaven help us).

It is all very well for large projects to involve learning a lot of
`system definition' facilities and to expect complicated and
hard-to-install infrastructure on the computers involved. But often
it is important to be able to ship small programs, in a form the
recipient will be able to execute; it is also important to be able to
make Lisp programs look and work like any other executable on the
system.

Naturally some of these problems can be addressed with wrapper scripts
and a few extra tools. That's fine. But where is the standard
facility for wrapper scripts, that I can put in a #! line ? Where are
the standard facilities for building *portably-deployable* CL
programs: by which I mean not `portable to a different Lisp' but
`a whole distribution bundle which is portable to a computer which
does not yet have a Lisp system' ? How do I integrate Lisp
compilation into the build system of a large project using many
languages and tools, all driven by something like make ?

Obviously I could write my own answers but I want to concentrate on
writing my application, not impedance matching to an approach to
programming that feels like a 1960's timewarp. Wouldn't it be nice if
Lisp were dragged kicking and screaming into the mid-1990's ?


Thanks for your attention. This has been a public service rant. I
hope that the community here will take it the right way. Don't get me
wrong; I like CL as a language and hope to increase my use of it.

I'm posting here to try to document some of the things that make it
difficult for even an experienced programmer to get involved with
Common Lisp. If the entrance barriers could be lowered, I think you
might find it easier to encourage new and useful people to join the
Lisp community.


--
Ian Jackson personal email: <ijac...@chiark.greenend.org.uk>
These opinions are my own. http://www.chiark.greenend.org.uk/~ijackson/
PGP2 key 1024R/0x23f5addb, fingerprint 5906F687 BD03ACAD 0D8E602E FCF37657

Pascal Bourguignon

unread,
Dec 4, 2006, 9:38:53 PM12/4/06
to
Ian Jackson <ijac...@chiark.greenend.org.uk> writes:

> As an experienced programmer, I've heard a lot about how good Lisp is,
> and I like getting to grips with new languages. After conversations
> with friend who's keen I decided I should learn Common Lisp.
>
> I thought I'd share some of my experiences here. While much of what
> I'm going to say is critical, I'd like to emphasize that I'm not
> giving up on Lisp. I like what I've seen so far, and the hurdles are
> more entrance barriers than they are problems for serious work - but
> they are quite time-consuming, and nowadays we are all in a hurry.
>
> So without futher ado, let me summarise my key point:
>
> * Documentation for introducing Lisp to existing programmers is poor;
> existing tutorials are old or at least outdated.

The "standard" answer is "Practical Common Lisp". It's available at
Amazon, or even online! http://www.gigamonkeys.com/

> A comprehensive resource aimed at contemporary non-Lisp programmers
> is urgently needed. I was going to started an article on the CLiki
> with some pointers and discussion, but as I've written this article
> I've realised that the answers I have found are not really usefully
> transferrable to other people new to Lisp unless they have
> circumstances very like my own.

On cliki, there are several pages dedicated to books, tutorials or
lisp "education"...


> Secondarily:
>
> * Infrastructure for performing tasks which are routine in
> modern programming is often lacking and/or hard to find.

Yes. If you have some time, you might want to build a Lisp
"distribution", like a linux distribution, where you'd prepackage
everything for the novice or lazy user. There's already the LispBox,
but perhaps it's not as maintained or as self contained as needed.


> * Support for Common Lisp development in Debian stable is
> surprisingly poor, given how mature the Lisp world is.

Well there's two aspects:

- It's difficult to package a lisp system at the level of a unix
system. One should really build a self contained lisp system (even
if it's stored as several files on a unix system).

- Actually, despite the stability of some parts of the lisp universe,
there is a lot of evolution, some packages or even some
implementation having a lot of releases, you might even want to use
CVS or darcs heads...


> Below I'll try to justify these assertions, but first here's a list of
> questions that current `Lisp tutorials' fail to address. I think that
> the world needs someone who knows more about this than I do to write a
> single opinionated introduction that answers at least these questions:
>
> Q. If I am using a modern Unix system, which Common Lisp
> implementation should I choose ?

The oneS that best match your needs.
I use clisp (79%), sbcl (19%), cmucl, ecl, gcl, acl (2%).


> Do I need to be using a
> particular operating system to get a good CL development
> environment ?

Not really. clisp works everywhere gcc works. Otherwise, things go
easier on a x86 linux, because that's what most developers work with,
but there are also good implementations usable on other systems or
processors.

> What if I prefer a different OS (or have
> a different version) ?

So you couldn't find with google the implementation for your OS?
What OS do you use on what processor?

Just SBCL lists a matrix with 10 OS on 8 processors...
http://sbcl.sourceforge.net/platform-table.html


> Q. Which development tools should I be using ?

The majority will say emacs + slime. I use emacs + inferior-lisp and
a couple of my own emacs lisp functions. From time to time, I try
slime.


> Summary of the
> key features of SLIME.

Try: http://common-lisp.net/project/slime/

Is there a problem with Internet connectivity somewhere?


> What if I'm a vi (vim) user ?

You must be a masochist. I was a vi user once upon a time, long long
before I got my NeXTstation.


> Q. Quick introduction to installing the relevant development tools
> and libraries (eg, list of Debian packages to install). If this
> turns into a list of instructions of the form `compile this',
> `edit the system definition' etc., then the answer is wrong.

Well, no, there is no SETUP.EXE to download and be set.
Unless you install cygwin on MS-Windows and check the box for clisp.
That'd be the easiest way to install a CL AFAIK.


> Q. Which tutorial on the Common Lisp language itself, and which
> reference, should I be using ? Answer: one tutorial book or
> webpage (I don't know what would be good to recommend) and one
> reference (the Hyperspec, obviously). Provide only one answer to
> each, not any lists; the web is full of lists of Lisp
> information.

The problem is that the Earth is full of different persons. It's not
possible to give ONE tutorial for every body. If you've not noticed
yet, your neighbors are not your clones! So go to a tutorial list,
and browse them all and see which comes better for you.

> Q. Which libraries should I definitely be looking at using, and what
> are they generally good for ?

What program do you want to write? How could WE answer this question
for you? You've been watching too much Starwars, no clones, no jedi
telepathic powers.


> Q. How do I turn my program into an executable ? NB that most Lisp
> FAQs seem to answer this question with either a blank space (!)
> or with some waffle.

It's been almost one year there's a simple positive answer to this
question for most of the free implementations (and it has been for
ever for commercial implementations of course).

But you don't say us what implementation you use. Could anybody with
Jedi telepathic powers help?


> The answer seems to be: "Sorry, this is not
> properly supported by anything yet; you must write a wrapper
> script. Here is an example."

This is not a bad idea in any case. I notice that even programs
compiled to binary ELF most often are launched from a wrapper script
(eg Mozilla, SecondLife, OpenOffice, etc).


> Q. How do I package my program in such a way that non-Lisp people
> will not be freaked out by the installation instructions ?

Well, you're the programmer, and you've got your users. YOU should know.


> [...]


> It was evident that attempting to find a spec to just read wasn't
> going to be very fruitful. Since I've used Lisp variants before on
> occasion, I decided it would be better to pick some project and
> just write a program.

Perhaps you're ripe to write your own tutorial to introduce people
like you to Common Lisp.


> First I thought I'd try starting my favourite lisp and playing with
> the REPL like many of the online tutorials suggest. This was all very
> well but it all seemed very primitive. Several of the lisps I ended
> up trying didn't have command line editing by default in Debian
> stable. Absurd !

Yeah! They're affraid of GPL readline! Absurd, I agree. In anycase,
don't you know rl or emacs? This is unix you know: small utilities
that do one thing well, but one thing. The job of command line
editing is done by libreadline or rl or emacs, not by random programs.

> Also, there were evidently many useful CL packages in Debian, some of
> which I wanted to use, but it seemed difficult to get documentation
> for them. For example, I installed cl-md5, and I could say (require
> 'md5) and have it work, but what to do next ? I wrote a one-liner to
> list the symbols in the package and then extracted their docstrings
> but it was a total pain. Surely, I thought, people can't really go
> about things this way in this day and age ? (I wouldn't even have
> thought of this approach if I wasn't so familiar with Emacs's builtin
> documentation system.)

See what I mean by self containined lisp system distribution?


> But I still find myself amazed at obvious things that appear to be
> missing from the CL standard and the libraries I was using:
>
> I had to write a function to convert a string of bytes (as produced by
> cl-md5) to hex.

There's sb-ext:octets-to-string and sb-ext:string-to-octets I don't
know if it's documented yet in 1.0.

In clisp, there's ext:convert-string-to-bytes and
ext:convert-string-from-bytes and it's documented since a long time.


> Newer (non-broken!) hash functions and so on don't
> seem to be available at all. I couldn't find a library for
> manipulating IP address ranges and masks, and when I tried to write
> the code myself I found that there wasn't even a standard function for
> splitting a string into substrings based on a delimiter !

You seems to have done a lot alone in your corner. Perhaps you should
have asked on irc://irc.freenode.org/#lisp or news:comp.lang.lisp
sooner.

To split a string (which is actually a vector of character, which is a
sequence), there's the SPLIT-SEQUENCE package.


> There is a
> cornucopia of functionality available for meddling with the innards of
> lisp, but hardly any of the pieces used for solving the kinds of
> problems encountered in the modern Internet.
>
> I presume that other people have already written much of the necessary
> code, but it is really hard to know where to look.

Usually, google works well.

By the way, I don't know if other have noticied, but I've even got the
impression that it learns from each user (queries vs. clicks on hits),
so when you keep asking stuff about lisp, it gives more lisp related
answers (and less speach impediment ones).


> Debian is
> well-supplied with CL packages and the infrastructure for loading them
> is good, but it's obviously only of limited use when choosing which
> one I should use.

Perhaps, but this is a unix system, not a lisp system.


> Finally, one problem that I still haven't tackled: Lisp systems all
> seem to have the idea that the way to run lisp programs is to invoke
> the lisp interpreter and type some runes into the REPL; they also
> think that this is the way to compile them too.

Indeed.


> For someone who has been working with Unix, the inability to turn a
> small lisp program into a proper executable, quickly and easily, is
> like returning to the stone age (or to Windows, heaven help us).

Well, it's more like booting a user-mode-linux, or any other Qemu or
Bosch with its own different OS. When've you've booted emacs, you're
in a different OS, emacs not in unix anymore. (See what I mean here:
http://www.informatimago.com/linux/emacs-on-user-mode-linux.html
) When you boot a CL implementation it's the same. Think of it as a
virtual lisp machine running on your linux supervisor.


> It is all very well for large projects to involve learning a lot of
> `system definition' facilities and to expect complicated and
> hard-to-install infrastructure on the computers involved. But often
> it is important to be able to ship small programs, in a form the
> recipient will be able to execute; it is also important to be able to
> make Lisp programs look and work like any other executable on the
> system.
>
> Naturally some of these problems can be addressed with wrapper scripts
> and a few extra tools. That's fine. But where is the standard
> facility for wrapper scripts, that I can put in a #! line ?

Why do you want a wrapper?

#!/usr/bin/clisp
or
#!/usr/bin/sbcl

(or other CL implementations) work perfectly well. For example, my
current ~/bin contains 23 clisp scripts:

% ~/bin/tally-bin
53 Bourne shell script text
129 Bourne-Again shell script text
59 C shell script text
23 a /usr/local/bin/clisp -ansi -q script text
1 awk script text
9 perl script text


> Where are the standard facilities for building *portably-deployable*
> CL programs: by which I mean not `portable to a different Lisp' but
> `a whole distribution bundle which is portable to a computer which
> does not yet have a Lisp system' ?

You'd have first to build your Dell corporation, and sell computers
pre-installed with lisp systems.

Then we could ask where are the standard facilities for building
*portably-deployable* unix programs: by which I mean not "portable to
a different lisp" but "a whole distribution bundle which is portable
to a computer which does not yet have a unix system" ?

Then perhaps we could point you to some emulating software or things
like coLinux or user-mode-linux.


> How do I integrate Lisp compilation into the build system of a large
> project using many languages and tools, all driven by something like
> make ?

Well, I've got my own makefile to do that. Really, it's been a long
time I've not used them anymore. If I have a big project with a
Makefile, at most nowadays it contains something like:

pgm:
@(echo '(LOAD "loader.lisp")' ; echo '(SAVE-IMAGE-FOR-PROJECT "pgm")' )\
| ./bin/lisp.sh

and all the rest is done in loader.lisp, with the help of asdf and
things like that.


> Obviously I could write my own answers but I want to concentrate on
> writing my application, not impedance matching to an approach to
> programming that feels like a 1960's timewarp. Wouldn't it be nice if
> Lisp were dragged kicking and screaming into the mid-1990's ?

It would be even nicer if mid-2000's had the facilities that were
available a long time ago, on the lisp machines. (In the mid-2000's I
still long for features on Mac hardware that were available in the
mid-1990's on NeXT hardware, and that, with basically the same OS and
toolbox!).


> Thanks for your attention. This has been a public service rant. I
> hope that the community here will take it the right way. Don't get me
> wrong; I like CL as a language and hope to increase my use of it.

You've detected a nice business opportunity. Hope you have some time
to implement it. Good Luck!


> I'm posting here to try to document some of the things that make it
> difficult for even an experienced programmer to get involved with
> Common Lisp. If the entrance barriers could be lowered, I think you
> might find it easier to encourage new and useful people to join the
> Lisp community.

I assume that that was what moved Franz, Corman, Lispworks, and the
other commercial implementors to provide well packaged lisp systems.
Commercially. Perhaps if you feel it so painful in the free world,
you could try commercial offerings?


--
__Pascal Bourguignon__ http://www.informatimago.com/

Nobody can fix the economy. Nobody can be trusted with their finger
on the button. Nobody's perfect. VOTE FOR NOBODY.

Kumar

unread,
Dec 4, 2006, 9:43:46 PM12/4/06
to
Not attempting to answer your questions, but as a fellow lisp
enthusiast I feel the same way you do. Recently I've been playing with
Cusp and Eclipse for lisp development with SBCL (I'm emacs-impaired).
http://www.paragent.com/lisp/cusp/cusp.htm Do check it out if you
haven't already. It comes closest to a good free IDE for lisp I think.

Robert Uhl

unread,
Dec 4, 2006, 10:12:12 PM12/4/06
to
Ian Jackson <ijac...@chiark.greenend.org.uk> writes:
>
> * Documentation for introducing Lisp to existing programmers is poor;
> existing tutorials are old or at least outdated.

Very true up until the publication of Practical Common Lisp. It's well
worth the modest price, and is also available free online.

> * Infrastructure for performing tasks which are routine in
> modern programming is often lacking and/or hard to find.

The old library problem. The answer from old-timers is 'write it
yourself,' and Lisp does make that more of an option than would be the
case in other languages--but it's still not a bloody great option.

> Q. If I am using a modern Unix system, which Common Lisp
> implementation should I choose ?

SBCL.

> Q. Which development tools should I be using ?

emacs+SLIME

> What if I'm a vi (vim) user ?

Come over to the light side of the force;-)

> Q. Which tutorial on the Common Lisp language itself, and which
> reference, should I be using ?

Practical Common Lisp and the HyperSpec (which links into SLIME nicely).

> Q. Which libraries should I definitely be looking at using, and what
> are they generally good for ?

Anything by Edi Weitz is excellent and suitable for its stated purpose.

> Q. How do I turn my program into an executable ?

SBCL does this now--see sb-ext:save-lisp-and-die.

> One particularly silly situation was that the sbcl in Debian stable
> was too old for unstable's slime and the sbcl in Debian unstable had a
> build-dependency only satisfiable by the sbcl in unstable !

ISTR that kind of thing used to happen a fair amount in Debian,
particularly in the Three Dark Years. Lisp not being as popular as
other languages, it's unsurprising (albeit annoying) that errors persist
longer than elsewhere.

> Finally, one problem that I still haven't tackled: Lisp systems all
> seem to have the idea that the way to run lisp programs is to invoke
> the lisp interpreter and type some runes into the REPL; they also
> think that this is the way to compile them too.
>
> For someone who has been working with Unix, the inability to turn a
> small lisp program into a proper executable, quickly and easily, is
> like returning to the stone age (or to Windows, heaven help us).

Well, in some ways it's like walking back into the stone age--but in
others it's like taking a rocket ship up into the space age. The
image-based approach of having all functions accessible everywhere is no
doubt more powerful, but unfortunately its advocates often seem to still
be stuck in the 1970s when it comes to user interface and such...

And I think more than a few fellows are still annoyed that the Lisp
Machines failed and rather like to pretend that Unix is just a
bootloader for Lisp.

--
Robert Uhl <http://public.xdi.org/=ruhl>
...and the harsh light of the server room shone round about them--which
the Pointy-Headed dare not abide--and they counted themselves safe.
--Ole Craig

Pascal Costanza

unread,
Dec 5, 2006, 3:15:01 AM12/5/06
to
Ian Jackson wrote:
> As an experienced programmer, I've heard a lot about how good Lisp is,
> and I like getting to grips with new languages. After conversations
> with friend who's keen I decided I should learn Common Lisp.

That's a good idea. ;)

> I thought I'd share some of my experiences here. While much of what
> I'm going to say is critical, I'd like to emphasize that I'm not
> giving up on Lisp. I like what I've seen so far, and the hurdles are
> more entrance barriers than they are problems for serious work - but
> they are quite time-consuming, and nowadays we are all in a hurry.
>
> So without futher ado, let me summarise my key point:
>
> * Documentation for introducing Lisp to existing programmers is poor;
> existing tutorials are old or at least outdated.

There are at least two pretty good new ones:

- http://www.gigamonkeys.com/book/
- http://psg.com/~dlamkins/sl/cover.html

> A comprehensive resource aimed at contemporary non-Lisp programmers
> is urgently needed. I was going to started an article on the CLiki
> with some pointers and discussion, but as I've written this article
> I've realised that the answers I have found are not really usefully
> transferrable to other people new to Lisp unless they have
> circumstances very like my own.

I had the same problem a few years ago when I made my switch to Common
Lisp. I have summarized my experiences at
http://p-cos.net/lisp/guide.html in the hope to make things easier for
other people. If you have suggestions for improving my guide, I would be
glad to hear about them.

> Secondarily:
>
> * Infrastructure for performing tasks which are routine in
> modern programming is often lacking and/or hard to find.

The main reason for this is one that newcomers typically don't find to
be a satisfactory answer, but it is indeed the main reason: The
infrastructure for performing tasks which are routine in Lisp is often
lacking and/or hard to find elsewhere.

Lisp provides different takes on things at several levels. For many of
the routine tasks in other languages, you will sooner or later find the
- more often than not better - equivalents in Lisp. The alternatives
that are used elsewhere are simply not needed. What looks like a
deficiency from the outside is very often indeed a win.

> * Support for Common Lisp development in Debian stable is
> surprisingly poor, given how mature the Lisp world is.

I can't comment on this.

> When I first settled on learning CL I thought I would read a standard
> reference work. This is my usual way of approaching new programming
> languages - I'm one of the minority of people who find they get on very
> well with reference manuals, and find tutorials distressingly vague
> about details.

Same here. ;)

> A Lisp-using friend lent me their copy of CLtL2, and I started reading
> through that. I quickly gave up because of Guy Steele's absurd habit
> of writing `and the thingum does the wossname to the doobry - no wait,
> it doesn't, in 1987 X3J13 voted that in fact the thingum does
> something completely different'. This is all very well once or twice
> but constantly reading, understanding and internalising complex
> descriptions, only to be told in the next paragraph that it's all
> false and I had to forget it all again, was too much like hard work.
> (There are some typographical indications but they are too weak to
> interrupt the flow of concentrated reading and in any case the text
> only does original-version-and-diff rather than an integrated
> description.)

True. CLtL2 was an intermediate report on Common Lisp standardization
that was apparently strongly needed by the community in 1989. The
finalization of ANSI Common Lisp took a few more years (it was finally
achieved in 1994/95), so it's clear that people needed something in
between to be able to work with Common Lisp. Common Lisp already had a
semi-official specification before (CLtL1), so for people at that time
it was indeed very useful to know what the differences between the two
texts were.

From nowadays perspective, it would indeed be a good idea to have a new
version of CLtL2 that reflects ANSI Common Lisp and completely omits the
old stuff. Especially because CLtL2 is in place indeed an excellent
text. But that would be a lot of work...

> My next approach was to try to read the Hyperspec through. Well, I'm
> still doing that - but the Hyperspec is poorly structured for this.
> The number of forward references is much higher than for most other
> language specifications. It's possible that a different reading order
> for the Hyperspec would improve this but I suppose since most people
> prefer to learn languages from tutorials I'm probably out of luck.

The HyperSpec indeed makes a suggestion for an alternative reading order
at http://www.lispworks.com/documentation/HyperSpec/Front/Hilights.htm

> It was evident that attempting to find a spec to just read wasn't
> going to be very fruitful. Since I've used Lisp variants before on
> occasion, I decided it would be better to pick some project and
> just write a program.

Another alternative is to start with the ISLISP specification which is
mostly a subset of Common Lisp. See the specification you can find at
http://islisp.info/ (Unfortunately, a few things do not work in Common
Lisp).


Pascal

--
My website: http://p-cos.net
Common Lisp Document Repository: http://cdr.eurolisp.org
Closer to MOP & ContextL: http://common-lisp.net/project/closer/

Pascal Costanza

unread,
Dec 5, 2006, 3:20:41 AM12/5/06
to
Robert Uhl wrote:
> Ian Jackson <ijac...@chiark.greenend.org.uk> writes:
>> * Documentation for introducing Lisp to existing programmers is poor;
>> existing tutorials are old or at least outdated.
>
> Very true up until the publication of Practical Common Lisp. It's well
> worth the modest price, and is also available free online.
>
>> * Infrastructure for performing tasks which are routine in
>> modern programming is often lacking and/or hard to find.
>
> The old library problem. The answer from old-timers is 'write it
> yourself,' and Lisp does make that more of an option than would be the
> case in other languages--but it's still not a bloody great option.

That's only part of the answer. The other part is that during the 90's,
Common Lisp was indeed almost dead. Since a few years, a new generation
of Lispers has been coming up and started to revive the language. The
interesting thing here, maybe even from a historical perspective, is
that although Lisp is nearly half a century old, it is nowadays more at
the level of an early adopters' technology, albeit with some very mature
technology behind the scenes. Nevertheless, the community is still quite
small, with all the advantages and disadvantages that this has...

niko...@random-state.net

unread,
Dec 5, 2006, 5:32:10 AM12/5/06
to
Ian Jackson wrote:

> Thanks for your attention. This has been a public service rant. I
> hope that the community here will take it the right way. Don't get me
> wrong; I like CL as a language and hope to increase my use of it.

I don't know if it counts as right way or not, but it motivated me to
post the "Nikodemus' Common Lisp FAQ", which had been gathering dust
for a while:


http://groups.google.com/group/comp.lang.lisp/msg/59e8d257e9ec648c?dmode=source

...and welcome to Lisp.

Cheers,

-- Nikodemus Siivola

Javier

unread,
Dec 5, 2006, 7:09:44 AM12/5/06
to

Ian Jackson ha escrito:

> So I decided I needed to try out SLIME. Note that SLIME isn't in
> Debian stable. Being an experienced Debian developer made solving
> this situation straightforward for me (if slightly tedious) but for
> many people it would have been hard or even impossible. (I have no
> idea what the situation is like on other Linux distributions, let
> alone on non-GNU systems.)

You should really, really use Emacs for Lisp developing, unless you pay
for Lisp Works.
Emacs is a decent editor once you understand how does it work.
For installing SLIME:
* Copy the slime folder under site-lisp of your emacs directory
(probably /usr/share/emacs/site-lisp)
* Open ~/.emacs and write (require 'slime) and evaluate it (puting the
cursor behind the right parenthesis and pushing C-x and C-e).

Once you have installed SBCL, in emacs push M-x and write slime, and
there you got it. (If it doesn't work, create a link from the sbcl
executable to /usr/bin/lisp).

And please, go to the help menu and spend some time in following the
emacs tutorial.

Ian Jackson

unread,
Dec 5, 2006, 7:33:12 AM12/5/06
to
In article <1165314729.8...@73g2000cwn.googlegroups.com>,

<niko...@random-state.net> wrote:
>I don't know if it counts as right way or not, but it motivated me to
>post the "Nikodemus' Common Lisp FAQ", which had been gathering dust
>for a while:
>
>http://groups.google.com/group/comp.lang.lisp/msg/59e8d257e9ec648c?dmode=source
>...and welcome to Lisp.

Thanks, that's very helpful.

Have you considered putting that FAQ on a web page ? Not that the web
needs more CL FAQs but it does need more CL FAQs with answers to
questions people might actually ask :-).

niko...@random-state.net

unread,
Dec 5, 2006, 8:05:40 AM12/5/06
to
Ian Jackson wrote:

> >http://groups.google.com/group/comp.lang.lisp/msg/59e8d257e9ec648c?dmode=source

> Have you considered putting that FAQ on a web page ? Not that the web
> needs more CL FAQs but it does need more CL FAQs with answers to
> questions people might actually ask :-).

Yes. The canonical url for the text file is

http://random-state.net/files/nikodemus-cl-faq.txt

I'll tweak it to play nice with some txt-to-html tool or another when I
have some extra time.

Cheers,

-- Nikodemus Siivola

Ian Jackson

unread,
Dec 5, 2006, 8:07:30 AM12/5/06
to
In article <87zma3x...@thalassa.informatimago.com>,

Pascal Bourguignon <p...@informatimago.com> wrote:
>Ian Jackson <ijac...@chiark.greenend.org.uk> writes:
>> * Documentation for introducing Lisp to existing programmers is poor;
>> existing tutorials are old or at least outdated.
>
>The "standard" answer is "Practical Common Lisp". It's available at
>Amazon, or even online! http://www.gigamonkeys.com/

This is helpful of course but if you want to get people started
quickly, a whole book is not a good answer. How long a web page is a
Perl or Python `get you started' tutorial ?

>On cliki, there are several pages dedicated to books, tutorials or
>lisp "education"...

Oh, yes, and I read many of them. But they (a) fail to address the
difficulties that I had (and presumably anyone new to CL has), and
(b) there are huge numbers of them containing huge amounts of
irrelevant material. It's evident that nothing ever gets deleted
(which is one of the common diseases of wikis, unfortunately).


>> Secondarily:
>> * Infrastructure for performing tasks which are routine in
>> modern programming is often lacking and/or hard to find.
>
>Yes. If you have some time, you might want to build a Lisp
>"distribution", like a linux distribution, where you'd prepackage
>everything for the novice or lazy user. There's already the LispBox,
>but perhaps it's not as maintained or as self contained as needed.

All of the languages that Common Lisp is competing with are available
pre-built, and often preinstalled, on all of the major Linux
distributions and many proprietary Unix systems. As are libraries for
writing webservers and clients, quick-and-dirty text processing,
network programming, etc. etc. etc.

What is needed is not a new bundling of the existing work. What is
needed is for the existing work to be present _in existing
distribution mechanisms_ that are already ubiquitous in the non-Lisp
world.

And of course, we need a standard and common set of libraries,
available in the same way. For example, Debian stable has three
Common Lisp regexp libraries. As someone new to Lisp I have no idea
how to choose between them. Obviously I can do research but:

*People writing in Python or Perl or Ruby do not have to do research
to choose between competing regexp libraries!*

To make CL attractive, it is essential that what other languages
regard as trivial and obvious tasks are easily addressed without a
great deal of background reading.


>Well there's two aspects:
>
>- It's difficult to package a lisp system at the level of a unix
> system. One should really build a self contained lisp system (even
> if it's stored as several files on a unix system).

This difficulty needs to be solved. Debian are doing reasonably well
here, and provide a way forward, but (much as I'm a Debian partisan)
Common Lisp needs good support elsewhere too.

Note that `one should really build a self contained lisp system' is
(as someone else said in this thread) just treating Unix like a
bootloader for Lisp. That's not the way complex systems are built in
the real world - the vast manority of significant computing systems
are heterogenous.

Lisp needs to live in a heterogenous world. It needs to cooperate
with other software readily and conveniently. A good FFI is part of
this (I haven't tried the CFFI but I'm told it's reasonable), but also
needed is good access to (and provision of) other kinds of OS-provided
inter-language, inter-process, and inter-system communication
facilities.

Java is the language which comes to my mind as one with the same
insular worldview: you must do everything in Java and you must do it
the Java Way. Java only got away with it because of massive amounts
of marketing hype which persuaded armies of idiot managers that it was
the way of the future.


>> What if I'm a vi (vim) user ?
>
>You must be a masochist. I was a vi user once upon a time, long long
>before I got my NeXTstation.

*blink* I'm not a vi user personally, but do you think that this
response is likely to encourage people to try out Common Lisp ?


>> Q. Which libraries should I definitely be looking at using, and what
>> are they generally good for ?
>
>What program do you want to write? How could WE answer this question
>for you? You've been watching too much Starwars, no clones, no jedi
>telepathic powers.

Have you programmed in Python ? The standard libraries are a bit
disorganised but there is clear documentation, most things that one
wants are provided, and if there is more than one of anything then all
but one are explicitly deprecated with a reference to the preferred
interface. (I'm not a fan of Python, by the way, but like any
programmer in the larger world I deal with it occasionally.)

Indeed, have you programmed recently in anything but Common Lisp ?

If you want CL to become more popular you will have to accomodate and
satisfy the expectations of people from outside the Lisp world.

As newcomers to Common Lisp go I'm am probably unusually fortunate: I
have a wide range of experience with different programming systems;
I've used a Lisp dialect before; I'm an expert on the operating system
I'm using; I'm a native English speaker with a very fast skimreading
rate; and so forth.

If you read my narrative and saw what I went through, just to get
started, doesn't it strike you that others might have similar
problems ?


>Then we could ask where are the standard facilities for building
>*portably-deployable* unix programs: by which I mean not "portable to
>a different lisp" but "a whole distribution bundle which is portable
>to a computer which does not yet have a unix system" ?

The difference is that in the real world there is quite likely already
to be a Unix system.

If you position CL as competing with Unix then you have already lost.
If you want to position it as competing with Perl, Python and C++ you
at least have a chance to play.

Ian Jackson

unread,
Dec 5, 2006, 8:13:05 AM12/5/06
to
In article <m3odqjj...@latakia.dyndns.org>,

Robert Uhl <eadm...@NOSPAMgmail.com> wrote:
>Ian Jackson <ijac...@chiark.greenend.org.uk> writes:
>> * Documentation for introducing Lisp to existing programmers is poor;
>> existing tutorials are old or at least outdated.
>
>Very true up until the publication of Practical Common Lisp. It's well
>worth the modest price, and is also available free online.

Thanks for the recommendation but when I made my suggestion I was
thinking of something a lot shorter than a book. Suggesting that
someone who wants to try out a language for some small project should
read through a book is, erm, optimistic.

>> * Infrastructure for performing tasks which are routine in
>> modern programming is often lacking and/or hard to find.
>
>The old library problem. The answer from old-timers is 'write it
>yourself,' and Lisp does make that more of an option than would be the
>case in other languages--but it's still not a bloody great option.

Yes. If there were a coherent directory of libraries, it would be an
improvement. I'm not suggesting that CL should gain a cesspit like
CPAN. Something more like Python's standard library set would be
ideal, but of course it would have to not be part of any particular CL
distribution.

>> Q. [stuff]
>[answer]

These are excellent answers and the kind of thing I was hoping for.
Would you like me to transfer them to a page on the CLiki ?

>And I think more than a few fellows are still annoyed that the Lisp
>Machines failed and rather like to pretend that Unix is just a
>bootloader for Lisp.

Yes, I did definitely get that impression from my background reading.
Needless to say I don't think that's an approach that's going to make
Lisp many new friends :-).

Wade Humeniuk

unread,
Dec 5, 2006, 9:55:33 AM12/5/06
to
Ian Jackson wrote:
> As an experienced programmer, I've heard a lot about how good Lisp is,
> and I like getting to grips with new languages. After conversations
> with friend who's keen I decided I should learn Common Lisp.
>
> I thought I'd share some of my experiences here. While much of what
> I'm going to say is critical, I'd like to emphasize that I'm not
> giving up on Lisp. I like what I've seen so far, and the hurdles are
> more entrance barriers than they are problems for serious work - but
> they are quite time-consuming, and nowadays we are all in a hurry.

Would be so kind to share some additional information about
your efforts?

1) What kind of experience programming do you have?
2) How long have you spent learning CL? Hours, days, weeks, years??
3) Why did you decide to learn CL?
4) I do not understand what you mean by "from a Unix perspective".
(Besides the problem of the Debian packages not being up to date,
and really having to use emacs).
(Since you mentioned Debian I assume by Unix you mean Linux).

W

Ken Tilton

unread,
Dec 5, 2006, 10:08:10 AM12/5/06
to

Ian Jackson wrote:

> Obviously I could write my own answers but I want to concentrate on
> writing my application,

That thwack you just felt was your 2k word boomerang of condescension
coming back to get your attention.

Everyone (you the latest):
goes thru the learning curve,
howls at the rawness of CL, and
just tears into programming in CL.

The latter is why no one (you the latest):
does what you are telling "us" to do

But once a week:
someone is dumb enough to walk into the NG of a new language and
shoot their mouths off without taking a moment to get up to speed.

Had you done so you would have found me explaining all this to last
week's self-important finger-shaker.

Please don't take this the wrong way.

kt

ps. Jeff, Nikodemus, any way to get this into the FAQs? i think it just
passed modifying '(a b c). k

--
Algebra: http://www.tilton-technology.com/LispNycAlgebra1.htm

"Well, I've wrestled with reality for thirty-five
years, Doctor, and I'm happy to state I finally
won out over it." -- Elwood P. Dowd

"I'll say I'm losing my grip, and it feels terrific."
-- Smiling husband to scowling wife, New Yorker cartoon

Ian Jackson

unread,
Dec 5, 2006, 12:48:43 PM12/5/06
to
In article <FLfdh.27584$rv4.18615@edtnps90>,

Wade Humeniuk <whumeniu+...@telus.net> wrote:
>1) What kind of experience programming do you have?

I've been programming since around 1980 and (as far as languages go) I
am expert in C, Tcl, bash, Perl and have varying levels of experience
in Haskell, Elisp, Python, Postscript, assembly languages, etc. etc.

>2) How long have you spent learning CL? Hours, days, weeks, years??

It's difficult to know exactly; I haven't been keeping a record.
The time I spent actually learning the Common Lisp language itself is
particularly hard to quantify but I've been dabbling on and off for a
month or two. I think I have probably spent the equivalent of several
days fighting incompatible software versions, hunting around on the
Internet for documentation, etc.

>3) Why did you decide to learn CL?

I thought I had adequately explained that in my previous article.

>4) I do not understand what you mean by "from a Unix perspective".
> (Besides the problem of the Debian packages not being up to date,
> and really having to use emacs).
> (Since you mentioned Debian I assume by Unix you mean Linux).

I mean that I want to treat Lisp like any of the other programming
languages on my existing Unix system. Or to put it another way, I
want to exclude two other perspectives which seem common: firstly
that CL should be treated like an operating system, and secondly the
perspective of Windows users.

Ken Tilton

unread,
Dec 5, 2006, 1:00:29 PM12/5/06
to

Wade Humeniuk wrote:
> Ian Jackson wrote:
>
>> As an experienced programmer, I've heard a lot about how good Lisp is,
>> and I like getting to grips with new languages. After conversations
>> with friend who's keen I decided I should learn Common Lisp.
>>
>> I thought I'd share some of my experiences here. While much of what
>> I'm going to say is critical, I'd like to emphasize that I'm not
>> giving up on Lisp. I like what I've seen so far, and the hurdles are
>> more entrance barriers than they are problems for serious work - but
>> they are quite time-consuming, and nowadays we are all in a hurry.
>
>
> Would be so kind to share some additional information about
> your efforts?
>
> 1) What kind of experience programming do you have?
> 2) How long have you spent learning CL? Hours, days, weeks, years??

...and...

> 2a) How many hours (roughly) it took to get over the hump described
in the original rant?

kt

Ian Jackson

unread,
Dec 5, 2006, 12:54:47 PM12/5/06
to
In article <mYfdh.13$7_2...@newsfe09.lga>,

Ken Tilton <kent...@gmail.com> wrote:
>Everyone (you the latest):
> goes thru the learning curve,
> howls at the rawness of CL, and

Are you at all interested in trying to make that less of an unpleasant
experience ? Because I think you're overoptimistic when you say that
`everyone' then ....

> just tears into programming in CL.

Many people will be discouraged by the hurdles that I hope I'm helping
to identify and give up and never come back. And they'll tell all of
their colleagues how bad it was.

>But once a week:
> someone is dumb enough to walk into the NG of a new language and
> shoot their mouths off without taking a moment to get up to speed.

If you'd actually read my article you'd realise that I _did_ spend the
time to get up to speed. I was under the impression that the denizens
of this newsgroup might be interested to know how (from my point of
view) this process was difficult and by implication how it can be made
easier for the next person.

I'm glad to see that others beside yourself do seem to be interested
in making Lisp more attractive, so that people will choose to use it.

bradb

unread,
Dec 5, 2006, 1:13:20 PM12/5/06
to
> I'm glad to see that others beside yourself do seem to be interested
> in making Lisp more attractive, so that people will choose to use it.
>

Hi Ian,
I checked out your website and see that you wrote Debian's dpkg. Since
you obviously have expertise in the package management arena, I would
be curious to hear your opinions on the current state of Lisp's package
management systems (ASDF and ASDF-install).

Cheers
Brad

Don Geddis

unread,
Dec 5, 2006, 1:55:06 PM12/5/06
to
Ian Jackson <ijac...@chiark.greenend.org.uk> wrote on 05 Dec 2006 01:0:
> A comprehensive resource aimed at contemporary non-Lisp programmers
> is urgently needed. I was going to started an article on the CLiki
> with some pointers and discussion, but as I've written this article
> I've realised that the answers I have found are not really usefully
> transferrable to other people new to Lisp unless they have
> circumstances very like my own.

You seem to have answered your own question. You couldn't find a tutorial
that directly addressed your personal circumstances, but at the same time
you now realize that such a tutorial, if it had existed, would have been of
little use to anyone EXCEPT you.

No doubt that very limited audience is why that specific tutorial did not
exist.

> * Support for Common Lisp development in Debian stable is
> surprisingly poor, given how mature the Lisp world is.

It's an odd choice you made, to insist on "Debian stable". The stable branch
of Debian is well known for being years out of date. In some sense, the newer
Ubuntu distribution is really just Debian with a quicker cycle of "stable"
releases; there wouldn't have been motivation to make Ubuntu if Debian's
release policy wasn't so slow.

It so happens that a great amount of progress has been made on Lisp
implementations in Debian in the last few years. So much of your difficulty
on this score is more a problem with Debian stable, than it is a problem with
the lisp world. Many of your reported difficulties have ALREADY been solved
today; they just happen not to be in the ancient distribution of Debian
labelled "stable".

> When I first settled on learning CL I thought I would read a standard
> reference work. This is my usual way of approaching new programming
> languages - I'm one of the minority of people who find they get on very
> well with reference manuals, and find tutorials distressingly vague
> about details.
>
> A Lisp-using friend lent me their copy of CLtL2, and I started reading
> through that.

A poor choice, unfortunately, since that text is far out of date.

> My next approach was to try to read the Hyperspec through. Well, I'm
> still doing that - but the Hyperspec is poorly structured for this.
> The number of forward references is much higher than for most other
> language specifications.

I find this complaint kind of odd. The ANSI spec is explicitly written to
an audience of Lisp implementors, NOT as a tutorial for a newbie to Lisp.
That's what tutorials are for.

And yet you rejected all texts that were addressed to your situation, chose
to attempt a text that was explicitly NOT addressed to you, and then got
frustrated when you found that it didn't work well for you?

It seems like your causing some of your own difficulties here...

> One particularly silly situation was that the sbcl in Debian stable was too
> old for unstable's slime and the sbcl in Debian unstable had a
> build-dependency only satisfiable by the sbcl in unstable ! I was able to
> solve this by bootstrapping with an sbcl binary package from backports.org.

More trouble because of your desire to stick with Debian stable. That
original choice was probably an error, and any reasonable tutorial (or more
experienced friend) would NOT have recommended it.

> I'm posting here to try to document some of the things that make it
> difficult for even an experienced programmer to get involved with
> Common Lisp. If the entrance barriers could be lowered, I think you
> might find it easier to encourage new and useful people to join the
> Lisp community.

I bet you would have had a very different experience if someone had been able
to guide you to this at the start:
"Practical Common Lisp" tutorial by Peter Seibel
Emacs + SLIME
Debian "testing"
SBCL
instead of CLtL2, Hyperspec, Vi, Debian stable, and implementation questions.

Some of your difficulties would still have been there, but probably half of
them would have just vanished immediately.

-- Don
_______________________________________________________________________________
Don Geddis http://don.geddis.org/ d...@geddis.org
Normally I don't believe in miracles, but something happened when I was about
seven years old I still can't explain. I was on the front porch with Grandpa,
about to eat my Twinkies, when Grandpa started grabbing his chest and saying he
was having a heart attack. I ran to get Mom, but when I got back, Grandpa was
okay. "An angel helped me," he said. "Also, he ate your Twinkies."
-- Deep Thoughts, by Jack Handey [1999]

Pedro Kröger

unread,
Dec 5, 2006, 2:10:44 PM12/5/06
to
Ian Jackson <ijac...@chiark.greenend.org.uk> writes:

> This is helpful of course but if you want to get people started
> quickly, a whole book is not a good answer. How long a web page is a
> Perl or Python `get you started' tutorial ?

could you point some of those tutorials? so we can have an idea of what
you consider to be good.

> Oh, yes, and I read many of them. But they (a) fail to address the
> difficulties that I had (and presumably anyone new to CL has), and
> (b) there are huge numbers of them containing huge amounts of
> irrelevant material. It's evident that nothing ever gets deleted
> (which is one of the common diseases of wikis, unfortunately).

again, could you, please, point what difficulties you had and what you'd
expect to have in these tutorials? I'm not trying to be picky here (or
whatever), I'm just trying to understand what people think is missing so
we can a) direct then to something that already exists and solve it, of
b) create it.

For instance, what do you think of this introduction by Paul Graham?

http://lib.store.yahoo.net/lib/paulgraham/acl2.txt

Pedro Kroger

joseph...@gmail.com

unread,
Dec 5, 2006, 2:23:43 PM12/5/06
to

Ian Jackson wrote:

> I mean that I want to treat Lisp like any of the other programming
> languages on my existing Unix system. Or to put it another way, I
> want to exclude two other perspectives which seem common: firstly
> that CL should be treated like an operating system, and secondly the
> perspective of Windows users.

Do you want a pony with that?

Lisp is not *like* any of the other programming languages on your
existing Unix system. One important reason for this is that Lisp was
born a decade before Unix ever existed, much less became widespread. In
fact, features like pathnames in Common Lisp turned out the way they
are because they needed to support multiple file systems with non-Unix
semantics.

If you are taking guitar lessons, do you similarly feel you should
treat it just like the violins and trumpets of your existing symphony
orchestra?

Ken Tilton

unread,
Dec 5, 2006, 2:40:14 PM12/5/06
to

Ian Jackson wrote:
> In article <mYfdh.13$7_2...@newsfe09.lga>,
> Ken Tilton <kent...@gmail.com> wrote:
>
>>Everyone (you the latest):
>> goes thru the learning curve,
>> howls at the rawness of CL, and
>
>
> Are you at all interested in trying to make that less of an unpleasant
> experience ?

Naw, fuck 'em. if they give up they are unworthy.

I think what you are missing is that:
it is a lot of work (making it easier)
you are not doing it either (because it is a lot of work)
in the end it will not increase Lisp mindshare because...

> Because I think you're overoptimistic when you say that
> `everyone' then ....
>
>
>> just tears into programming in CL.

The only people turned back by your experience are tire kickers, not
people really looking for A Better Way. If someone comes to Lisp because:
they have heard it is vastly better than other languages,
they see all sorts of nuts on c.l.l whooping it up, and
they have read the Road to Lisp

... do you think (how many hours?) of aggravation will stop them?

Barker: "Stairway to Heaven! Open to all! Come on up! One-day amnesty!"
Kenny: "No elevator?"

> Many people will be discouraged by the hurdles that I hope I'm helping
> to identify and give up and never come back. And they'll tell all of
> their colleagues how bad it was.

There is no such thing as bad publicity. Their colleagues will ask them
why they were looking at a dead language. They say, Omigod, have you
read The Road to Lisp? A week later the resulting assault team has a
free Lisp environment working and the one smart colleague went off on
her own, downloaded ACL Trial, and won a programming contest with CL.

>
>
>>But once a week:
>> someone is dumb enough to walk into the NG of a new language and
>> shoot their mouths off without taking a moment to get up to speed.
>
>
> If you'd actually read my article you'd realise that I _did_ spend the
> time to get up to speed.

No, sorry, I meant on this question of why it is so hard to get going on
Lisp. I am not kidding, your clone was in here last week or the week
before. I have to say, savaging you blowhards is starting to get as
tedious as a treadmill.

> I was under the impression that the denizens
> of this newsgroup might be interested to know how (from my point of
> view) this process was difficult and by implication how it can be made
> easier for the next person.

See above. We get blessed with this brilliant insight about once a week.
It is pretty funny, really. And if it makes you feel better, if the
archives go back to '95 you might find me saying the same thing, because
I had the exact same reaction -- and I even had the lovely MCL
integrated IDE, Freditor, and compiler all in one. I /know/ I thought
it, just not sure I posted it.

No, what we (that is the royal we) want you to do is stop pontificating
and get to work on the CFFI equivalent of a sockets lib. LispNYC's Perry
and someone here on c.l.l almost got started on one when SoC 2006 was
aborning.

Or even better, finish Fetter/Verrazano. It is almost there and would
open up every C/C++ library to CL a hundred times better than SWIG ever
will.

I know, I know, that would be so much more work than just lecturing a
non-existent community. Welcome to the club, you are now as ineffectual
as the rest of us Lispniks, smugly enjoying a great language and not
doing the heavy-lifting ti takes to grow the language.

>
> I'm glad to see that others beside yourself do seem to be interested
> in making Lisp more attractive, so that people will choose to use it.
>

They are just sucking up to you because you have some cred. These clowns
know nothing. I have been telling them about Cells (heaven itself) for
ten years and I have ten users. Take away Edi and Marc and I have
produced more valuable bindings and libraries alone than the entire group.

You are now the blind leading the blind. We do not need a free Lisp and
we do not need Emacs+Slime+ASDF For Dummies, because noobs do not get
that far. They just walk up to the store window, see the shelves are
bare of the libraries they just bolt together in other languages, and
keep on walking.

No kidding, finishing Verrazano would make up for all your sins.

kt

Pascal Costanza

unread,
Dec 5, 2006, 2:52:33 PM12/5/06
to
Ian Jackson wrote:

> And of course, we need a standard and common set of libraries,
> available in the same way. For example, Debian stable has three
> Common Lisp regexp libraries. As someone new to Lisp I have no idea
> how to choose between them. Obviously I can do research but:
>
> *People writing in Python or Perl or Ruby do not have to do research
> to choose between competing regexp libraries!*
>
> To make CL attractive, it is essential that what other languages
> regard as trivial and obvious tasks are easily addressed without a
> great deal of background reading.

CL is not a language for people who are afraid of understanding the
background of what they are using.

On the other hand, if you want to have a CL system that comes with a lot
of preinstalled libraries, there are a few choices out there. For
example, using one of the commercial implementations is not a bad
choice, especially not for a beginner. (Don't worry here, due to some
fundamental characteristics of Lisp, there is little danger of vendor
lock-in here.)

> Have you programmed in Python ? The standard libraries are a bit
> disorganised but there is clear documentation, most things that one
> wants are provided, and if there is more than one of anything then all
> but one are explicitly deprecated with a reference to the preferred
> interface. (I'm not a fan of Python, by the way, but like any
> programmer in the larger world I deal with it occasionally.)
>
> Indeed, have you programmed recently in anything but Common Lisp ?
>
> If you want CL to become more popular you will have to accomodate and
> satisfy the expectations of people from outside the Lisp world.

Becoming more popular is an important goal, since it increases the
number of users and thus helps to ensure a certain longevity of CL.

But: Becoming popular is not the most important goal!

Lisp requires a change of perspective in a few areas, which includes
dropping a number of habits and replacing them with new ones. Some
elements of this new perspective are hard to understand in the
beginning. So you need to be patient in this regard. It's impossible to
be able to judge these things after just two months.

One important boundary condition is that Common Lisp is not a single
implementation language, but a language specification with quite a few
implementations that adhere to it. Some of the things you are asking for
are impossible due to this fact. The different implementations have
their respective strengths and it is quite unlikely that one of them
will become _the_ single dominant Common Lisp.

(And that's just the tip of the iceberg.)

Alex Mizrahi

unread,
Dec 5, 2006, 3:41:21 PM12/5/06
to
(message (Hello 'Ian)
(you :wrote :on '(05 Dec 2006 13:07:30 +0000 (GMT)))
(

IJ> All of the languages that Common Lisp is competing with are available
IJ> pre-built, and often preinstalled, on all of the major Linux
IJ> distributions and many proprietary Unix systems.

hell, no.
i have a _lot_ of hassle installing Java -- the most language Common Lisp is
competing.
at same time, lisp installs surprisingly well.

)
(With-best-regards '(Alex Mizrahi) :aka 'killer_storm)
"People who lust for the Feel of keys on their fingertips (c) Inity")


Alex Mizrahi

unread,
Dec 5, 2006, 3:43:59 PM12/5/06
to
(message (Hello 'Ian)
(you :wrote :on '(05 Dec 2006 01:08:23 +0000 (GMT)))
(

IJ> Q. How do I turn my program into an executable ?

there is no good and official way to make executable from Java or .net
application, at same time Java is most popular language according to TIOBE,
so i think it's not a case.

Ian Jackson

unread,
Dec 5, 2006, 4:01:27 PM12/5/06
to
In article <87lklmx...@gmail.com>,

Pedro =?utf-8?Q?Kr=C3=B6ger?= <pedro....@gmail.com> wrote:
>Ian Jackson <ijac...@chiark.greenend.org.uk> writes:
>> This is helpful of course but if you want to get people started
>> quickly, a whole book is not a good answer. How long a web page is a
>> Perl or Python `get you started' tutorial ?
>
>could you point some of those tutorials? so we can have an idea of what
>you consider to be good.

http://www.python.org/doc/Intros.html has a bunch of them. Having a
look at the descriptions there and with a quick overview, the ones
under `Introductions for programmers' seem like the kind of thing that
Lisp is really lacking.

Particularly, look at the structure of
http://www.python.org/doc/lj21.html
which starts with the assumption that you don't know how to run Python
and in the next paragraph tells you how to make a script with a #!-line.

Python tutorials have it slightly easier because the support is
generally shipped with most people's operating systems. The Linux
Journal article http://www.linuxjournal.com/article/3946 does deal
with this to some extent but more work is needed to make a pleasant
Common Lisp environment so a CL introduction ought to pay more
attention to that.

(I wouldn't say that these documents are necessarily `good' - I
haven't reviewed them with that kind of eye and anyway I'm not really
a Python expert - but they're an example of the kind of size,
structure and topics I would like covered in an analogous document for
CL.)

>again, could you, please, point what difficulties you had and what you'd
>expect to have in these tutorials? I'm not trying to be picky here (or
>whatever), I'm just trying to understand what people think is missing so
>we can a) direct then to something that already exists and solve it, of
>b) create it.

They tend not to answer the questions I posed in my original posting.
Rather, they are introductions to the Common Lisp language itself.

Speaking personally I've previously been exposed to the basic
constructs found in various lisps and was happy to use the hyperspec
and guesswork. For others there is copious and high-quality
documentation for the language itself.

>For instance, what do you think of this introduction by Paul Graham?
>http://lib.store.yahoo.net/lib/paulgraham/acl2.txt

This is exactly an example of the kind of high-quality language
documentation I mention above. Typically they can be thought of as
`a tutorial on what forms to type into a REPL' to get started with the
CL core.

That's not what I think is missing: what I want is `how to get to a
nice REPL with command history and completion and integrated
documentation lookup'; `how to find a library to do XYZ'; `how to make
a Unix program out of my Lisp program' etc. - impedance matching.

Ian Jackson

unread,
Dec 5, 2006, 4:11:46 PM12/5/06
to
In article <1165342400.2...@73g2000cwn.googlegroups.com>,

bradb <brad.be...@gmail.com> wrote:
>I checked out your website and see that you wrote Debian's dpkg. Since
>you obviously have expertise in the package management arena, I would
>be curious to hear your opinions on the current state of Lisp's package
>management systems (ASDF and ASDF-install).

I'm afraid I haven't got to grips with asdf (or any of its
competitors) at all so I can't answer that question at all.

What I can say is this: I was most impressed with the
`common-lisp-controller' system which Debian use to solve many of
these problems in a more tightly controlled way, to make CL addon
packages easy to use in Debian (and Gentoo, a websearch now tells me).
IIRC it's based on asdf.

It `just worked' in a way that many Debian approaches to similar
problems have failed :-). (Debian's Python module support system, and
its Emacs Lisp addon system, have both had serious problems.)

I haven't got anywhere near making my own cl-* extension package so I
don't know how easy or error-prone that is, but I did come across what
seemed to be comprehensive documentation for how to do it, included in
the relevant Debian package.

http://www.cliki.net/common-lisp-controller seems relevant too.

Ian Jackson

unread,
Dec 5, 2006, 4:06:31 PM12/5/06
to
In article <4tm101F...@mid.individual.net>,

Pascal Costanza <p...@p-cos.net> wrote:
>Becoming more popular is an important goal, since it increases the
>number of users and thus helps to ensure a certain longevity of CL.
>
>But: Becoming popular is not the most important goal!

Obviously not. But the things I'm suggesting don't have a downside.
They just make CL more attractive. I'm not asking that CL be changed,
even - I think the solution is better documentation and better and
more standard addons (de-facto standard would be fine).

>Lisp requires a change of perspective in a few areas, [...]

This is true of any programming language. What is troublesome about
Common Lisp is that - if you have a certain mindset - it seems to
insist on being the whole answer to the problems you attack with it.
That's not helpful, because complex and difficult problems are usually
best solved with a mixture of tools and approaches.

>One important boundary condition is that Common Lisp is not a single

>implementation language, but a language specification [...]

The same is true of C and Haskell and even Java. That's doesn't
preclude addressing the barriers to adoption I'm discussing.

Nathan Froyd

unread,
Dec 5, 2006, 4:29:38 PM12/5/06
to
Ian Jackson wrote:
> I had to write a function to convert a string of bytes (as produced by
> cl-md5) to hex. Newer (non-broken!) hash functions and so on don't
> seem to be available at all.

You might have already found this, but Ironclad
(http://www.cliki.net/Ironclad) has several non-broken hash functions
in it. It even includes byte-array-to-hex-string. I believe it's
packaged in Debian under 'cl-ironclad'.

Unfortunately, you will have to resort to the 'extract docstrings
manually' approach to the documentation, but it is there.

-Nathan

r...@homeunix.net

unread,
Dec 5, 2006, 4:53:56 PM12/5/06
to
Ian Jackson <ijac...@chiark.greenend.org.uk> wrote in
news:Nje*+Ww...@news.chiark.greenend.org.uk:

> In article <FLfdh.27584$rv4.18615@edtnps90>,
> Wade Humeniuk <whumeniu+...@telus.net> wrote:
. etc.
>
>>2) How long have you spent learning CL? Hours, days, weeks, years??
>
> It's difficult to know exactly; I haven't been keeping a record.
> The time I spent actually learning the Common Lisp language itself is
> particularly hard to quantify but I've been dabbling on and off for a
> month or two. I think I have probably spent the equivalent of several
> days fighting incompatible software versions, hunting around on the
> Internet for documentation, etc.
>

2 months?

after 2 years your mind will probably change.
Lisp is a byte-the-bullet technology. Some say you need at least 10 years
to master it.

Ken Tilton

unread,
Dec 5, 2006, 5:19:33 PM12/5/06
to

>> I think I have probably spent the equivalent of several
>>days fighting incompatible software versions, hunting around on the
>>Internet for documentation, etc.

And another day ranting about how hard it was which it would not have
been had you bought Lispworks Pro* for $1500. And then, good God, look
at what you get with it that does not come with "free" Lisps:

http://www.lispworks.com/products/features.html#editionfeatures

Not sure how you price your days, but hopefully you are kicking yourself
by now (I mean I hope you price your days higher than $375).

OK, everyone over on the SBCL thread is probably wondering where to send
their apologies and concede my point... :)

kt

* Not sure what deal you'd get on the even better ACL Pro and whether
you can live with the licensing royalty they want.

k

Pascal Costanza

unread,
Dec 5, 2006, 5:58:59 PM12/5/06
to
Ken Tilton wrote:

>> Many people will be discouraged by the hurdles that I hope I'm helping
>> to identify and give up and never come back. And they'll tell all of
>> their colleagues how bad it was.
>
> There is no such thing as bad publicity. Their colleagues will ask them
> why they were looking at a dead language. They say, Omigod, have you
> read The Road to Lisp? A week later the resulting assault team has a
> free Lisp environment working and the one smart colleague went off on
> her own, downloaded ACL Trial, and won a programming contest with CL.

At some stage, you have to make up your mind.

Not so long ago, you stated that the release of SBCL 1.0 has marked a
"sad day" and made you conclude that "Lisp loses because the best and
the brightest young Lisp turks are just trying to drive Franz and
Lispworks out of business when there is so much other amazing code to be
written." (Your words.)

Now you say that "there is no such thing as bad publicity."

What is it?


Pascal

[To give this a similar spin: People will ask why Lispers are spending
their time on a new open-source implementation when there are already
excellent commercial and open-source implementations available. They
say, Omigod, have you read The Road to Lisp? A week later... etc. pp. ;) ]

Aidan Kehoe

unread,
Dec 5, 2006, 6:09:41 PM12/5/06
to

Ar an cúigiú lá de mí na Nollaig, scríobh Ken Tilton:

> [...] The only people turned back by your experience are tire kickers,


> not people really looking for A Better Way. If someone comes to Lisp
> because: they have heard it is vastly better than other languages, they
> see all sorts of nuts on c.l.l whooping it up, and they have read the
> Road to Lisp

I’m intrested in real Lisp because I’m developing XEmacs, and because in
XEmacs Lisp, if you’re emulating Common Lisp style, you’re writing better
code than otherwise. I am exceptional in this, certainly, but the
conclusions Ian draws are also applicable to me, and I think that depending
on those who are already committed to a language to support a particular
implementation is defeatist at best, from the perspective of that
implementation and of that language.

> [...] You are now the blind leading the blind. We do not need a free Lisp


> and we do not need Emacs+Slime+ASDF For Dummies, because noobs do not get
> that far. They just walk up to the store window, see the shelves are bare
> of the libraries they just bolt together in other languages, and keep on
> walking.

I _fucking hate_ Perl. It’s unmaintainable--by which I mean, the interpreter
has far too much tolerance for alternative, endorsed ways of saying the same
thing, so if I hand a program to someone else and come back in a year it’s
incomprehensible--and confusing in its documentation; but I use it
constantly because its libraries (CPAN) mean I don’t have to implement MIME
(with good suppport for a long list of character sets) and HTTP again in the
language I would otherwise prefer to use. Ditto several other languages.

The barriers to entry for a language matter. You can ignore that, and you
will get a circle of self-reinforcing zealots as your languages users, and
hear very little about the question again. Or, you could promote _the
language,_ rather than your own opinons as to how great and leet it is.

--
Santa Maradona, priez pour moi!

Pascal Costanza

unread,
Dec 5, 2006, 6:16:02 PM12/5/06
to
Ian Jackson wrote:
> In article <4tm101F...@mid.individual.net>,
> Pascal Costanza <p...@p-cos.net> wrote:
>> Becoming more popular is an important goal, since it increases the
>> number of users and thus helps to ensure a certain longevity of CL.
>>
>> But: Becoming popular is not the most important goal!
>
> Obviously not. But the things I'm suggesting don't have a downside.
> They just make CL more attractive. I'm not asking that CL be changed,
> even - I think the solution is better documentation and better and
> more standard addons (de-facto standard would be fine).

The documentation exists and is appropriate. It's just longer because
there is more to explain. As I tried to explain, CL requires a more
radical change of perspective than other languages.

It's unclear to me what you mean with "better." Better than what?

More standard libraries and add-ons are being developed. Due to the
(weird) early adopters' state of Common Lisp at this point in time, some
things haven't stabilized yet.

But another important aspect is that Common Lisp is not a language whose
design is being dictated by a single person or a single self-elected
group of people. This has both disadvantages (which you seem to notice)
and advantages (which you don't yet seem to notice).

>> Lisp requires a change of perspective in a few areas, [...]
>
> This is true of any programming language. What is troublesome about
> Common Lisp is that - if you have a certain mindset - it seems to
> insist on being the whole answer to the problems you attack with it.
> That's not helpful, because complex and difficult problems are usually
> best solved with a mixture of tools and approaches.

The cool thing about Common Lisp that you can have a mixture of tools
and approaches in the same environment.

To quote Guy Steele: "If you give someone Fortran, he has Fortran. If
you give someone Lisp, he has any language he pleases."

Common Lisp is not a language. It's a language toolbox. Unfortunately,
this is exactly the one part that is hard to understand in the beginning
and will take a while to grasp.

Exactly because it is a language toolbox, the notion of standard
libraries makes a lot less sense than in other languages.

Ken Tilton

unread,
Dec 5, 2006, 7:02:17 PM12/5/06
to

Aidan Kehoe wrote:
> Ar an cúigiú lá de mí na Nollaig, scríobh Ken Tilton:
>
> > [...] The only people turned back by your experience are tire kickers,
> > not people really looking for A Better Way. If someone comes to Lisp
> > because: they have heard it is vastly better than other languages, they
> > see all sorts of nuts on c.l.l whooping it up, and they have read the
> > Road to Lisp
>
> I’m intrested in real Lisp because I’m developing XEmacs, and because in
> XEmacs Lisp, if you’re emulating Common Lisp style, you’re writing better
> code than otherwise. I am exceptional in this, certainly, but the
> conclusions Ian draws are also applicable to me, and I think that depending

> on those who are already committed to a language...

Cool, you got "already committed" from "having visited
http://wiki.alu.org/RtL_Highlight_Film"? We might need you for an
upcoming study correlating Broca's Area volume with pointless Usenet
comments.

> to support a particular
> implementation is defeatist at best, from the perspective of that
> implementation and of that language.
>
> > [...] You are now the blind leading the blind. We do not need a free Lisp
> > and we do not need Emacs+Slime+ASDF For Dummies, because noobs do not get
> > that far. They just walk up to the store window, see the shelves are bare
> > of the libraries they just bolt together in other languages, and keep on
> > walking.
>
> I _fucking hate_ Perl. It’s unmaintainable--by which I mean, the interpreter
> has far too much tolerance for alternative, endorsed ways of saying the same
> thing, so if I hand a program to someone else and come back in a year it’s
> incomprehensible--and confusing in its documentation; but I use it
> constantly because its libraries (CPAN) mean I don’t have to implement MIME
> (with good suppport for a long list of character sets) and HTTP again in the
> language I would otherwise prefer to use. Ditto several other languages.

Is there someone there who can explain to you that you just said is
verbatim what I said? And we /will/ want you for the Broca's Area study.

>
> The barriers to entry for a language matter. You can ignore that, and you

> will get a circle of self-reinforcing zealots as your languages users,...

Why does that sound so good after the past few days?

> and
> hear very little about the question again. Or, you could promote _the
> language,_ rather than your own opinons as to how great and leet it is.

Promote the language?! I am a commercial application developer using
Lisp as my secret edge, which is why I spend a considerable amount of
time walking the wire chasing away noobs.

As for this being just my opinion, damn, where is it... anybody got a
link to the RtL? TIA.

Ken Tilton

unread,
Dec 5, 2006, 7:14:42 PM12/5/06
to

Pascal Costanza wrote:
> Ken Tilton wrote:
>
>>> Many people will be discouraged by the hurdles that I hope I'm helping
>>> to identify and give up and never come back. And they'll tell all of
>>> their colleagues how bad it was.
>>
>>
>> There is no such thing as bad publicity. Their colleagues will ask
>> them why they were looking at a dead language. They say, Omigod, have
>> you read The Road to Lisp? A week later the resulting assault team has
>> a free Lisp environment working and the one smart colleague went off
>> on her own, downloaded ACL Trial, and won a programming contest with CL.
>
>
> At some stage, you have to make up your mind.
>
> Not so long ago, you stated that the release of SBCL 1.0 has marked a
> "sad day" and made you conclude that "Lisp loses because the best and
> the brightest young Lisp turks are just trying to drive Franz and
> Lispworks out of business when there is so much other amazing code to be
> written." (Your words.)
>
> Now you say that "there is no such thing as bad publicity."
>
> What is it?

This type of bullsh*t Usenet gotcha-play is exactly what gets you into
trouble on Usenet. I think you saw Garret doing it and decided it was a
good idea, probably why you both ended up on EN's sh*t list and mine.

"Gotcha" is like analogies, they lead to arguments about the gotchaness
of the gotcha, an exponential explosion guaranteed.

You will not be a real Lispnik until you can respond on c.l.l without
playing "Gotcha".

hth, kenny

ps. If it helps, no, I read what you wrote and could not understand a
word of it, which is why I am being careful to respond not to it but
instead to its litigiousness. k

pps. This applies also to some one-liner you addressed to me recently,
which I missed because you were in my killfile. That remark just reeked
of aggression, sand-bagging, and gotcha. You post like a troll. The
funny thing is, I was wondering how you had gotten into my killfile, now
I am wondering something else. k

Pascal Costanza

unread,
Dec 5, 2006, 7:26:12 PM12/5/06
to

OK, you're right. I apologize.


Pascal

Pedro Kröger

unread,
Dec 5, 2006, 7:26:05 PM12/5/06
to

Ian Jackson wrote:

> That's not what I think is missing: what I want is `how to get to a
> nice REPL with command history and completion and integrated
> documentation lookup'; `how to find a library to do XYZ'; `how to make
> a Unix program out of my Lisp program' etc. - impedance matching.

Now I see. I believe a single tutorial like this is indeed missing. I
suppose that's not that easy because there is not only one
implementation of lisp (like python) that 'dictates' how things should
be done. So, how one gets started with C? if he uses gcc he may compile
using the shell, OTOH if using visual C the approach may be different.
Anyway, I do think that a documentation of this kind could be useful,
and could, of course, point to the others documentations.

Pedro Kroger

Mike T

unread,
Dec 5, 2006, 7:53:14 PM12/5/06
to
Ken Tilton wrote:
>
> This type of bullsh*t Usenet gotcha-play is exactly what gets you into
> trouble on Usenet. I think you saw Garret doing it and decided it was a
> good idea, probably why you both ended up on EN's sh*t list and mine.

Actually Kenny out of all the regulars you seemed to be fairly highly
ranked on Erik sh*t list. This is well documented using google groups
search.

Here's some reminders:
http://groups.google.co.uk/group/comp.lang.lisp/browse_frm/thread/707067b1ace5fd18/e15d85ac5626af9e?lnk=st&q=naggum+tilton+shit&rnum=1&hl=en#e15d85ac5626af9e

http://groups.google.co.uk/group/comp.lang.lisp/browse_frm/thread/707067b1ace5fd18/166624ccb533656d?lnk=st&q=naggum+tilton+idiot&rnum=8&hl=en#166624ccb533656d

I really can't understand why you waste so much of your time posting
crap on this group.

Mike

Ken Tilton

unread,
Dec 5, 2006, 8:19:19 PM12/5/06
to

Mike T wrote:
> Ken Tilton wrote:
>
>>This type of bullsh*t Usenet gotcha-play is exactly what gets you into
>>trouble on Usenet. I think you saw Garret doing it and decided it was a
>>good idea, probably why you both ended up on EN's sh*t list and mine.
>
>
> Actually Kenny out of all the regulars you seemed to be fairly highly
> ranked on Erik sh*t list. This is well documented using google groups
> search.

<sigh> I begin to understand why the Chinese built that wall.

Actually Mike T you have no clue what you are saying. That thread is a
fucking love fest between Erik and I who got along quite well on Usenet.

But never mind that, because if you think about it hard enough, what you
said, even were it true, is a complete non sequitor.

It's the fan mail from flounders like you.

kt

Mike T

unread,
Dec 5, 2006, 8:27:10 PM12/5/06
to
Ken Tilton wrote:
> [snipped]

>
> <sigh> I begin to understand why the Chinese built that wall.
>
> Actually Mike T you have no clue what you are saying. That thread is a
> fucking love fest between Erik and I who got along quite well on Usenet.
>
> But never mind that, because if you think about it hard enough, what you
> said, even were it true, is a complete non sequitor.
>
> >
> > Here's some reminders:
> > http://groups.google.co.uk/group/comp.lang.lisp/browse_frm/thread/707067b1ace5fd18/e15d85ac5626af9e?lnk=st&q=naggum+tilton+shit&rnum=1&hl=en#e15d85ac5626af9e
> >
> > http://groups.google.co.uk/group/comp.lang.lisp/browse_frm/thread/707067b1ace5fd18/166624ccb533656d?lnk=st&q=naggum+tilton+idiot&rnum=8&hl=en#166624ccb533656d
> >
> > I really can't understand why you waste so much of your time posting
> > crap on this group.
>
> It's the fan mail from flounders like you.

Well as Erik would say:

"What is your major malfunction, numbnut?"

http://groups.google.co.uk/group/comp.lang.lisp/browse_frm/thread/743a336328626e85/1ff27b241408bee9?lnk=st&q=tilton+naggum+newbies+floorboards&rnum=1&hl=en#1ff27b241408bee9

Best wishes

Ken Tilton

unread,
Dec 5, 2006, 9:15:33 PM12/5/06
to

Mike T wrote:
> Ken Tilton wrote:
>
>>[snipped]
>>
>><sigh> I begin to understand why the Chinese built that wall.
>>
>>Actually Mike T you have no clue what you are saying. That thread is a
>>fucking love fest between Erik and I who got along quite well on Usenet.
>>
>>But never mind that, because if you think about it hard enough, what you
>>said, even were it true, is a complete non sequitor.
>>
>>
>>>Here's some reminders:
>>>http://groups.google.co.uk/group/comp.lang.lisp/browse_frm/thread/707067b1ace5fd18/e15d85ac5626af9e?lnk=st&q=naggum+tilton+shit&rnum=1&hl=en#e15d85ac5626af9e
>>>
>>>http://groups.google.co.uk/group/comp.lang.lisp/browse_frm/thread/707067b1ace5fd18/166624ccb533656d?lnk=st&q=naggum+tilton+idiot&rnum=8&hl=en#166624ccb533656d
>>>
>>>I really can't understand why you waste so much of your time posting
>>>crap on this group.
>>
>>It's the fan mail from flounders like you.
>
>
> Well as Erik would say:
>
> "What is your major malfunction, numbnut?"

Jeez, Thompson, get the citation right, will ya?

http://www.moviesoundscentral.com/sounds/full_metal_jacket/numbnuts.wav

In your excitement over having been personally savaged by The Kenny, you
neglected to pick up my drift: that thread is a dialogue about
technology, with incidental mud-slinging to keep you lowbrows awake. It
stays on topic and never descends into the ad homineum mud your kind
finds so attractive. Even the dog crack was an echo of one I had made at
my own mistake.

You know, the last thing Erik said to me in our email exchanges (I'll
wait while you pick your sorry ass off the floor) was not to the sink to
the level of idiots like you. Right again, Erik.

<PLONK>

Ken Tilton

unread,
Dec 5, 2006, 9:23:24 PM12/5/06
to

No problemo. peace, out. k

Robert Maas, see http://tinyurl.com/uh3t

unread,
Dec 5, 2006, 9:55:40 PM12/5/06
to
> From: Ian Jackson <ijack...@chiark.greenend.org.uk>
> * Documentation for introducing Lisp to existing programmers is poor;
> existing tutorials are old or at least outdated.

IMO, tutorials should be "hands on", where the newcomer gets to
actually try stuff and see it work (or get explanations what's
wrong when it's not working). I.e. more than just a "tutorial",
more like a CAI (Computer-Assisted Instruction) class.

I would like to make such a super-tutorial myself, but I need a
guinea pig, somebody willing to try it as I work on it, and give me
prompt feedback how it's working. Do you know anyone willing to
give it a try?

> * Infrastructure for performing tasks which are routine in
> modern programming is often lacking and/or hard to find.

The software infrastructure is already there for a lot of common
tasks. For example, look at the chapters on hash tables, and
string/sequence operations. Serializing/deserializing is trivial
using print and read. Please list several examples of routine tasks
that Common Lisp does *not* include built-in, so that we can
address the specifics.

Sometime in the past few years I've seen mention of a "cookbook"
that somebody was going to compose. I looked at the proposed table
of contents and noticed that it skipped right past the really easy
stuff that stumps beginners, and I suggested those really easy
tasks be covered first.
(In fact I have suggested a universal "cookbook" be composed which
for each task shows how to do it in several different common
languages. So-far I've started work on that composition for a
single task: Decoding urlencoded HTML form contents for use in CGI
service applications.
<http://www.rawbw.com/~rem/HelloPlus/hellos.html#step3>
I wanted to move onward to a lot more common elementary tasks, but
nobody showed any interest in what I had already done so I haven't
done any more work on this project.)

> Q. Which development tools should I be using ?

Emacs is nice, but not necessary. I don't have any decent version
of Emacs here on my Macintosh, so I use McSink instead.

> Q. Which libraries should I definitely be looking at using, ...

What application areas do you have in mind? Distributed computing
using XML or s-expressions to pass data back and forth? Standalone
CGI applications? Heavy numerical calculations such as statistics?
Animated games? Deep board games such as Go?

> How do I turn my program into an executable ?

Why would you want to do that? That basically requires copying
large portions of the Lisp system into each copy of the compiled
program. Why not keep the Lisp software as FASLs and have just one
copy of the Lisp system plus a tiny script for each toplevel
application? Java basically does it that way, with a single jvm
that all applications require to run, instead of a separate copy of
the jvm in each application. If it's good enough for Java, why
isn't it good enough for Lisp?

> Q. How do I package my program in such a way that non-Lisp people
> will not be freaked out by the installation instructions ?

If you concentrate on writing CGI server applications, you never
have that problem. All the user needs is the URL of the startup
form for your application.

> When I first settled on learning CL I thought I would read a
> standard reference work. This is my usual way of approaching new
> programming languages - I'm one of the minority of people who find
> they get on very well with reference manuals, and find tutorials
> distressingly vague about details.

I wonder why you didn't consider a tutorial plus a real live system
to try things on? That why if the tutorial isn't clear, you'll find
it out quickly and have a chance to guess what they meant and try
that and finally understand what they really meant.

When you worked from a reference manual, did you have a real live
system to try things on??

> A Lisp-using friend lent me their copy of CLtL2, and I started

> reading through that. I quickly gave up because of Guy Steele's
> absurd habit of writing `and the thingum does the wossname to the
> doobry - no wait, it doesn't, in 1987 X3J13 voted that in fact the
> thingum does something completely different'.

Thanks for pointing this out. I learned CL back when CLtL1 was the
standard, and that one book was sufficient for my needs.
(Now I sometimes use the HyperSpec instead because it's right here
at my fingertips instead of across the room in a book.)

> My next approach was to try to read the Hyperspec through.

It's a good reference, if you already know enough to know what to
look for, but for an absolute beginner, ...

> I decided it would be better to pick some project and just write
> a program. ... Quickly, I encountered a suitable project: a non
> hideously broken ip-over-http implementation.

Let me see if I understand this correctly. You already have HTTP
over TCP over IP, and now you use CL to operate the HTTP/TCP/IP and
then emulate IP on top of all that, as some sort of demonstration?
May I respectifully submit that accessing HTTP/TCP/IP from CL is
not the ideal first project for learning a new language? You bit
off more than you could chew. Couldn't you think of a more modest
project as a first self-training task?

> First I thought I'd try starting my favourite lisp and playing
> with the REPL like many of the online tutorials suggest.

What, you hadn't *already* done that before embarking on your
IP-emulation/HTTP/TCP/IP project?? Walk before run!

> Several of the lisps I ended up trying didn't have command line
> editing by default ...

Does your computer support copy and paste between different
applications, so you could edit your source to your heart's content
in a text editor and then copy an entire s-expression from there to
the CL environment to see if it works as planned?

> I had to write a function to convert a string of bytes (as
> produced by cl-md5) to hex.

I presume you don't mean hex (base 6) but hexadecimal (base 16)?
Note that bytes are internal data, whereas hexadecimal is a print
notation used mostly for debugging. By "string" do you literally
mean string (the data type in CL) or simply unsigned-octet vector?
In either case, a function to convert the internal data into
hexadecimal debug format is trivial, so why are you complaining?
Did you want all the hexadecimal run together, or broken by
whitespace between adjacent bytes, or blocked in groups of 4 or 8
bytes with whitespace only between blocks, or lined up in tabular
form with low-order part of index along top and high-order part of
index along left?

> Newer (non-broken!) hash functions and so on don't seem to be
> available at all.

In general, when you're writing an application, you don't want a
"hash function", you want a hash table, with all the hash function
and collision resolution etc. hidden from you. All you care about
is that gethash, and the setf for it, both work correctly.
What exactly do you really need which is missing?

> ... I found that there wasn't even a standard function for
> splitting a string into substrings based on a delimiter !

In emacs lisp such a function *is* built-in because when writing
utilities for a text editor such a function is commonly used. But
why would you need that specific feature in any other context?
And if you do really need it, why is it so difficult for you
to write it yourself, using the built-in functions POSITION
and SUBSEQUENCE?

Regarding your tirade about Lisp not producing standard
executables, have you tried posting the same tirade to a Java
newsgroup where the same remarks apply? What response do you get
there when you say that Java feels like a 1960's timewarp?

By the way, Java applets don't work if they use any packages other
than java.lang. Not even java.util is available in most Web
browsers.

Frank Buss

unread,
Dec 6, 2006, 2:57:11 AM12/6/06
to
Alex Mizrahi wrote:

> (message (Hello 'Ian)
> (you :wrote :on '(05 Dec 2006 01:08:23 +0000 (GMT)))
> (
>
> IJ> Q. How do I turn my program into an executable ?
>
> there is no good and official way to make executable from Java or .net
> application, at same time Java is most popular language according to TIOBE,
> so i think it's not a case.

The official way is to make a JAR or use Java Webstart or a WAR for web
applications. The user has to install the official Sun implementation once
and then he/she can just double click every JAR file to start the
application or click on a link to install and start a Webstart application.

Some "unofficial" ways:

http://www.ej-technologies.com/products/exe4j/overview.html
http://www.excelsior-usa.com/jet.html

For Lisp:

CLISP: see ext:saveinitmem with :executable t and
http://www.frank-buss.de/lisp/clisp.html

SBCL: see sb-ext:save-lisp-and-die and :executable

LispWorks: see "deliver"

I assume most other Lisp implemenations have similiar features.

Like to JAR, but not as easy and platform independant: ASDF
Like to Webstart, but again not a single click: ASDF-Install

--
Frank Buss, f...@frank-buss.de
http://www.frank-buss.de, http://www.it4-systems.de

Pascal Bourguignon

unread,
Dec 6, 2006, 3:05:22 AM12/6/06
to
Ian Jackson <ijac...@chiark.greenend.org.uk> writes:
> [...]

> *People writing in Python or Perl or Ruby do not have to do research
> to choose between competing regexp libraries!*

So the problem would be that there are too many libraries, too many
implementations of CL and too many CL tutorials, too much choice.

If that was true:

1- it's too late the worms are out of the can. What do you suggest?
Erasing implementations and libraries?

2- I don't believe it's bad. Newbies have better come to term with
this life fact: we're not 6.5 billion clones, we're 6.5 billion
individuals.

3- there would also be too many scheme, ruby, python, perl tutorials:
google gives:

318,000 for "common lisp" tutorial.
1,280,000 for scheme tutorial.
1,810,000 for ruby tutorial.
6,940,000 for python tutorial.
12,100,000 for perl tutorial.

Clearly, Common Lisp is still the best choice here...


Perhaps you should choose LispWorks Common Lisp:

36 for "LispWorks Common Lisp" tutorial.


> To make CL attractive, it is essential that what other languages
> regard as trivial and obvious tasks are easily addressed without a
> great deal of background reading.

Once again, I notice that you have a business opportunity here. What
are you waiting to start working on it?


--
__Pascal Bourguignon__ http://www.informatimago.com/

IMPORTANT NOTICE TO PURCHASERS: The entire physical universe,
including this product, may one day collapse back into an
infinitesimally small space. Should another universe subsequently
re-emerge, the existence of this product in that universe cannot be
guaranteed.

Frank Buss

unread,
Dec 6, 2006, 3:42:07 AM12/6/06
to
Ian Jackson wrote:

> Naturally some of these problems can be addressed with wrapper scripts
> and a few extra tools. That's fine. But where is the standard
> facility for wrapper scripts, that I can put in a #! line ? Where are
> the standard facilities for building *portably-deployable* CL
> programs: by which I mean not `portable to a different Lisp' but
> `a whole distribution bundle which is portable to a computer which
> does not yet have a Lisp system' ? How do I integrate Lisp
> compilation into the build system of a large project using many
> languages and tools, all driven by something like make ?

This is one goal of the Common Lisp Application Builder project:

http://www.lispbuilder.org

Unfortunately I don't have much time at the moment for it, but some users
are very active enhancing it, particularly the SDL support. I have added
some other libraries for regular expressions, yacc- and AWK-emulation and
started a Microsoft Windows wrapper, which could become a general GUI
library.

For OpenGL I recommend cl-opengl: http://common-lisp.net/project/cl-opengl/

For web development I recommend TBNL:
http://weitz.de/tbnl/
http://www.frank-buss.de/lisp/tbnl.html
It provides many functions you need for web development and references some
useful other libraries, like HTML-TEMPLATE etc.

Would be nice to integrate some de facto standard web libraries into a
release of the Lispbuilder project. It could be integrated all into the
Lispbox project (http://www.gigamonkeys.com/lispbox/), but I don't like
Emacs, so a more newbie friendly IDE is required, like the Java Eclipse
IDE.

Stefan Kamphausen

unread,
Dec 6, 2006, 4:07:39 AM12/6/06
to
Hi,

Ian Jackson <ijac...@chiark.greenend.org.uk> writes:

> *People writing in Python or Perl or Ruby do not have to do research
> to choose between competing regexp libraries!*

this, I humbly think, is a wrong mindset: CL doesn't compete with
those scripting languages but more with C++ and Java. That makes all
the difference.

C++:
There is not built-in regexp engine in C++, the installation of the
runtime is a real pain (gcc and libc), library dependencies get in the
way all the time and there is no single lib for each single task. And
just because almost everybody uses GCC nowadays does not mean that
there are not other compilers out there (intel, ms, ...).
Ah, and try to have several versions of GCC and other C-compilers on
one system. Fun that is.

Java:
Things are slightly better here because the language ships with a huge
collection of standard libs and classes. But what about different
versions of java on one system, do your programs run on IBM Java as
well as Sun Java and compile with GJC? Gentoo just came up with a
mechanism to switch java versions on a per user basis whenever you
need to switch. Cross your fingers that you never need two programms
running at the same time using different versions. And when it comes
to things not in the language standard you're pretty hopelessly lost
in the internet because search machines can't help too much with a
language that is hype-oriented. You alway have to skim through
strategic, marketing and other buzz-word pages until you get to the
technical bottom.

CL:
Keep several binaries and core file wherever you want. Each package
of those two makes for a complete runtime. Keep listening to the
CL-senders (like this newsgroup) and you will get a picture of what
libraries to use.


Mind, though, that I agree with you that the beginners barriers are
big (I once wrote a small essay much like your rant here ;-). But
then, just keep hanging around, start a CL project every now and then
and you will pretty sure get into things. It's a different world and
it needs different thinking and that needs getting used to.


Kind Regards
Stefan

--
Stefan Kamphausen --- http://www.skamphausen.de
a blessed +42 regexp of confusion (weapon in hand)
You hit. The format string crumbles and turns to dust.

nha...@gmail.com

unread,
Dec 6, 2006, 5:02:03 AM12/6/06
to
Frank Buss wrote:

> For web development I recommend TBNL:
> http://weitz.de/tbnl/

TBNL is deprecated. Use Hunchentoot instead.

http://weitz.de/hunchentoot/

Cheers,
Edi.

Frank Buss

unread,
Dec 6, 2006, 5:53:59 AM12/6/06
to
nha...@gmail.com wrote:

> TBNL is deprecated. Use Hunchentoot instead.
>
> http://weitz.de/hunchentoot/

Thanks, I'll try it. And looks like you had some time to implement some
more interesting Lisp libraries and projects since I last visited your web
site. Do you plan to implement all additional standard libraries, which are
needed for a useful Lisp environment, by yourself? :-)

Ian Jackson

unread,
Dec 6, 2006, 6:32:05 AM12/6/06