Common Lisp from a Unix perspective - barriers to using CL
Ian Jackson
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
> 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
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
>
> * 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
> 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
> 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
> 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
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
<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
> >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
Pascal Bourguignon <p...@informatimago.com> wrote:
>Ian Jackson <ijac...@chiark.greenend.org.uk> writes:
>> 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
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
> 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
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
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
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
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
> 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
> 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
> 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
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
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
> 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
(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
(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
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
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
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
> 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
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
> Ian Jackson <ijac...@chiark.greenend.org.uk> wrote in
> news:Nje*+Ww...@news.chiark.greenend.org.uk:
>
>> 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
>> 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
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
> 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
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
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
OK, you're right. I apologize.
Pascal
Pedro Kröger
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
>
> 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
I really can't understand why you waste so much of your time posting
crap on this group.
Mike
Ken Tilton
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.
>
> 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.
kt
Mike T
> [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?"
Best wishes
Ken Tilton
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
No problemo. peace, out. k
Robert Maas, see http://tinyurl.com/uh3t
> * 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
> (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
> [...]
> *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
> 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
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
> For web development I recommend TBNL:
> http://weitz.de/tbnl/
TBNL is deprecated. Use Hunchentoot instead.
Cheers,
Edi.
Frank Buss
> 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
Alex Mizrahi <udod...@users.sourceforge.net> wrote:
> [Ian Jackson]:
> > 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.
>
>hell, no. i have a _lot_ of hassle installing Java -- the most
>language Common Lisp is competing. at same time, lisp installs
>surprisingly well.
You're right that Java has many of the same problems. Those problems
are daily cursed by programmers around the world whose idiot bosses
have mandated that they use Java, after having been told my Sun's
massive marketing campaign how wonderful it was. Common Lisp doesn't
have the doubtful benefit of a following amongst idiot bosses.
Ian Jackson
Stefan Kamphausen <ska...@gmx.de> wrote:
>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.
See my comments back ^ there about Java. C++ also has enormous hype
and momentum behind it. The people who are using it aren't doing so
because of how wonderful C++ is (after all, C++ is pretty awful), so
competing on wonderfulness is missing the point.
At least the scripting languages are still competing on their merits.
One reason they can do that is that it's a low time commitment to try
them out on small problems.
Ian Jackson
Pascal Bourguignon <p...@informatimago.com> wrote:
>Ian Jackson <ijac...@chiark.greenend.org.uk> writes:
>> 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.
In one sense, yes, but (obviously) I think the availability of
alternatives is a good thing. What is lacking is a clear consensus
that _these_ are the ones you probably want, whereas _those_
competitors are not quite there yet, or better for special purposes,
or what-have-you.
> 3- there would also be too many scheme, ruby, python, perl tutorials:
> google gives:
Reading a tutorial is not the same kind of commitment as building
reliance on a particularly library into a program.
>Once again, I notice that you have a business opportunity here. What
>are you waiting to start working on it?
I'm too busy fixing other parts of the world. Aren't we all ?
Ian Jackson
Robert Maas, see http://tinyurl.com/uh3t <rem...@Yahoo.Com> wrote:
>[stuff]
>
>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?
The best way to do this would probably be to find someone you know but
who doesn't already know lisp and watch them go through it. (If it
takes more than an hour or two then it's probably too long anyway.)
>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.
Indeed. This is quite a strange situation: some important facilities
which in other languages are found in obscure libraries, and which
hardly anyone uses, are standard in CL. But those facilities are
generally ones used when writing larger and more sophisticated
applications, and it is hard to get that far when writing a small
program shows up lack of standard facilities for operations people
nowadays think of as trivial.
> Please list several examples of routine tasks
>that Common Lisp does *not* include built-in, so that we can
>address the specifics.
The biggest class of these is textual string handling, and the next
biggest is Internet functionality. Most modern programming languages
have a huge array of facilities for doing useful things with strings
(regexp libraries, easy split and join, lexers and parser generators,
UTF-8, etc.) and nowadays you wouldn't like to choose a language which
couldn't at least (for example) do basic parsing of CGI form data,
make DNS lookups, read IP addresses from textial configuration files,
etc.
>(In fact I have suggested a universal "cookbook" be composed [...])
That sounds interesting to me (but I haven't followed your link ...)
>> 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?
No, the IP is feeding back into the operating system. (I already have
a suitable way to make pseudo network interfaces from user programs.)
It's an ip-over-braindamage protocol. Eg, some idiot hotel gives you
"internet access" which turns out to mean "web access" so you fill
their webcache with your encrypted packets. Not efficient or pretty
but it gets the job done.
>May I respectifully submit that accessing HTTP/TCP/IP from CL is
>not the ideal first project for learning a new language?
Actually, the portable allegroserve bit is one of the easier parts.
Extensible single-process webserver frameworks are rare enough that I
didn't have the difficulty of choosing between them. It was either
cl-aserve, or twisted, or some hideous nightmare with cooperating
processes and liberal use of fcntl F_GETLK.
> You bit off more than you could chew. Couldn't you think of a more
>modest project as a first self-training task?
This project ought to be modest. When I'm done it ought to be no more
than a few hundred lines at most.
>In either case, a function to convert the internal data into
>hexadecimal debug format is trivial, so why are you complaining?
Because it's tedious to be reimplementing trivial wheels all the time.
If my program has 100 lines of algorithm and needs two dozen trivial
but not suplied features, I end up with 100 lines of algorithm and 100
lines of trivial wheel-reimplementations. What a waste of effort!
OTOH at least reimplementing all of those wheels is good programming
practice, I suppose.
>> Newer (non-broken!) hash functions and so on don't seem to be
>> available at all.
...
>What exactly do you really need which is missing?
As it happens MD5 is sufficient for my needs, but what would be really
nice would be a ready-made HMAC-SHA256. Someone in another thread has
suggested cl-ironport which I would backport if MD5 wasn't good
enough.
>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?
Because the world nowadays uses strings, with particular common kinds
of structure, as interchange formats and protocol elements. Being
able to deal with those quickly and easily saves a lot of faff.
>[Java]
Java is terrible in so many different ways. Common Lisp advocates
should set their sights higher !
Ian Jackson
Ian Jackson <ijac...@chiark.greenend.org.uk> wrote:
>have mandated that they use Java, after having been told my Sun's
`by'. Oops, I didn't want to claim responsibility for that :-).
Bill Atkins
> string/sequence operations. Serializing/deserializing is trivial
> using print and read.
To be precise, printing and reading are trivial with print and read.
Serialization is a different ball game.
Holger Schauer
> Ian Jackson wrote:
>> * Support for Common Lisp development in Debian stable is
>> surprisingly poor, given how mature the Lisp world is.
> I can't comment on this.
I think I can. I agree with Ian. The basic problem is that as of
today, CL libraries and implementations are fast moving targets (wow,
I never would have believed that in the late 90s), while Debian stable
is -- per definiton -- stable. For instance, you don't really want to
try to use UCW on Debian Sarge. Over the last year, I've experienced
quite some hassle on Sarge, although (or perhaps because?) I'm using
backports.org. The latest installment of cmucl and
common-lisp-controller from bpo segfaults, for instance.
Holger
--
--- http://hillview.bugwriter.net/ ---
"Innenminister Schillstein hat gestern eine Anweisung erlassen, die
den Betrieb von Homefirewalls verbietet: `Die Umsetzung der europäischen
Brandschutzrichtlinie Nummer 1234 läßt uns keinen Spielraum: Die
Feuerwehr muß ständig Zugriff auf die Wohnungselektronik haben.'"
-- Uwe Ohse in de.alt.sysadmin.recovery
Pascal Costanza
> On 4843 September 1993, Pascal Costanza wrote:
>> Ian Jackson wrote:
>>> * Support for Common Lisp development in Debian stable is
>>> surprisingly poor, given how mature the Lisp world is.
>> I can't comment on this.
>
> I think I can. I agree with Ian. The basic problem is that as of
> today, CL libraries and implementations are fast moving targets (wow,
> I never would have believed that in the late 90s), while Debian stable
> is -- per definiton -- stable. For instance, you don't really want to
> try to use UCW on Debian Sarge. Over the last year, I've experienced
> quite some hassle on Sarge, although (or perhaps because?) I'm using
> backports.org. The latest installment of cmucl and
> common-lisp-controller from bpo segfaults, for instance.
But that sounds like a problem of Debian, not of Common Lisp, doesn't it?
Holger Schauer
> Holger Schauer wrote:
>> On 4843 September 1993, Pascal Costanza wrote:
>>> Ian Jackson wrote:
>>>> * Support for Common Lisp development in Debian stable is
>>>> surprisingly poor, given how mature the Lisp world is.
>>> I can't comment on this.
>> I think I can. I agree with Ian. The basic problem is that as of
>> today, CL libraries and implementations are fast moving targets (wow,
>> I never would have believed that in the late 90s), while Debian stable
> But that sounds like a problem of Debian, not of Common Lisp, doesn't it?
On first sight, yes, but not so on the second. One major
accomplishment of Debian is usually that shipped versions work and
typically that they're compatible with each other. But one of the
major problems with the current developments efforts is that often
enough APIs change. Over the last year, I think it happened to me
twice that I wanted to update some library or CL implementation, and
discovered that in order to run it, or better said, my applications on
top of it, I had to get the latest version of some other, totally
unrelated library, too. And then there are those packages which keep
their own version of some CL library that you might have already
installed in a different and incompatible version (UCW has some of
these, IIRC). As a result (of my manual repairs), my
/usr/share/common-lisp/ directory is currently such a mess that it
reminds me of students kitchens.
From what I've read and heard, the situation is likely to get better
with Etch (more libraries, more up-to-date), as I know that there are
some people working on improving the situation. We'll see.
Robert Uhl
>
>>> * Documentation for introducing Lisp to existing programmers is poor;
>>> existing tutorials are old or at least outdated.
>>
>>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.
Well, I managed to read it in a day or two--but I'm a quick reader.
Common Lisp is a _very_ different language from the usual ones (as I'm
sure you've realised); I'm not certain that an abbreviated guide is
particularly useful.
An advantage of PCL is that one can skip over the obvious parts
(e.g. the explanations of what lists are).
>>> * 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.
Well, as I noted Dr. Edi Weitz's stuff is
excellent--<http://www.weitz.de/> has a nice long list. And of course
then there's CLiki and the Common Lisp Directory and a few others.
Have you played with CLSQL? It's really very cool. Webactions and
PortableAllegroServe are also quite good.
> 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.
I agree--Python's a very useful little language; it's my typical tool at
work simply because it has a nice standard library (one which improves
every release, even). I can get the job done in a reasonably nice
language, although I keep on thinking how much easier expressing the
algorithms would be using Lisp--but then I remember how much more
difficult everything else would be, since there's no Lisp Django and so
forth.
> 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 ?
Feel free.
>>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 :-).
That's changing, of course. I don't know that any Lisp will ever be
suitable for shell scripting, but at least it's now quite possible to
create executables and so forth.
--
Robert Uhl <http://public.xdi.org/=ruhl>
Thanks to the joint efforts of OpenOffice, Mozilla, and a few others, Emacs
officially entered the category of lightweight utilities. --kalifa on /.
Robert Uhl
>
> 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!*
Well, they get one by default. No doubt there are others available if
they really wanted them.
>>> 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 ?
It's true, though. There's just no reason to use vi for
programming--and I know, for I was a vi-user for a long time. Using vi
to program is like writing a word processor for Windows in octal:
possible but severely unpleasant.
That said, I'm told that there are many vim-using Lispers out there; a
quick googling reveals several pertinent documents.
> If you want CL to become more popular you will have to accomodate and
> satisfy the expectations of people from outside the Lisp world.
The problem is that there are very few people invested in the success of
Lisp-the-language. There are folks invested in the success of SBCL or
Allegro or LispWorks; there are folks invested in the success of
CL-PPCRE (which is, incidentally, the regexp library to use); but who is
invested in the success of Lisp-the-language? The closest I can come up
with is Kent Pitman, but he apparently doesn't want Lisp to succeed
enough to embrace free implementations thereof.
The Benevolent-Dictator-for-Life model has several advantages; among
them is that he really, _really_ wants his project to succeed, so he
tries to come up with an attractive offering. Perl was attractive in
its time (as was Cybil Shepherd; like Miss Shepherd, it's not aged
gracefully); Python is an attractive platform; Ruby is an attractive
platform. Common Lisp is an attractive language, but the platform is
essentially nonexistent.
--
Robert Uhl <http://public.xdi.org/=ruhl>
From my cold dead hands, my ass. I'll be taking their issue weapons
from their cold dead hands. I fight to win. --KBarrett
Robert Uhl
>
>> *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.
It's not so much that there's a choice--it's that there are no
defaults. E.g., if every implementation had CL-PPCRE you'd be free to
download some other regexp library, but every tutorial could rely on you
have CL-PPCRE, and 11/12ths of programmers would never worry about it.
Imagine in CL if you had to write (+ 1 2 :base 10 :rollover nil :type
(list integer integer)) every time... Better to provide some sane
defaults and not worry about it.
And yes, I realise that tacking a base argument on #'+ is nonsensical in
this case because by the time #'+ sees its arguments they've been read
and are just numbers. It's an example, that's all.
--
Robert Uhl <http://public.xdi.org/=ruhl>
If your adversary is badly bunkered, there is no rule against your
standing over him and counting his strokes aloud, but it will be a wise
precaution to arm yourself with the niblick before doing so, so as to
meet him on equal terms. --Horace G. Hutchinson, 1886
Robert Uhl
>
> 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.
What's wrong with bolting together libraries? Sure, it's not creating,
but it's a useful activity. Not all are called to be library-writers;
not all are called to be library-users.
--
Robert Uhl <http://public.xdi.org/=ruhl>
One interesting feature of Latin is that you ROT13 it and get Welsh. --Peter
Ken Tilton
Robert Uhl wrote:
> Ken Tilton <kent...@gmail.com> writes:
>
>>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.
>
>
> What's wrong with bolting together libraries? Sure, it's not creating,
> but it's a useful activity. Not all are called to be library-writers;
> not all are called to be library-users.
>
Admit it. You guys are deliberately completely misparsing natural
language just to see my funny comebacks.
:)
Can somebody help Robert?
kzo
Ivan Boldyrev
> ... Complex and difficult problems are usually best solved with a
> mixture of tools and approaches.
Lisp *is* a mixture of tools and approaches :)
--
Ivan Boldyrev
Violets are red
Roses are blue
It's amazing what DNA splicing can do.
Richard M Kreuter
> On 4844 September 1993, Pascal Costanza wrote:
>> But that sounds like a problem of Debian, not of Common Lisp,
>> doesn't it?
>
> On first sight, yes, but not so on the second. One major
> accomplishment of Debian is usually that shipped versions work and
> typically that they're compatible with each other...
I've used Debian stable for years, and while it is a nice platform in
many ways, I always find myself needing to go outside the system for
various things: PostgreSQL, Emacs or Emacs addons, Firefox, CPAN
modules. Folks I know do or have done the same for Python versions,
desktops, X-Windows implementations. There's really nothing
Lisp-specific about the situation.
--
RmK
sailor...@gmail.com
Stefan Kamphausen 寫道：
> Hi,
> 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.
Excuse me but I can't understand these words.
What does it by "Keep several binaries and core file wherever you
want"?
and "Each package of those two makes for a complete runtime"...
I am not familiar with the CL runtime enviroment...
Can you detail them? Thanks
Tim X
Debian stable is, well, extremely stable, but due to the slow release
cycle Debian has had, the stable disribution does tend to lag a bit
behind.
However, having said that, I've been running Debian testing for about
6 years and have rarely had any problems at all - minor glitches from
time to time that are usually resolved quite quickly and never
anything which has prevented me from working. for the past couple of
years, I've been running a hybrid testing/unstable distribution. The
Debian packaging system handles this very nicely. Essentially, you
can add the unstable source location to your configuration and if yo
install a package from unstable, Debian will continue to offer you
updates for that package form the unstable branch, but everything
else is from testing (unless the unstable package you have installed
depends on other packages in unstable).
I've done this so that I can get the emacs 22 snapshot from unstable
and run the latest slime. All works really well.
Tim
--
tcross (at) rapttech dot com dot au
Holger Schauer
> Holger Schauer <Holger....@gmx.de> writes:
>> On 4844 September 1993, Pascal Costanza wrote:
>>> But that sounds like a problem of Debian, not of Common Lisp,
>>> doesn't it?
>> On first sight, yes, but not so on the second. One major
>> accomplishment of Debian is usually that shipped versions work and
>> typically that they're compatible with each other...
> I've used Debian stable for years, [...]
So do I.
> and while it is a nice platform in many ways, I always find myself
> needing to go outside the system for various things: PostgreSQL,
> Emacs or Emacs addons, Firefox, CPAN modules. Folks I know do or
> have done the same for Python versions, desktops, X-Windows
> implementations. There's really nothing Lisp-specific about the
> situation.
I use backports also for Firefox, PostgreSQL and compile XEmacs
entirely on my own, so, yes, in some respect this is true. This is,
however, for a totally different reason, e.g., if I install Firefox
from bpo, this is not because of some incompatible library versions
that force me to update seemingly unrelated software. But if you want
to use a modern lisp library, e.g. UCW, it might well be that sbcl in
stable is just too old. And with UCW being rather heavy under
development, it might well be, that in half a year, you'll be
recompiling sbcl again. I.e,, what I see as Lisp-specific is the
inmaturity of some of the newer software which increases the
problem[1] that Debian stable is never bleeding edge. I agree that
e.g. Gnome users have suffered similar problems in the past, however,
there situation has improved a lot, because the foundation (i.e. gtk-
and gnome-libraries and infrastructure) is now much more mature and
contained in reasonable recent versions in stable. That's what I meant
when I said that the situation is going to improve (wrt. the Lisp
libraries) with Etch.
Holger
Footnotes:
[1] Actually, I don't think that stable has a problem. It does what
it is designed to. If that's not what you want, then there are several
alternatives to choose from. And with Ubuntu, you can have a 'stable'
version of a dpkg/apt-based Linux distribution twice a year.
Stefan Kamphausen
"sailor...@gmail.com" <sailor...@gmail.com> writes:
A runtime is what you need to run your program.
Well your Java runtime comprises the java binary and loads of
jar-files which contain all the standard classes. The C/C++ runtime
comprises at least the lib and several other libraries. For a
compiler you also need GCC.
When in the lisp world you just take a binary (e.g. "lisp" for CMUCL,
or "sbcl" for SBCL) and one core file (/usr/lib/cmucl/lisp.core, or
/usr/lib/sbcl/sbcl.core or (and this is interesting) any other core
file you created with all your lisp libraries loaded), tell the binary
which core file to use (lisp -core corefile, sbcl --core corefile) and
there you are. Runtime plus compiler at hand.
Does that help?
Rob Warnock
+---------------
| I don't know that any Lisp will ever be suitable for shell scripting...
+---------------
Hunh?!? I use CMUCL for "shell scripting" all the time!!!
$ file ~/bin/* | grep -i cmucl | wc -l
41
$
And many other people use CLISP and other implementations for
similar things. [I even have a half-dozen CLISP scripts myself.]
-Rob
-----
Rob Warnock <rp...@rpw3.org>
627 26th Avenue <URL:http://rpw3.org/>
San Mateo, CA 94403 (650)572-2607
grackle
> 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.
Kenny, I don't see any licensing information on the Verrazano page or
in the project proposal. What license is the code distributed under?
-David Huebel
Alain Picard
> limitation (even very advanced stuff). If you ever 1) get to the
> point where you have (more or less) mastered CL and 2) want to use it
> for a large industrial strength application, you can then revisit
> whether or not it makes sense to buy the package or start hacking at
> making some of the "free" junk "work".
How fantastically obnoxious.
Here is a guy showing up, with 25 years of programming experience
under his belt. He's done serious, important work for the Debian
project. And you turn around and derogatorily refer to free software
as free "junk", and imply that it barely "works".
Are you listening to yourself? Do you know how you come across?
Ian -- don't give up on CL. The language, and pretty much all of
the implementations you'll lie your hands on, are of far greater
quality than most of the "responses" you've received in this forum
so far. I welcome you as a new CL hacker, and hope you will raise
the average tone of this newsgroup! [Come to think of it -- scratch
that -- you already have!]
Alain Picard
Ken Tilton
Wow, you are right, I do not see anything anywhere. The Google Summer of
Code requirements were that the project be open source, but several such
licenses were acceptable.
Rayiner seems to have moved on from vzn, but we could try asking him to
add a license and pass along the c-l.net admin privs. c-l.net also has
an open source requirement, maybe they have some documentation.
Rayiner seems to be active on gmane.comp.lang.dylan.gwydion.devel as of
last month. Anyone interested in picking up vzn could try emailing him,
or I could. I have tried in the past, but not at the email address I see
on gmane.
ken
Ken Tilton
Alain Picard wrote:
> jayessay <nos...@foo.com> writes:
>
>
>>limitation (even very advanced stuff). If you ever 1) get to the
>>point where you have (more or less) mastered CL and 2) want to use it
>>for a large industrial strength application, you can then revisit
>>whether or not it makes sense to buy the package or start hacking at
>>making some of the "free" junk "work".
>
>
> How fantastically obnoxious.
>
> Here is a guy showing up, with 25 years of programming experience
> under his belt. He's done serious, important work for the Debian
> project. And you turn around and derogatorily refer to free software
> as free "junk", and imply that it barely "works".
>
> Are you listening to yourself? Do you know how you come across?
Like me? :)
>
>
> Ian -- don't give up on CL. The language, and pretty much all of
> the implementations you'll lie your hands on, are of far greater
> quality than most of the "responses" you've received in this forum
> so far. I welcome you as a new CL hacker, and hope you will raise
> the average tone of this newsgroup! [Come to think of it -- scratch
> that -- you already have!]
Lawdy, what is this, the Second Coming? If the guy is any good, HTH can
he pass on CL? After all, he has already gotten over the hard part,
getting the free junk to work. :)
Me, I saw the comment about it being unlikely anyone would ever want to
use a book to explore a new language and, unable to think of any
language I explored /without/ using a book, I started thinking "troll".
:)
grackle
> Rayiner seems to have moved on from vzn, but we could try asking him to
> add a license and pass along the c-l.net admin privs. c-l.net also has
> an open source requirement, maybe they have some documentation.
Please do ask him to attach a license. If the license allows
distribution of closed-source commercial apps built with Verrazano, I
will be interested in using it and doing whatever work is necessary to
enable my use of it. (Geez, I sound like such a Scrooge, but that's
the truth :-(
-David
Ken Tilton
grackle wrote:
> Ken Tilton wrote:
>
>>Rayiner seems to have moved on from vzn, but we could try asking him to
>>add a license and pass along the c-l.net admin privs. c-l.net also has
>>an open source requirement, maybe they have some documentation.
>
>
> Please do ask him to attach a license. If the license allows
> distribution of closed-source commercial apps built with Verrazano, I
> will be interested in using it and doing whatever work is necessary to
> enable my use of it.
I cc'ed you on the email. If we do not hear back, we can try Google and
c-l.net to see if they have any correspondence. If all else fails...
While working on my Antlr-based C-to-lisp translator it occurred to me
that I could easily use it to produce some pretty sweet bindings,
including even noticing how pointers were used (null terminated string?
secondary return values?) by looking inside the API function to see what
it did with a parameter. I'd give that code up for a virtual beer. :)
Stefan Scholl
> * Documentation for introducing Lisp to existing programmers is poor;
> existing tutorials are old or at least outdated.
Nope. The poor old documentation (or link lists) has a higher
PageRank(tm) than the good/great new documentation. So Google
will show you the bottom first.
That's a real problem.
Pascal Bourguignon
Well, google is not programmed in lisp, what can we hope?
--
__Pascal Bourguignon__ http://www.informatimago.com/
NEW GRAND UNIFIED THEORY DISCLAIMER: The manufacturer may
technically be entitled to claim that this product is
ten-dimensional. However, the consumer is reminded that this
confers no legal rights above and beyond those applicable to
three-dimensional objects, since the seven new dimensions are
"rolled up" into such a small "area" that they cannot be
detected.
oo...@rocketage.org
Pedro Kröger 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.
Excuse me for just jumping in, but I feel these are really good points.
I read the Paul Graham stuff as well and got all fired up about the
Lisp thing... However, I found it really hard to get anywhere with the
"standard" documentation -- and I read a lot of it. I tried several
Lisps, all considered reasonable implementations of Common Lisp. All
very hard to deal with. And trying to learn the language from the
HyperSpec? I stand in awe of Mr. Jackson's patience. It must surely be
that of a saint.
I'm not totally new to the programming thing -- I've written
interesting programs in various languages, embedded systems to
"enterprise", however, I couldn't get anywhere with common Lisp beyond
a few parlour tricks. I once wrote a CGI program in it for listing
directories for clients to download their files from our web server...
That was certainly an inglorious two pages of code. Certainly no fault
of the language, but every fault of my not being able to get a good
grip on the language.
Then (cue Holy Light and Angelic Chorus), I discovered NewLisp. Yes, I
know it doesn't have whossname variables or do untactic declosures in
the canonical form. However... And this is a *biggie*, it works almost
seamlessly on all major platforms and it has Human Readable
Documentation (tm). The documentation is what I'm here to tell you
about.
The NewLisp documentation is complete (every function, every
variation), reasonably organized, easy to get a handle on, and INCLUDES
A WORKED OUT EXAMPLE FOR EVERYTHING! Yes, that one thing (in the
screaming caps) has done wonders for my comprehension and appreciation
of Lisp. Whatever you may think about Mr. Mueller's implementation, it
is a *useable* implementation because he (or whoever) thought to
include those examples. Then, he took a good thing and made it even
better with his "Code Patterns" document, which shows the NewLisp-y way
to approach lots of common problems.
If you could provide a Common Lisp version of that one document ("Code
Patterns") and point all newcomers to it you would be doing future
newbies a great service. It's not necessary to appreciate or understand
*all* the clever ways to do something when you're starting, just *a*
way! The cleverness will come later when the learner has aquired
confidence in both the language and his/her ability to use it to solve
relevant problems.
Thank you for your time.
sross
Bill Atkins
Raffael Cavallaro
> Excuse me for just jumping in, but I feel these are really good points.
> I read the Paul Graham stuff as well and got all fired up about the
> Lisp thing... However, I found it really hard to get anywhere with the
> "standard" documentation -- and I read a lot of it. I tried several
> Lisps, all considered reasonable implementations of Common Lisp. All
> very hard to deal with. And trying to learn the language from the
> HyperSpec? I stand in awe of Mr. Jackson's patience. It must surely be
> that of a saint.
Let me put in my 2 cents, if anybody cares to listen - I don't even
know if Ian Jackson is still reading.
My impression of why learning lisp can be so difficult even for
experienced programmers coming from perl/c/python/java/etc.- I went
through a similar process - is that they try to apply the same model
they have sucessully used for each new language:
1. Download the best/standard/ *free* version of the language
2. Download a brief tutorial
3. profit !!! ;^)
Unfortunately:
1. the best free versions of common lisp are not the best environments
for *learning* common lisp.
2. the best brief online tutorials out there are not the best
documentation for *learning* common lisp.
The best environments for learning common lisp are the free trial
versions of the commercial implementations - LispWorks, MCL, Allegro
Common Lisp, Corman Common Lisp. I personally would choose LispWorks if
you're on the Mac, and either LispWorks or Corman if you're on Windows.
I'll let linux users say which free trial edition is the easiest to
work with on various linux distros.
The best documentation for learning common lisp is the freely available
Practical Common Lisp by Peter Siebel (which you should probably just
buy at some point since you'll want a dead tree copy anyway) available
at http://www.gigamonkeys.com/book.
If you're an experienced programmer and you do these things - download
the free trial of LispWorks, download PCL, and follow allong with PCL
in LispWorks a couple of hours a day, you'll be up to usable speed in
lisp in a few weeks at most. Of course fully *mastering* the language
will take significantly longer, but this is true of any powerful
language.
good luck,
Ralph
mi...@evins.net
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.
Welcome to Lisp, and to the unique world that is comp.lang.lisp. Since
you are reporting some difficulties, you may reliably expect to be
insulted. It just seems to be a feature of comp.lang.lisp.
Starting out learning common lisp is not particularly easy as compared
to lots of other languages. As you discovered, there is a bunch of
stuff (documentation and implementations) available, and for the
newcomer there is no very obvious starting point. Probably the easiest
place to start is with either Franz's Allegro Common Lisp or Lispworks,
from the company also called Lispworks. Both provide free versions of
their commercial software, complete with helpful documentation.
A good way to start learning Common Lisp is to read Peter Seibel's book
_Practical Common Lisp_ together with LispBox, a turnkey common lisp +
emacs package designed to be easy to use in combination with that book,
and also maintained by its author.
The free Lisps and tools are good, but require more tinkering, and
probably some help from more experienced users. You can get help from
comp.lang.lisp, but, its culture being what it is, you will be made to
pay for the help by taking abuse. (Over twenty years of writing
commercial software in Common Lisp, I've seen this phenomenon in more
than one place, as if the population of Lisp programmers were a giant
"I'm smarter than you" club; but, thankfully, I've also run into
pockets of very smart Lispers that are free of this nonsense.)
These answers have been the same for a little while now. I don't know
what would be the best way to make the easiest solutions for newcomers
more obvious. A significant issue is that there is a lot of recent
development in Lisp, while at the same time there are decades of legacy
as well. By the time many programmers have figured out how to use Lisp
productively, they seem to have lost any interest they might have had
in making it easier for other newcomers. There are exceptions -- see
the aforementioned _Practical Common Lisp_ and Lispbox, for example --
but even when there are easier starting approaches, they seem to get
lost amongst the plethora of other, less easy, alternatives, which
exist in part because Lisp has been around for so long.
When I started learning Lisp 20 years ago I was lucky in that an easy,
accessible implementation fell into my lap, and it was packaged very
conveniently for my chosen platform (Coral Common Lisp on Macintosh).
The situation is more complicated and less clear-cut than that for
people starting to learn Lisp these days.
A reasonable solution, if you end up really loving Lisp, as some people
do, might be to create a project (or a business!) expanding on the
Lispbox idea -- packaging a Lisp with some tutorial materials and
promoting it to newcomers. Or, if you decided you wanted to address any
deficiencies you find in Lispbox, I'll bet Peter would welcome help
with it.
Once again, welcome to Lisp, and my condolences on the reception your
post is bound to receive.
Robert Uhl
>
> Robert Uhl <eadm...@NOSPAMgmail.com> wrote:
> +---------------
> | I don't know that any Lisp will ever be suitable for shell scripting...
> +---------------
>
> Hunh?!? I use CMUCL for "shell scripting" all the time!!!
You don't find the start-up times a pain?
At least in SBCL, stuff like capturing stdin & stdout is more of a pain
than in a simple shell, perl or python script.
--
Robert Uhl <http://public.xdi.org/=ruhl>
Sometimes, I think the French were put on earth for no other reason than
to give Germany an over-inflated sense of their military prowess. Other
times, I can't come up with any reason at all. --Burt Prelutsky
Petter Gustad
> rp...@rpw3.org (Rob Warnock) writes:
> >
> > Robert Uhl <eadm...@NOSPAMgmail.com> wrote:
> > +---------------
> > | I don't know that any Lisp will ever be suitable for shell scripting...
> > +---------------
> >
> > Hunh?!? I use CMUCL for "shell scripting" all the time!!!
>
> You don't find the start-up times a pain?
time lisp -quiet -core script.core -eval '(script)'
this could be my script, args are (#<Command Line Switch "quiet">
#<Command Line Switch "core" -- ("script.core")>
#<Command Line Switch "eval" -- ("(script)")>)
real 0m0.033s
user 0m0.020s
sys 0m0.010s
time python script.py
this could be my script
real 0m0.039s
user 0m0.020s
sys 0m0.020s
Petter
--
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
A: Top-posting.
Q: What is the most annoying thing on usenet and in e-mail?
Rob Warnock
+---------------
| rp...@rpw3.org (Rob Warnock) writes:
| > Robert Uhl <eadm...@NOSPAMgmail.com> wrote:
| > +---------------
| > | I don't know that any Lisp will ever be suitable for shell scripting...
| > +---------------
| >
| > Hunh?!? I use CMUCL for "shell scripting" all the time!!!
|
| You don't find the start-up times a pain?
Not at all. Remember, unlike SBCL, CMUCL still contains a full
interpreter which is quite fast at running simple code. Also, almost
all modern operating systems do a *very* good job of caching the
CMUCL executable & image files [which are mmap()'d COW at startup],
so that repeated execution is *fast*! -- in the range of 20 ms
(that's "milliseconds"!) on all the machines I usually run on.
Times for CLISP are similar.[1] They're even usable for low-volume
CGI scripting! ;-}
+---------------
| At least in SBCL, stuff like capturing stdin & stdout is more
| of a pain than in a simple shell, perl or python script.
+---------------
I don't understand. I use CMUCL scripts in pipes all the time, e.g.:
$ cat ./powers
#!/usr/local/bin/cmucl -script
(unless (= 1 (length *script-args*))
(format *error-output* "usage: ~a #powers~%" *script-name*)
(unix:unix-exit 1))
(let ((npowers (read-from-string (first *script-args*))))
(loop for line = (read-line nil nil nil)
while line do
(let ((n (read-from-string line)))
(format t "~s~{ ~s~}~%" n (loop for p from 2 to npowers
collect (expt n p))))))
$ for i in 2 3 5 10; do echo $i; done | ./powers 5
2 4 8 16 32
3 9 27 81 243
5 25 125 625 3125
10 100 1000 10000 100000
$ for i in 2 3 5 10; do echo $i; done | ./powers 5 | cut -d' ' -f3-
8 16 32
27 81 243
125 625 3125
1000 10000 100000
$
Almost exactly the same code [though with differences on the "#!" line
and in how you do an "exit 1"] should work on SBCL or CLISP or indeed
most CLs.
-Rob
[1] Actually, my measurements some time ago indicated that CMUCL's
startup is actually *slightly* faster than CLISP's [despite CMUCL's
greatly larger memory footprint]:
$ cat ./test3c.lisp
#!/usr/local/bin/clisp -q
(format t "hello world!~%")
$ time-hist ./test3c.lisp
Timing 100 runs of: ./test3c.lisp
4 0.019
26 0.020
70 0.021
$
versus:
$ cat ./test3a.lisp
#!/usr/local/bin/cmucl -script
(format t "hello world!~%")
$ time-hist ./test3a.lisp
Timing 100 runs of: ./test3a.lisp
66 0.016
34 0.017
$
[The "-script" switch for CMUCL is a local hack to "site-init.lisp"
that I've been intending to publish for several years. My bad.
Soon, soon...]
Don Geddis
> [The "-script" switch for CMUCL is a local hack to "site-init.lisp"
> that I've been intending to publish for several years. My bad.
> Soon, soon...]
Now that looks awesome, and quite useful.
Besides just publishing it, could it be added to the main branch of the
CMUCL code?
-- Don
_______________________________________________________________________________
Don Geddis http://don.geddis.org/ d...@geddis.org
Sheep haiku:
sheepskin seatcovers / winter warm and summer cool / little lambs no more
Chris Barts
>
> The best environments for learning common lisp are the free trial
> versions of the commercial implementations
Name one advantage the trial versions have over the Free implementations
that is relevant to learning the language.
--
My address happens to be com (dot) gmail (at) usenet (plus) chbarts,
wardsback and translated.
It's in my header if you need a spoiler.
----== Posted via Newsfeeds.Com - Unlimited-Unrestricted-Secure Usenet News==----
http://www.newsfeeds.com The #1 Newsgroup Service in the World! 120,000+ Newsgroups
----= East and West-Coast Server Farms - Total Privacy via Encryption =----
jayessay
> On Mon, 11 Dec 2006 00:47:47 -0500, Raffael Cavallaro wrote:
>
> >
> > The best environments for learning common lisp are the free trial
> > versions of the commercial implementations
>
> Name one advantage the trial versions have over the Free implementations
> that is relevant to learning the language.
One "click" out of the box usability with everything available. A
_huge_ advantage for "just" learning.
/Jon
--
'j' - a n t h o n y at romeo/charley/november com
Pascal Costanza
> On Mon, 11 Dec 2006 00:47:47 -0500, Raffael Cavallaro wrote:
>
>> The best environments for learning common lisp are the free trial
>> versions of the commercial implementations
>
> Name one advantage the trial versions have over the Free implementations
> that is relevant to learning the language.
The fact that they come with development environments which to a certain
degree behave like those for other languages can be an advantage for
some. Not everyone wants to learn Lisp and Emacs at the same time. ;)
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/
niko...@random-state.net
> Chris Barts wrote:
> > Name one advantage the trial versions have over the Free implementations
> > that is relevant to learning the language.
> The fact that they come with development environments which to a certain
> degree behave like those for other languages can be an advantage for
> some. Not everyone wants to learn Lisp and Emacs at the same time. ;)
True. The opposite is true for those people already using Emacs, which
is not exactly a small percentage of programmers... ;-)
Cheers,
-- Nikodemus
Ian Jackson
Raffael Cavallaro <raffaelcavallaro@pas-d'espam-s'il-vous-plait-mac.com> wrote:
>Let me put in my 2 cents, if anybody cares to listen - I don't even
>know if Ian Jackson is still reading.
Yes, I am ...
>Unfortunately:
>
>1. the best free versions of common lisp are not the best environments
>for *learning* common lisp.
Well, personally I'm not prepared to commit to a programming language
(or even a significant library) which is not Free Software. Obviously
this is a political rather than a technical criterion, and people may
disagree.
>The best documentation for learning common lisp is the freely available
>Practical Common Lisp by Peter Siebel [...]
I think the problem here isn't that it's not free (or not Free), but
that it's not brief.
--
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
Ken Tilton
Something like ACL offers* the kind of IDE noobs would expect (and Emacs
mode!) and easy install and a better project manager than ASDF and lotsa
tools right off the shelf and graphical inspectors and..
ken
* on win32 and *nix.
Richard M Kreuter
> In article <2006121100474716807-raffaelcavallaro@pasdespamsilvousplaitmaccom>,
> Raffael Cavallaro <raffaelcavallaro@pas-d'espam-s'il-vous-plait-mac.com> wrote:
>
>> The best documentation for learning common lisp is the freely
>> available Practical Common Lisp by Peter Siebel [...]
>
> I think the problem here isn't that it's not free (or not Free), but
> that it's not brief.
You keep repeating this point about the length of a tutorial, so it
must be important to you. Can you offer an upper bound on the length
(in printed pages, say) of document that you would have found
acceptable?
--
RmK
joseph...@gmail.com
> >Unfortunately:
> >
> >1. the best free versions of common lisp are not the best environments
> >for *learning* common lisp.
>
> Well, personally I'm not prepared to commit to a programming language
> (or even a significant library) which is not Free Software. Obviously
> this is a political rather than a technical criterion, and people may
> disagree.
To contradict an earlier statement about the c.l.l "community", this
kind of stubborn grasp on preconceived notions held by novices is what
most raises hackles on c.l.l, not that fact that you might have honest
difficulties.
The fact that you expect Lispers to have presented you with a "language
that is Free Software"---putting aside that a language is not software,
but an abstraction with *implementations* that are software, and that
Lisp far predates RMS's manifesto---is a problem with your
expectations, not with Lisp. And, after all, there are multiple Free
implementations of Common Lisp, and quite good ones.
The only way such admittedly political principles could present a
practical obstacle to learning the language is if you decide to let
them.
If you decide your political posturing should be allowed to impede your
intellectual growth, that is your problem, not ours, and forgive us for
not pitying the situation in which you have placed yourself.
Bill Atkins
> Not at all. Remember, unlike SBCL, CMUCL still contains a full
> interpreter which is quite fast at running simple code. Also, almost
I'm pretty sure the latest releases of SBCL have an interpreter again.
Bill Atkins
> On Mon, 11 Dec 2006 00:47:47 -0500, Raffael Cavallaro wrote:
>
>>
>> The best environments for learning common lisp are the free trial
>> versions of the commercial implementations
>
> Name one advantage the trial versions have over the Free implementations
> that is relevant to learning the language.
Why so confrontational?
The free implementations require zero configuration and the LispWorks
IDE is way more mature and featureful than SLIME (graphical
inspectors, class browser, system browser, an extensible editor in
Common Lisp). You also get a full GUI toolkit that you can play
around with. I am sure the other commercial implementations are
comparable, although I have less experience with them.
"Commercial" does not imply "bad." If you've got a problem with
commercial software, you can always pick up the basics in a commerical
Lisp and then set up the free "equivalents" when you're more familiar
with Lisp.
Ken Tilton
Bill Atkins wrote (ironically):
> "Commercial" does not imply "bad."
Hey! Reread your Stallman:
"I consider that the golden rule requires that if I like a program I
must share it with other people who like it. Software sellers want to
divide the users and conquer them, making each..." Evil software
resellers, you!.
Would the "oh, RMS never said that" crowd please now summon up the
slimmest shred of intellectual honesty and post for everyone to see,
"Oh. Sh*t. You are right."?
.
.
.
.
.
.
.
.
.
I did not think so. Why not, given the facts?
Easy. Free software has become a cult.
Every time I say this on this august forum replete with the best of the
best, the yobbos descend on me like so many barbara schwarziand
scientology pit bulls, so wrought in their internal frency they do not
notice they are proving my point. Smart folks, btw, would notice and
adjust their spin. Not the FSF yobbos, leaving open the question...
exactly how smart are they? Maybe not as such as I guessed.
kt
John Thingstad
There was a reply to that effect a couple of weeks ago.
But as I understand it isn't enabled by default.
--
Using Opera's revolutionary e-mail client: http://www.opera.com/mail/