Getting started with Lisp?

loca...@example.org

unread,

Mar 10, 2011, 6:47:51 AM3/10/11

to

Hi guys! Last time I looked at Lisp was mumble years ago. Looks like alot
has changed. I see there are numerous implementations of common Lisp and
there is Scheme and probably tons of other variations I haven't heard of. Is
there any place I could read about what all these languages and
implementations are all about and how to choose one to get started with?
Honestly I'm not sure what I would use it for but I seem to be attracted to
unusual programming languages. I believe thinking outside the box makes you
a better programmer. I am using Linux if that matters.

Teemu Likonen

unread,

Mar 10, 2011, 8:47:28 AM3/10/11

to

* 2011-03-10 11:47 (UTC), loca...@example.org wrote:

> Is there any place I could read about what all these languages and
> implementations are all about and how to choose one to get started

> with? [...] I am using Linux if that matters.

I don't know such place but here's my single-minded suggestion anyway.
For learning Common Lisp I suggest reading Practical Common Lisp (by
Peter Seibel) [1].

As for implementation, most Linux users use SBCL, some use CLISP. I
think both can be installed easily with your Linux distribution's
package manager.

---------------
1. http://www.gigamonkeys.com/book/

loca...@example.org

unread,

Mar 10, 2011, 9:57:50 AM3/10/11

to

> For learning Common Lisp I suggest reading Practical Common Lisp (by
> Peter Seibel) [1].

I started going over this book some time ago and I couldn't get some of the
examples to work. I gave up and now I am trying again. Does it depend on
some specific implementation?

> As for implementation, most Linux users use SBCL, some use CLISP. I
> think both can be installed easily with your Linux distribution's
> package manager.

I looked before and SBCL didn't support 64 bit but I see now it does. I will
probably build it again, it looks nice. And CLISP comes on the Slackware CD
so it's easy to install.

> 1. http://www.gigamonkeys.com/book/

Thank you.

WJ

unread,

Mar 10, 2011, 11:07:32 AM3/10/11

to

loca...@example.org wrote:

http://groups.google.com/group/comp.lang.lisp/browse_frm/thread/31d55cbe
4b65fd13#

http://groups.google.com/group/comp.lang.lisp/browse_frm/thread/4021fc01
d9955a96#

Here's what the experts say about Commune Lisp:

"an unwieldy, overweight beast"
"intellectual overload"
"did kill Lisp"
"A monstrosity"
"killed Lisp"
"sucks"
"an aberration"
"incomprehensible"
"a nightmare"
"no future"
"a significantly ugly language"
"hacks"
"unfortunate"
"bad"

In context:

Brooks and Gabriel 1984, "A Critique of Common Lisp":

Every decision of the committee can be locally rationalized
as the right thing. We believe that the sum of these
decisions, however, has produced something greater than its
parts; an unwieldy, overweight beast, with significant costs
(especially on other than micro-codable personal Lisp
engines) in compiler size and speed, in runtime performance,
in programmer overhead needed to produce efficient programs,
and in intellectual overload for a programmer wishing to be
a proficient COMMON LISP programmer.

-----

Bernard Lang:

Common Lisp did kill Lisp. Period. (just languages take a
long time dying ...) It is to Lisp what C++ is to C. A
monstrosity that totally ignores the basics of language
design, simplicity and orthogonality to begin with.

-----

Gilles Kahn:

To this day I have not forgotten that Common Lisp killed
Lisp, and forced us to abandon a perfectly good system,
LeLisp.

-----

Paul Graham, May 2001:

A hacker's language is terse and hackable. Common Lisp is not.

The good news is, it's not Lisp that sucks, but Common Lisp.

Historically, Lisp has been good at letting hackers have their
way. The political correctness of Common Lisp is an aberration.
Early Lisps let you get your hands on everything.

A really good language should be both clean and dirty:
cleanly designed, with a small core of well understood and
highly orthogonal operators, but dirty in the sense that it
lets hackers have their way with it. C is like this. So were
the early Lisps. A real hacker's language will always have a
slightly raffish character.

Organic growth seems to yield better technology and richer
founders than the big bang method. If you look at the
dominant technologies today, you'll find that most of them
grew organically. This pattern doesn't only apply to
companies. You see it in sponsored research too. Multics and
Common Lisp were big-bang projects, and Unix and MacLisp
were organic growth projects.

-----

Jeffrey M. Jacobs:

Common LISP is the PL/I of Lisps. Too big and too
incomprehensible, with no examination of the real world of
software engineering.

... The CL effort resembles a bunch of spoiled children,
each insisting "include my feature or I'll pull out, and
then we'll all go down the tubes". Everybody had vested
interests, both financial and emotional.

CL is a nightmare; it has effectively killed LISP
development in this country. It is not commercially viable
and has virtually no future outside of the traditional
academic/defense/research arena.

-----

Dick Gabriel:

Common Lisp is a significantly ugly language. If Guy and I
had been locked in a room, you can bet it wouldn't have
turned out like that.

-----

Paul Graham:

Do you really think people in 1000 years want to be
constrained by hacks that got put into the foundations of
Common Lisp because a lot of code at Symbolics depended on
it in 1988?

-----

Daniel Weinreb, 24 Feb 2003:

Having separate "value cells" and "function cells" (to use
the "street language" way of saying it) was one of the most
unfortuanate issues. We did not want to break pre-existing
programs that had a global variable named "foo" and a global
function named "foo" that were distinct. We at Symbolics
were forced to insist on this, in the face of everyone's
knowing that it was not what we would have done absent
compatibility constraints. It's hard for me to remember all
the specific things like this, but if we had had fewer
compatibility issues, I think it would have come out looking
more like Scheme in general.

-----

Daniel Weinreb, 28 Feb 2003:

Lisp2 means that all kinds of language primitives have to
exist in two versions, or be parameterizable as to whether
they are talking about the value cell or function cell. It
makes the language bigger, and that's bad in and of itself.

-----

Guy L. Steele, Jr., July 1989:

I think we may usefully compare the approximate number of pages
in the defining standard or draft standard for several
programming languages:

Common Lisp 1000 or more
COBOL 810
ATLAS 790
Fortran 77 430
PL/I 420
BASIC 360
ADA 340
Fortran 8x 300
C 220
Pascal 120
DIBOL 90
Scheme 50

Peter Keller

unread,

Mar 10, 2011, 11:13:46 AM3/10/11

to

WJ <w_a_...@yahoo.com> wrote:
> loca...@example.org wrote:
>
>> Hi guys! Last time I looked at Lisp was mumble years ago. Looks like
>> alot has changed. I see there are numerous implementations of common
>> Lisp and there is Scheme and probably tons of other variations I
>> haven't heard of. Is there any place I could read about what all
>> these languages and implementations are all about and how to choose
>> one to get started with? Honestly I'm not sure what I would use it
>> for but I seem to be attracted to unusual programming languages. I
>> believe thinking outside the box makes you a better programmer. I am
>> using Linux if that matters.
>
> http://groups.google.com/group/comp.lang.lisp/browse_frm/thread/31d55cbe
> 4b65fd13#
>
> http://groups.google.com/group/comp.lang.lisp/browse_frm/thread/4021fc01
> d9955a96#
>
>
>
> Here's what the experts say about Commune Lisp:

[snip]

This poster had Common Lisp get he/she/its daughter pregnant out of
wedlock or something, so he/she/it will generally disparage Common
Lisp and its users. However, if you'd like to see the answers to your
Common Lisp questions in a variety of other languages, he/she/it will
glady comply. So that's a bonus at least.

-pete

Pascal J. Bourguignon

unread,

Mar 10, 2011, 11:13:45 AM3/10/11

to

loca...@example.org writes:

http://cliki.net/ has a lot of pointers.
http://common-lisp.net/ has a lot of libraries.

Be sure to read and watch:

SICP = Structure and Interpretation of Computer Programs
http://mitpress.mit.edu/sicp/full-text/book/book-Z-H-4.html
http://swiss.csail.mit.edu/classes/6.001/abelson-sussman-lectures/
http://www.codepoetics.com/wiki/index.php?title=Topics:SICP_in_other_languages
http://eli.thegreenplace.net/category/programming/lisp/sicp/
http://www.neilvandyke.org/sicp-plt/
http://www.youtube.com/watch?v=rdj6deraQ6k

Other interesting CL books (but check the lists on cliki):

PAIP = Paradigms of Artificial Intelligence Programming:
Case Studies in Common Lisp

CLAIA = "COMMON LISP: An Interactive Approach"
by Stuart C. Shapiro:
http://www.cse.buffalo.edu/~shapiro/Commonlisp/

A short introduction to CL (with only a few AllegroCL specific things):

BLT = Basic Lisp Techniques
Cooper - 2003 Franz, Inc. - 100 pages.
http://www.franz.com/resources/educational_resources/cooper.book.pdf

If you've not done so, you might also be interested by Erlang and Haskell.

--
__Pascal Bourguignon__ http://www.informatimago.com/
A bad day in () is better than a good day in {}.

Tim Bradshaw

unread,

Mar 10, 2011, 11:23:37 AM3/10/11

to

Worth pointing out to the OP: you might want to read some of WJ's other
articles before making judgements about what he says.

WJ

unread,

Mar 10, 2011, 12:22:37 PM3/10/11

to

Teemu Likonen wrote:

(let ((words (string-tokenize (string-upcase
(regexp-substitute/global #f "ng"

"> Is there any place I could read about what all these languages and
> implementations are all about and how to choose one to get started
> with? [...] I am using Linux if that matters.

I don't know such place but here's my single-minded suggestion anyway.
For learning Common Lisp I suggest reading Practical Common Lisp (by
Peter Seibel)

As for implementation, most Linux users use SBCL, some use CLISP. I

think both can be installed easily with your Linux distribution's
package manager.

" 'pre "mp" 'post)))))
(display (map (lambda (n) (list-ref words n))
'(38 22 56 51 38 76 45)))
(newline))

(DON'T CHOOSE COMMON LISP DON'T BE SIMPLE-MINDED)

Carlos

unread,

Mar 10, 2011, 12:28:43 PM3/10/11

to

[loca...@example.org, 2011-03-10 11:47]
[...]

> Is there any place I could read about what all
> these languages and implementations are all about and how to choose
> one to get started with?

This page has a survey of Common Lisp implementations:
http://common-lisp.net/~dlw/LispSurvey.html

It also has links to a lot of extra useful material.

Happy Lisp hacking :)
--

loca...@example.org

unread,

Mar 10, 2011, 12:46:27 PM3/10/11

to

Thanks for all these links! I will have a look at them all. But my problem
is not finding information on Lisp, it's how to find comparative information
for Lisp beginners. There's too much information in a way.

Teemu Likonen

unread,

Mar 10, 2011, 1:21:42 PM3/10/11

to

What information do you need exactly?

http://www.google.com/search?q=compare+scheme+common+lisp
http://clojure.org/lisps
http://www.cliki.net/Common%20Lisp%20implementation

loca...@example.org

unread,

Mar 10, 2011, 1:45:33 PM3/10/11

to

> What information do you need exactly?

How does someone who doesn't know anything know what he needs? ;)
Especially not exactly!

What dialects of Lisp exist and what is their purpose/how are they used?
That's the main thing I'm searching for. I can find dozens of home pages of
implementations and varieties but I didn't find a site explaining the
differences. I'll have a look at your links after I post this. Maybe some
Lisp advocacy type of information, what is Lisp good at, what is it not good
at, what unique features does it have etc.

I'm also interested in the history of Lisp and how and when all the branches
of the various dialects and implementations were created and why.

> http://www.google.com/search?q=compare+scheme+common+lisp
> http://clojure.org/lisps
> http://www.cliki.net/Common%20Lisp%20implementation

Thank you.

Zach Beane

unread,

Mar 10, 2011, 1:56:20 PM3/10/11

to

loca...@example.org writes:

> Maybe some Lisp advocacy type of information, what is Lisp good at,
> what is it not good at, what unique features does it have etc.

I like Abhishek Reddy's pages:

http://abhishek.geek.nz/docs/features-of-common-lisp/

http://abhishek.geek.nz/docs/lisp-answers/

Zach

loca...@example.org

unread,

Mar 10, 2011, 1:59:21 PM3/10/11

to

Thanks for the links!

Pascal J. Bourguignon

unread,

Mar 10, 2011, 2:00:28 PM3/10/11

to

loca...@example.org writes:

There's various paths to the destination.
What matters is not the destination, it's the travel.

You can choose or randomly enter any path. Soon enough, you'll know the
map.

For example, you could follow this path:

Get emacs, clisp (or ccl, or sbcl, whichever installs first smoothly for
you), quicklisp, configure slime.

Read PCL (or PAIP, or GENTLE, or really, any other Common Lisp
introduction), and the CLHS.

GENTLE = Common Lisp: A Gentle Introduction to Symbolic Computation
http://www-cgi.cs.cmu.edu/afs/cs.cmu.edu/user/dst/www/LispBook/index.html
http://www.cs.cmu.edu/~dst/LispBook/

Write Common Lisp programs, and read the CLHS.

When doing so, since you'll be using emacs, you'll be learning some
emacs lisp and the differences between emacs lisp and Common Lisp. If
you want to write more complex emacs customization, read the
"Introduction to Programming in Emacs Lisp" and the "GNU Emacs Lisp
Reference Manual".

As your second lisp book, read SICP, watch the SICP videos. (Even if you
don't plan to use scheme later!)

When doing so, since you'll be learning some scheme and some differences
between scheme and Common Lisp. If you want to learn more about scheme,
read the R5RS. If R7RS is not ready yet when you reach this stage, I'd
advise to wait for it and skip over R6RS. http://schemers.org/

If you want to get some historical perspective, read some documents and
sources referenced at: http://www.softwarepreservation.org/projects/LISP/

loca...@example.org

unread,

Mar 10, 2011, 2:13:27 PM3/10/11

to

> There's various paths to the destination.
> What matters is not the destination, it's the travel.

A philosopher ;) Well said! Anyway as we get older the destination sometimes
matters. I have enough exploratory languages to play around with that aren't
so practical for daily work. I don't like c or c++ so I thought maybe Lisp
would be a language I could use on Linux and get many things done. I would
like to find a language I like that compiles to native code, for one thing.

> Get emacs, clisp (or ccl, or sbcl, whichever installs first smoothly for
> you), quicklisp, configure slime.

Got clisp and slime already setup :) Emacs for years...

> you want to write more complex emacs customization, read the
> "Introduction to Programming in Emacs Lisp" and the "GNU Emacs Lisp
> Reference Manual".

That's an excellent idea as there are always things that need to be done
customizing emacs. I should start there perhaps.

Thanks for your excellent post and the links!

Tim Bradshaw

unread,

Mar 10, 2011, 2:28:31 PM3/10/11

to

On 2011-03-10 17:46:27 +0000, loca...@example.org said:

> it's how to find comparative information
> for Lisp beginners. There's too much information in a way.

If you mean "information about how to pick an implentation or dialect"
then I think the answer is "don't try and make that kind of choice
yet". As you can probably tell by looking at the responses so far
there are strong feelings about this kind of thing, which are almost
entirely irrational (indeed, in some cases you have to wonder about the
mental state of the people expressing these opinions).

Instead pick *something* and learn it, until you decide if it's what
you're after. Then make your own decision. I think it is now the case
that all the implementations of Common Lisp and certainly many
implementations of Scheme are of very high quality, and there is also
Clojure which, while neither a CL nor a Scheme also seems to be good,
so it's more important just to pick one, and learn the language
(whichever one you choose), and then, later, decide if it suits you
when you're in a better position to make a choice.

The fear people have is that making the wrong choice will somehow doom
them, but I don't think this is the case: I would particularly not want
to use any of the dialects I used when I started learning Lisp (which
were the only dialects available to me, none of them being really
anything like a modern Lisp), but I don't think they have somehow
warped my mind.

So, just pick *something*: it will be OK.

Paul Rubin

unread,

Mar 10, 2011, 3:09:56 PM3/10/11

to

loca...@example.org writes:
>> What information do you need exactly?
> How does someone who doesn't know anything know what he needs? ;)
> Especially not exactly!

What do you mean about "doesn't know anything"? You may know less than
the Lispers do about Lisp, but you know more than anyone else about YOU.
And knowledge about YOU is vital in figuring out the best approach to
Lisp for YOU.

Relevant aspects of the above:

- What languages do you already know? What do you like the most/least
about them and why?
- Why are you interested in Lisp? Just as a sightseer (nothing wrong
with that)? To deepen your understanding of programming? To find
a new language and environment to call "home"?
- Do you drive a fully loaded station wagon with a lot of creature
comforts, or a precision-tuned sports car with cramped seating a
no cargo space?

Basically if you're after clarity of thought and technical
enlightenment, try SICP and Scheme. If you want something more decked
out and "lived-in", try CL, but keep in mind that lots of its current
inhabitants are fond of it because they and CL have been together for
decades, but newbies might find CL old-fashioned. If you want something
newer, try Clojure, though that unfortunately makes you deal with Java.

loca...@example.org

unread,

Mar 10, 2011, 3:12:03 PM3/10/11

to

Tim what a brilliant post! I really like what I'm reading here. If you and
Pascal are representative of the Lisp community I think things are to my
liking. I like clear thinkers.

You're right for pointing out I'm not ready to make any choice. I wanted to,
to save time not learning something I really don't want. I'll continue
asking questions and try to avoid making that mistake but you're truly
right, I should just get started with something and then I'll know more as
you say about if it's what I'm looking for or not. At this point I can't
possibly choose.

> you're after. Then make your own decision. I think it is now the case
> that all the implementations of Common Lisp and certainly many
> implementations of Scheme are of very high quality, and there is also
> Clojure which, while neither a CL nor a Scheme also seems to be good,

It's good to know I won't go wrong picking a common Lisp implementation. I
was thinking about using SBCL because I read it creates native executables,
is that right? I just have to download it and build it under clisp and get
started. I am sure of one thing and that's I don't want to spend time with a
a scripting (interpreted) language. I mean I would like to be able to use it
for scripting but I want something I can use for everything, not just
scripting. I've got a few I can use for scripting already.

> So, just pick *something*: it will be OK.

Great advice and great post! Thanks to you and everyone who's responded!

Zach Beane

unread,

Mar 10, 2011, 3:23:30 PM3/10/11

to

loca...@example.org writes:

> I was thinking about using SBCL because I read it creates native
> executables, is that right?

With SBCL, all code you load from files or enter at the REPL is compiled
to native machine code before execution. (That's also the case with
Clozure CL, the second most popular implementation of CL.)

Producing single-file programs to run is a different sort of issue, but
SBCL (and other CLs) can do it. When I want to write a program to run on
the command-line or from cron or something like that, I write the
program interactively and then use Buildapp
(http://xach.com/lisp/buildapp/) to produce a single (large) executable
file from it.

> I just have to download it and build it under clisp and get started.

I recommend getting a binary of SBCL from www.sbcl.org to build
SBCL. It's fast and easy. While CLISP can usually build SBCL, it's not
as well-tested as building from SBCL.

Zach

loca...@example.org

unread,

Mar 10, 2011, 3:29:44 PM3/10/11

to

Hi Paul, great questions! This newsgroup is a goldmine!

> - What languages do you already know? What do you like the most/least
> about them and why?

I work on non x86 hardware and software for my day job. I write assembler
and have for many years. I didn't find any language or implementation on the
PC I feel gives me all that I want. I don't like C or C++ aesthetically
they bother me. I like languages that expose details as much as possible and
let you work in small steps rather than higher level ones that do many
things to you/for you. I like building my own bits and pieces for long term
reuse rather than relying on libraries but when it comes to something like
GUI I don't have the time or knowledge to reinvent the wheel so I'd like
something that works and doesn't have intolerable wierdness or
unreliability. I'd like to be kept away from the hardware just enough that I
am still using an HLL and not assembly- when I want assembly I'll learn that
;) and not C that just takes too much effort for no benefit, neither here
nor there. I like languages that are visually appealing but that doesn't
help much since it's a matter of personal taste. I find Ada pleasant to look
at for example and I find Java less offensive than C/C++.

> - Why are you interested in Lisp? Just as a sightseer (nothing wrong
> with that)? To deepen your understanding of programming? To find
> a new language and environment to call "home"?

I would say the latter since I am not fluent in any PC language that creates
native code. I'd like to learn one language I could use to get anything done
short of device drivers and it would be nice if it could also be used for
scripting but not essential since I know a few scripting languages well
enough for my needs. Ada seems like a good choice but it's got its issues
and I'd like a non-drama-queen environment and not being held hostage by the
GPL every time I need something outside the main language.

> - Do you drive a fully loaded station wagon with a lot of creature
> comforts, or a precision-tuned sports car with cramped seating a
> no cargo space?

The latter definitely. I don't like interpreted languages for that reason.

> Basically if you're after clarity of thought and technical
> enlightenment, try SICP and Scheme. If you want something more decked
> out and "lived-in", try CL, but keep in mind that lots of its current
> inhabitants are fond of it because they and CL have been together for
> decades, but newbies might find CL old-fashioned. If you want something
> newer, try Clojure, though that unfortunately makes you deal with Java.

Yeah I'm fine with oldish things that work. I don't have to have the
newest, tried and true is better for me than latest and greatest. I want
something solid that just works, runs fast, with a good community (and first
impressions are great here!) and just enough libraries for my meager needs
so I don't have to give up and choose Java for everything on the PC just
because it has tons of classes.

loca...@example.org

unread,

Mar 10, 2011, 3:31:48 PM3/10/11

to

Hi Zach thanks for the help!

> With SBCL, all code you load from files or enter at the REPL is compiled
> to native machine code before execution. (That's also the case with
> Clozure CL, the second most popular implementation of CL.)

Good to know.

> I recommend getting a binary of SBCL from www.sbcl.org to build
> SBCL. It's fast and easy. While CLISP can usually build SBCL, it's not
> as well-tested as building from SBCL.

I'll see if there's anything I can use. Thanks for the pointer!

loca...@example.org

unread,

Mar 10, 2011, 3:37:19 PM3/10/11

to

I didn't mean to leave out Temo and Zach, you guys are all great! thanks for
the help!

Paul Rubin

unread,

Mar 10, 2011, 4:10:04 PM3/10/11

to

loca...@example.org writes:
> I like languages that expose details as much as possible and
> let you work in small steps rather than higher level ones that do many
> things to you/for you.

Maybe you want FORTH (www.forth.org). Lisp might not be your thing.

> I like languages that are visually appealing but that doesn't
> help much since it's a matter of personal taste. I find Ada pleasant to look
> at for example and I find Java less offensive than C/C++.

In that case I hope you feel capable of developing visual fondness for
parentheses, if you start using Lisp.

>> - Do you drive a fully loaded station wagon with a lot of creature
>> comforts, or a precision-tuned sports car with cramped seating a
>> no cargo space?
>
> The latter definitely. I don't like interpreted languages for that reason.

Well, Scheme and CL are both compiled and go at your cpu's "speed
limit", so it's mostly a matter of style. If you want the cramped
sports car, go for Scheme. You might also like Picolisp or Hedgehog
Lisp (find with web search).

Marco Antoniotti

unread,

Mar 10, 2011, 4:51:55 PM3/10/11

to

On Mar 10, 7:56 pm, Zach Beane <x...@xach.com> wrote:

Thanks for these links. They are very nice.
--
MA

Pascal J. Bourguignon

unread,

Mar 10, 2011, 5:21:10 PM3/10/11

to

loca...@example.org writes:

> I was thinking about using SBCL because I read it creates native executables,
> is that right?

That's right, but all CL implementations let you create native executables
(apart perhaps abcl). So that's not a very significant criteria.

What could be a valid criteria, for deployment, would be:

- size of executable,
- speed of executable,
- possibility of storing part of the executable in a shared library,

amongst others.

Then we could compare implementations and see what would match best your
purposes. But notice that a lot of other criteria will be involved in
the choice of an implementation (eg. target plateform(s), availability of
certain interfaces, ease of use (debugging).

An interesting feature of Common Lisp, is that since it has a standard,
a program written conformingly to this standard will run equally on all
the conforming implementations. This allows you to choose a different
implementation for different phases of a project, or for different
deployment strategies.

The consequence is that it makes the question of an implementation quite
irrelevant and not something that you should bother with too early.

Lisp is a late binding language, which allows you to commit to a
specific compiler later than most other programming languages.

>> So, just pick *something*: it will be OK.
>
> Great advice and great post! Thanks to you and everyone who's responded!

TheFlyingDutchman

unread,

Mar 10, 2011, 10:07:29 PM3/10/11

to

> Daniel Weinreb, 24 Feb 2003:
>
> Having separate "value cells" and "function cells" (to use
> the "street language" way of saying it) was one of the most
> unfortuanate issues. We did not want to break pre-existing
> programs that had a global variable named "foo" and a global
> function named "foo" that were distinct. We at Symbolics
> were forced to insist on this, in the face of everyone's
> knowing that it was not what we would have done absent
> compatibility constraints. It's hard for me to remember all
> the specific things like this, but if we had had fewer
> compatibility issues, I think it would have come out looking
> more like Scheme in general.

There must be some advantages to having separate "value cells" and
"function cells" for a symbol. I don't believe the original Lisp did
it. And Emacs Lisp does it and that did not have to be backward
compatible with a previous Emacs macro language.

Not clear about the comment regarding "come out looking more like
Scheme in general". I don't recall hearing about Scheme being part of
the Lisp dialects the US Department of Defense wanted consolidated
into a single dialect. Why does Weinreb seem to wish Common Lisp was
more "Scheme-like" when it was not being used in the domain where he
was working?

Marco Antoniotti

unread,

Mar 11, 2011, 2:30:38 AM3/11/11

to

On Mar 10, 11:21 pm, "Pascal J. Bourguignon" <p...@informatimago.com>
wrote:

> localh...@example.org writes:
> > I was thinking about using SBCL because I read it creates native executables,
> > is that right?
>
> That's right, but all CL implementations let you create native executables
> (apart perhaps abcl). So that's not a very significant criteria.

I believe Didier Verna has worked nicely to this end.

Cheers
--
Marco

loca...@example.org

unread,

Mar 11, 2011, 4:10:29 AM3/11/11

to

> Maybe you want FORTH (www.forth.org). Lisp might not be your thing.

Thanks for the link that looks very interesting and I would probably enjoy
it. But now I am looking for a more mainstream language so I don't add
another oddball to my tool bag.

> In that case I hope you feel capable of developing visual fondness for
> parentheses, if you start using Lisp.

It was a shock at first because I was using a line editor. At least Emacs
matches up the parens..

> Well, Scheme and CL are both compiled and go at your cpu's "speed
> limit", so it's mostly a matter of style. If you want the cramped
> sports car, go for Scheme. You might also like Picolisp or Hedgehog
> Lisp (find with web search).

I had thought I read clisp and several others actually compiled to
bytecode. Is that right, if so that's not what I'm looking for. But I also
read SBCL does compile to native code. I'll look at the other ones you
mentioned as well, thanks.

loca...@example.org

unread,

Mar 11, 2011, 4:15:48 AM3/11/11

to

> That's right, but all CL implementations let you create native executables
> (apart perhaps abcl). So that's not a very significant criteria.

Is that true? I thought I read several used VMs.

> What could be a valid criteria, for deployment, would be:
>
> - size of executable,

Not all too important unless there's needless bloat

> - speed of executable,

Right

> - possibility of storing part of the executable in a shared library,
> amongst others.

I'm not sure what that means but my preference is to have everything
staticly linked.

> An interesting feature of Common Lisp, is that since it has a standard,
> a program written conformingly to this standard will run equally on all
> the conforming implementations. This allows you to choose a different
> implementation for different phases of a project, or for different
> deployment strategies.

That is important if indeed it really works.

> The consequence is that it makes the question of an implementation quite
> irrelevant and not something that you should bother with too early.

Thanks, I realize that now except I don't want to get started with an
interpreted system and have to spend time later moving to one that compiles
to an executable.

> Lisp is a late binding language, which allows you to commit to a
> specific compiler later than most other programming languages.

Excellent

Paul Rubin

unread,

Mar 11, 2011, 4:44:07 AM3/11/11

to

loca...@example.org writes:
> I had thought I read clisp and several others actually compiled to
> bytecode. Is that right, if so that's not what I'm looking for. But I also
> read SBCL does compile to native code. I'll look at the other ones you
> mentioned as well, thanks.

CL means common lisp. Clisp is just one implementation of common lisp,
a fairly lightweight one, that I don't think has a native compiler.
SBCL is another CL implementation that does have a native compiler,
though the overall system is much bigger than Clisp. The point of CL
being a standard is that most of your code should be able to run the
same way on both systems.

I frankly would start out with SICP and Scheme given what you told me.
Scheme is a Lisp dialect that uses mostly the same ideas, so knowledge
you get from it will carry over to CL if you later want to use that.
But SICP will give you a more solid understanding of what the
implementations actually do.

If you know C, you could also study the source code of some Lisp
implementations, especially smaller ones. That too is very informative.

Pascal J. Bourguignon

unread,

Mar 11, 2011, 4:49:22 AM3/11/11

to

Paul Rubin <no.e...@nospam.invalid> writes:

> If you know C, you could also study the source code of some Lisp
> implementations, especially smaller ones. That too is very informative.

I fail to see how that applies.
Most lisp implementations are written (mostly) in lisp.

Teemu Likonen

unread,

Mar 11, 2011, 4:57:56 AM3/11/11

to

* 2011-03-11 09:15 (UTC), loca...@example.org wrote:

>> - size of executable,
>
> Not all too important unless there's needless bloat

Common Lisp executables usually contain the whole Lisp environment.
Everything is available at runtime too. Since many programs don't need
the all the language environment there usually is some "needless bloat".

For example, I have one general SBCL image for my different tools and it
takes 43 megabytes of disk space. The image has all the needed libraries
for all my tools.

>> An interesting feature of Common Lisp, is that since it has a
>> standard, a program written conformingly to this standard will run
>> equally on all the conforming implementations. This allows you to
>> choose a different implementation for different phases of a project,
>> or for different deployment strategies.
>
> That is important if indeed it really works.

It works in theory ("a program written conformingly") but not that well
in practice. The standard does not say much about interacting with
operating system's features. In practice you'll often need additional
features which implementations offer. This introduces some portability
problems. Fortunately there are general libraries which provide a
higher-level interface for implementation- specific features.

For example, you could use SB-POSIX:GETENV function in SBCL and
EXT:GETENV in CLISP but you can also use IOLIB.SYSCALLS library and its
ISYS:GETENV function. That works on both SBCL and CLISP (and also in
many other implementations).

Paul Rubin

unread,

Mar 11, 2011, 5:02:05 AM3/11/11

to

"Pascal J. Bourguignon" <p...@informatimago.com> writes:
>> If you know C, you could also study the source code of some Lisp
>> implementations, especially smaller ones. That too is very informative.
>
> I fail to see how that applies.
> Most lisp implementations are written (mostly) in lisp.

The premise is that the OP doesn't already know lisp. Also, quite a few
small lisps (including Clisp) and maybe some of the larger ones
(KCL/GCL?) have at least their inner layers written in C.

I played around with interactive lisps for a while when I got started,
but I didn't really "get it" til reading the Emacs source code. So in
my experience the approach of reading an implementation is useful.

loca...@example.org

unread,

Mar 11, 2011, 5:04:08 AM3/11/11

to

> CL means common lisp. Clisp is just one implementation of common lisp,
> a fairly lightweight one, that I don't think has a native compiler.
> SBCL is another CL implementation that does have a native compiler,
> though the overall system is much bigger than Clisp. The point of CL
> being a standard is that most of your code should be able to run the
> same way on both systems.

Thanks for the info. I assumed CL meant Common Lisp so my question was in
response to the statement that all CL implementations compile to native
code, which you just said is not true.

> I frankly would start out with SICP and Scheme given what you told me.
> Scheme is a Lisp dialect that uses mostly the same ideas, so knowledge
> you get from it will carry over to CL if you later want to use that.
> But SICP will give you a more solid understanding of what the
> implementations actually do.

Thanks, sounds like a good plan. Now which implementation of Scheme should I
use ;) The questions never end...

> If you know C, you could also study the source code of some Lisp
> implementations, especially smaller ones. That too is very informative.

That would be good but my C is rather poor since I don't like it, I didn't
make any effort to learn it.

loca...@example.org

unread,

Mar 11, 2011, 5:06:47 AM3/11/11

to

> Common Lisp executables usually contain the whole Lisp environment.
> Everything is available at runtime too. Since many programs don't need
> the all the language environment there usually is some "needless bloat".

Ok, thanks for the info. That is important to know.

> For example, I have one general SBCL image for my different tools and it
> takes 43 megabytes of disk space. The image has all the needed libraries
> for all my tools.

Well that is ok on a normal PC, it's still lighter than Java's VM ;)

But for embedded work I guess a lightweight implementation is necessary.
Anyway I don't plan any embedded work so I should be ok even with a big
executable. I prefer something that runs fast over something small when it
comes to HLL.

> It works in theory ("a program written conformingly") but not that well
> in practice. The standard does not say much about interacting with
> operating system's features. In practice you'll often need additional
> features which implementations offer. This introduces some portability
> problems. Fortunately there are general libraries which provide a
> higher-level interface for implementation- specific features.

I guess that's true of almost every language.

unread,

Mar 11, 2011, 5:20:56 AM3/11/11

to

> For reasonable sized embedded cpu's you might try hedgehog lisp, which
> uses a bytecode vm that takes about 20k and is intended for embedded
> use. What do you want to run that needs native-code speed anyway?

Since I'm an assembler guy I don't like interpreted systems, I'm used to
being able to create small, high performance executables and I would like
the same capability in any HLL I choose for my general purpose language on
Linux. If I was happy with bytecode compilers I would just use Java. I use
SNOBOL for scripting and it's excellent, powerful and flexible, but there
isn't any native compiler for Linux. The search is on!

> You could also look at Lua, which has a VM and some kind of VM to native
> translator (LuaJIT). I don't know how lightweight LuaJIT is though.
>
> For smaller mcu's, lisp is hopeless but you can run a reasonable Forth
> in 8K. Smaller than that and you need cross compilers.

As I mentioned, I'm not planning on doing any embedded work. But thanks for
the pointers all this is very interesting.

Tim Bradshaw

unread,

Mar 11, 2011, 5:25:38 AM3/11/11

to

On 2011-03-11 09:15:48 +0000, loca...@example.org said:

>
>> An interesting feature of Common Lisp, is that since it has a standard,
>> a program written conformingly to this standard will run equally on all
>> the conforming implementations. This allows you to choose a different
>> implementation for different phases of a project, or for different
>> deployment strategies.
>
> That is important if indeed it really works.

It's actually less important than you might think. People get
enormously hung up on the fact that there is a standard but it doesn't
cover enough that you can write entirely portable code which (for
instance) does network access.

Here's a story which tries to explain why it does not actually matter.
First of all, pick an implementation which runs on a wide range of
platforms: this is probably almost any current CL implementation. You
are now busy worrying about portability. Now, I will peform brain
surgury on you and modify your mind until you believe that this is the
only implementation, that there is no standard other than that defined
by this implementation, and in fact that the language is called "Perl",
not "Common Lisp". Suddenly you are not worrying about portability any
more. Why is that? What has actually changed outside your head?

The situation with Scheme is probably similar: I am talking about CL
only because I am less familiar with Scheme implementations so I'm not
really competent to discuss them (the one I use - Racket - seems to
have all the good properties).

I'd suggest that a far more important thing to worry about is: once you
have chosen an implementation, how much do you need to modify your
program to run on the various different platforms you might care about?
In other words, once you have written your system on Linux, what
changes do you need to make to make it portable to Windows as well?
From first-hand experience I can say that if you write reasonably
carefully, the answer is that the changes are very small indeed.

loca...@example.org

unread,

Mar 11, 2011, 5:25:39 AM3/11/11

to

> I don't think I'd say Lisp is mainstream either.

I thought the same thing but I see from the web anyway the community looks
pretty substantial and Lisp is actively developed and used, so it's becoming
more and more mainstream. Ok most people never heard of it but that's true
with many things in software.

> You might also take a look at Ocaml, another non-mainstream language, if
> you like normal-looking syntax and static types.

That's interesting you say OCaml has normal looking syntax. I saw a few
examples and I was horrified. I'll look again.

> Or Erlang, if you want massive concurrency.

Not until they start selling PCs with 16 sockets...until then I do my
massively parallel stuff at work :-)

Edmunds Cers

unread,

Mar 11, 2011, 5:37:26 AM3/11/11

to

Paul Rubin <no.e...@nospam.invalid> writes:

> I frankly would start out with SICP and Scheme given what you told me.

I read the thread and I get the feeling you might be talking past each
other. When you asked for station wagon vs sports car, you obviously
meant language features, whereas the OP seems to have meant executable
performance. (I draw that inference mainly on the OP stating that he
found Ada likable.) If this is the case, it's worth stating that CL is
a big and feature loaded language shaped in a big way by (smart)
compromises whereas Scheme is lean and sleek and originally a
concept/teaching language. Performance wise the differences shouldn't be
great, with CL's native compilers having some edge.

> Scheme is a Lisp dialect that uses mostly the same ideas, so knowledge
> you get from it will carry over to CL if you later want to use that.

I'm not so sure about that. IMHO Scheme puts a great emphasis on
recursion and closures in unhelpful ways. If you start to learn lisp by
learning Scheme you run the risk of getting the wrong impression about
what lisp is. While I agree that the style advocated by SICP (and
Scheme) is very elegant, I feel it to be restraining. To me, part of the
attraction of lisp is the freedom to choose whatever style works for a
given problem, losing the shackles, so to say. So while I absolutely
love CL, I'm not that keen on Scheme (and I can't be the only one).

The above does not mean you shouldn't start by reading SICP - it still
is one of the best programming books ever. Just take it for what it is -
just one approach to the programming problem. And lisp is not
intrinsically tied to the approach offered in SICP either (Scheme
largely is). CL is much more down to earth in a "just do whatever works"
way. To get a feel of what CL is about, I'd echo the suggestion for PCL.

--
A change in perspective is worth 80 IQ points. --- Alan Kay

Paul Rubin

unread,

Mar 11, 2011, 6:22:25 AM3/11/11

to

Edmunds Cers <edm...@laivas.lv> writes:
> When you asked for station wagon vs sports car... it's worth stating

> that CL is a big and feature loaded language shaped in a big way by
> (smart) compromises whereas Scheme is lean and sleek and originally a
> concept/teaching language. Performance wise the differences shouldn't
> be great, with CL's native compilers having some edge.

Yes, that's what I meant, in case there was any confusion.

> CL is much more down to earth in a "just do whatever works"
> way. To get a feel of what CL is about, I'd echo the suggestion for PCL.

Fair enough. I want to get around to looking at PCL myself sometime.
I actually found CLTL2 pretty readable, but I was already familiar
with other lisp dialects when I read it.

loca...@example.org

unread,

Mar 11, 2011, 6:54:31 AM3/11/11

to

>> That is important if indeed it really works.
>
> It's actually less important than you might think. People get
> enormously hung up on the fact that there is a standard but it doesn't
> cover enough that you can write entirely portable code which (for
> instance) does network access.

I never bought into the idea that C was so great because of it's alleged
portability and I hear Java's portability hasn't lived up to it either. I
don't really worry about stuff running on systems I don't have but it would
be nice to be able to give people running Windows stuff I develop on
Linux. If not, ok.

> From first-hand experience I can say that if you write reasonably
> carefully, the answer is that the changes are very small indeed.

Good!

loca...@example.org

unread,

Mar 11, 2011, 6:55:44 AM3/11/11

to

Thank you for a very helpful and insightful post!

Paul Rubin

unread,

Mar 11, 2011, 7:09:13 AM3/11/11

to

loca...@example.org writes:
> Since I'm an assembler guy I don't like interpreted systems, I'm used
> to being able to create small, high performance executables and I
> would like the same capability in any HLL I choose for my general
> purpose language on Linux.

Well, for some definition of "small", I think that's not completely
going to happen with any language that relies on garbage collection and
a complicated runtime. With a native CL compiler and a bit of tuning
you can get a Lisp program to run comparably fast to a C program, but at
the cost of using quite a bit more memory. I think you should stop
worrying about it unless you've got a specific application that is
hosing your processor, in which case you should describe it so you can
get some more concrete advice. If you're talking about desktop
computers, they are so fast and capacious these days that you can get
away with quite inefficient languages if it makes you more productive as
a programmer. Even if it's cpu-intensive it's not necessarily memory
starved.

> SNOBOL for scripting

OMG, now THERE's a blast from the past. Really, try something more
modern, like Python or Ruby, for that sort of thing.

> but there isn't any native compiler for Linux. The search is on!

http://en.wikipedia.org/wiki/SPITBOL_compiler

loca...@example.org

unread,

Mar 11, 2011, 7:12:53 AM3/11/11

to

> http://en.wikipedia.org/wiki/SPITBOL_compiler

Unfortunately no Linux port. I've been checking the page ;) Thanks.

Paul Rubin

unread,

Mar 11, 2011, 7:16:19 AM3/11/11

to

loca...@example.org writes:
> I thought the same thing but I see from the web anyway the community
> looks pretty substantial and Lisp is actively developed and used, so
> it's becoming more and more mainstream. Ok most people never heard of
> it but that's true with many things in software.

Certainly it's still being used and it will be with us forever, and
every programmer should get interested in it at some point. But I
would say that its heyday was the 1980's and it's basically in decline
now, becoming further rather than closer to mainstream.

> That's interesting you say OCaml has normal looking syntax. I saw a few
> examples and I was horrified. I'll look again.

Well, I just mean it has infix arithmetic etc. I actually think it's
ugly too. I like Haskell syntax but that language may be weirder and
hairier than you want to deal with.

>> Or Erlang, if you want massive concurrency.
> Not until they start selling PCs with 16 sockets...until then I do my
> massively parallel stuff at work :-)

Parallelism (multiple CPU's) and concurrency (multitasking, like having
several network connections active at the same time) are not the same
thing. I just read an interview with someone who wrote a BitTorrent
client in Erlang and he said Erlang was great for that.

loca...@example.org

unread,

Mar 11, 2011, 7:27:32 AM3/11/11

to

>>> Or Erlang, if you want massive concurrency.
>> Not until they start selling PCs with 16 sockets...until then I do my
>> massively parallel stuff at work :-)
>
> Parallelism (multiple CPU's) and concurrency (multitasking, like having
> several network connections active at the same time) are not the same
> thing.

I'm aware of it, we've had both for over 30 years on the system I work
on and we have significantly less problems than the UNIX guys because they
started out with lightweight processes and never understood threads or how
to implement them and when they did it was race condition city. Multitasking
and multiple CPUs have been so basic to our environment for so many years
it's a little surprising to see the state of affairs in SMP support on x86
and how many issues there are with it.

The simple fact is multitasking only gets you so far without enough
horsepower to support it. Otherwise you either spend most of your time
thrashing and get no or negative performance gain. It's interesting how much
time the PC chip manufacturers have thrown at 64 bit hardware and how little
they've done with more sockets. I guess that's mostly because of Windows, I
mean the lack of increased sockets. Anyway I really don't see any relevance
in emphasis on concurrency on a single-user PC platform more than having a
couple of threads around so your GUI or DB access doesn't get stuck.

Paul Rubin

unread,

Mar 11, 2011, 7:31:45 AM3/11/11

to

loca...@example.org writes:
>> http://en.wikipedia.org/wiki/SPITBOL_compiler
> Unfortunately no Linux port. I've been checking the page ;) Thanks.

Have you been looking at the blog (I just found it)?
http://daveshields.wordpress.com

It was updated fairly frequently til mid 2009, then suddenly stopped.
I hope nothing is wrong.

loca...@example.org

unread,

Mar 11, 2011, 7:53:46 AM3/11/11

to

> Have you been looking at the blog (I just found it)?
> http://daveshields.wordpress.com

Yes. SPITBOL isn't exactly SNOBOL but I guess you could compare them to Lisp
v. Scheme, maybe I'm overstating since I don't know Lisp at all. They're
different implementations, very similar but with some important mostly
operational differences. SNOBOL was always interpreted and SPITBOL was
Illinois Institute of Technology's compiled language, with changes. Bob
Dewar, the guy who wrote it is some kind of a genius, he was also
responsible for developing the Ada front end for gcc at NYU which was forked
into a commercial offering from Ada Core where he works now.

It doesn't exactly help x86 guys that the MVS source code for SPITBOL is
available but it does help that the SNOBOL code was available, because of
the way SNOBOL was implemented originally in a macro language vm-ish sort of
way. I guess that's why somebody was able to give us a really nice version
of SNOBOL on *NIX. So far no SPITBOL and no compiled variant of SNOBOL, but
it's still an excellent scripting language mostly because of the amazing
pattern matching but also because the guy who implemented the PC version
really did a nice job with alot of thought put into it.

>
> It was updated fairly frequently til mid 2009, then suddenly stopped.
> I hope nothing is wrong.

That's a good question. I don't know whether Dave went onto something else
or what the story is. Apparently he also has a history of compiler writing
and looks like pretty hot stuff. I would love to have a Linux compiler but
have confirmed through several sources there's no such animal at the
moment. There is a vendor for Windows/DOS and even Sparc SPITBOL compilers,
the only reason I can think of why there isn't a Linux version must be
because the guy selling it now didn't develop it and can't port it.

Pascal J. Bourguignon

unread,

Mar 11, 2011, 8:11:51 AM3/11/11

to

Tim Bradshaw <t...@tfeb.org> writes:

> On 2011-03-11 09:15:48 +0000, loca...@example.org said:
>
>>
>>> An interesting feature of Common Lisp, is that since it has a standard,
>>> a program written conformingly to this standard will run equally on all
>>> the conforming implementations. This allows you to choose a different
>>> implementation for different phases of a project, or for different
>>> deployment strategies.
>>
>> That is important if indeed it really works.
>
> It's actually less important than you might think. People get
> enormously hung up on the fact that there is a standard but it doesn't
> cover enough that you can write entirely portable code which (for
> instance) does network access.

That's a lie! There are portability libraries covering all the needed
functionalies, including network access. Even if some library was
missing, there's CFFI, so you have at least exactly the same portability
issues as programs written in C.

> Here's a story which tries to explain why it does not actually
> matter. First of all, pick an implementation which runs on a wide
> range of platforms: this is probably almost any current CL
> implementation.

This just does not matter: you can use implementation A on plateform α,
and implemetation B on plateform β, and thanks to the portability
libraries, that goes beyond the CL standard.

> I'd suggest that a far more important thing to worry about is: once
> you have chosen an implementation, how much do you need to modify your
> program to run on the various different platforms you might care
> about? In other words, once you have written your system on Linux,
> what changes do you need to make to make it portable to Windows as
> well? From first-hand experience I can say that if you write
> reasonably carefully, the answer is that the changes are very small
> indeed.

Indeed, if you structure your application well, it can include its own
portability libraries. But why wait the last moment when you can use
portability libraries from the start? In any case, you need to know the
standard, and what makes a program conforming or not.

Pascal J. Bourguignon

unread,

Mar 11, 2011, 8:13:52 AM3/11/11

to

loca...@example.org writes:

> That's interesting you say OCaml has normal looking syntax. I saw a few
> examples and I was horrified. I'll look again.

Don't bother. It just means you're ready for lisp.

Pascal J. Bourguignon

unread,

Mar 11, 2011, 8:17:12 AM3/11/11

to

loca...@example.org writes:

> Anyway I really don't see any relevance
> in emphasis on concurrency on a single-user PC platform more than having a
> couple of threads around so your GUI or DB access doesn't get stuck.

Sure, GUI or DB access doesn't need heavy parallelism.

On the other hand what benefit heavy parallelism are 3D graphics, physic
simulations, artificial neural networks, etc.

unread,

Mar 11, 2011, 3:25:41 PM3/11/11

to

On 3/10/11 12:29 PM, loca...@example.org wrote:
> Hi Paul, great questions! This newsgroup is a goldmine!
>
>> - What languages do you already know? What do you like the most/least
>> about them and why?
>
> I work on non x86 hardware and software for my day job. I write assembler
> and have for many years. I didn't find any language or implementation on the
> PC I feel gives me all that I want. I don't like C or C++ aesthetically
> they bother me. I like languages that expose details as much as possible and
> let you work in small steps rather than higher level ones that do many
> things to you/for you. I like building my own bits and pieces for long term
> reuse rather than relying on libraries but when it comes to something like

This makes me think you'd be happier with Scheme. Somewhere else you said
you like `small, high performance executables'. For that you can use Stalin
(a slow compiler but it generates very efficient code). You will have to
stick with R4RS dialect (which is plenty good).

There are lots of choices in the Scheme world: interpreters, compilers,
IDEs. And none of them are ideal (or even necessarily "complete"). But
if you like rolling your own code that shouldn't be a problem.

>> - Why are you interested in Lisp? Just as a sightseer (nothing wrong
>> with that)? To deepen your understanding of programming? To find
>> a new language and environment to call "home"?
>
> I would say the latter since I am not fluent in any PC language that creates
> native code. I'd like to learn one language I could use to get anything done
> short of device drivers and it would be nice if it could also be used for
> scripting but not essential since I know a few scripting languages well
> enough for my needs. Ada seems like a good choice but it's got its issues
> and I'd like a non-drama-queen environment and not being held hostage by the
> GPL every time I need something outside the main language.

Scheme is one of the language I use for scripting, for text processing,
for quick hacks, for generating "code" (target language can be C, C++,
sh, etc.).

I have written `firmware' code for a custom network processor using
Scheme! I know people have used Scheme for designing asics, for `live
coding' (electronic music composition & performance by writing code in
front of an audience), etc, etc. CL would also work in all these situations.
Which language you like probably depends on your personality!

> Yeah I'm fine with oldish things that work. I don't have to have the
> newest, tried and true is better for me than latest and greatest. I want
> something solid that just works, runs fast, with a good community (and first
> impressions are great here!) and just enough libraries for my meager needs
> so I don't have to give up and choose Java for everything on the PC just
> because it has tons of classes.

Ah... that "just enough libraries" makes me less certain Scheme is
right for you, not knowing what your "meager" needs might be!

My advice: don't waste time `researching'. Pick either CL or Scheme,
pick one (or two) implementation(s) and write code. When you run into
difficulties, don't give up and move to a new implementation but
try to solve your problem as best as you can. If you stick using
only standard language features (or library, or SRFIs in Scheme),
moving to a new impl. later will be easier.

James Ashley

unread,

Mar 11, 2011, 4:48:23 PM3/11/11

to

I'm really just a lurker who's learning CL. The experts (and even
those who aren't so expert) who have already posted in this thread are
much more qualified than I when it comes to most aspects of
programming. For that matter, so's the OP.

OTOH...in a lot of ways, I've spent years going through the same
search the OP is now. And sometimes the worm's-eye perspective has
value.

On Mar 11, 3:15 am, localh...@example.org wrote:
> > That's right, but all CL implementations let you create native executables
> > (apart perhaps abcl). So that's not a very significant criteria.
>
> Is that true? I thought I read several used VMs.

Several do. And, in a lot of ways, it makes sense to think of all CL
"programs" (no idea if this is true of other lisp dialects) as running
in a VM (even the ones that compile to native code).

In a similar sense, one can think of the C runtime as a VM. But CL is
more-so.

The most common use-case I run across (in my *extremely* limited
experience) is starting up a lisp instance, then modifying it and
running "programs" from within it. IMHO, it really stands out from the
crowd when you're using it interactively.

Python and ruby (along with several others, I'm sure) also have REPLs,
but they feel more like something you use for trying things out while
you're developing your "real" script. I wonder how much difference
something like SLIME would make for them.

> > What could be a valid criteria, for deployment, would be:
>
> > - size of executable,
>
> Not all too important unless there's needless bloat

That really depends on what you mean by "needless."

Others have already pointed this out, but it felt [to me] as if they
were making the point just a little too subtly.

In almost every free CL implementation with which I'm familiar, the
"executable" it produces is really just a snapshot of your current VM
image, along with the CL runtime (which includes things like the
compiler). IIRC, at least one of the commercial packages includes a
"tree-shaker" to remove the pieces your "executable" doesn't need.

It seems like it's much more common (at least in the open source
world) to just define a "system" that specifies which source files
(and other systems) it needs to run, then other people can load that
into their running image, as they want/need.

Personally, I think this is one of CL's most glaring weaknesses. Not a
big one, but it's still there. It's at least as difficult to create a
set of binaries that work with multiple platforms as it is with C.
OTOH, it's also a strength: if you're writing compliant code, porting
it to a different platform is just a matter of defining vendor-
specific pieces that are supported on that platform.

Well, and possibly dealing with UI issues. AIUI, that's really the
only aspect where Java's "WORA" has meaningful issues. There's plenty
that's wrong with Java, but that really isn't a good example.

Anyway, to distribute something as a system, whomever you're sharing
it with really needs to have a CL installed, and be willing to
interact with something like the command-line to load the system and
run the "program" it defines. Until someone wraps a pretty GUI around
quicklisp.

No idea how the real world of closed source deals with this. And I
could very well be completely and totally mistaken about the entire
issue.

> > - speed of executable,
>
> Right

A lot of people get hung up on this, and it's generally a mistake.

They'll pick some random benchmark and use it to prove that "lisp" is
slow. Maybe the Python runtime has a faster dictionary implementation
than CMUCL's hash tables. Or a "Hello World" program is ridiculously
slow, because the lisp image has to load before it can run (for this
reason, lisp generally isn't suitable for a standard CGI environment
where it has to start and end with each request).

For anyone who doesn't know this (browsing the archives, maybe): Most
of a program's performance depends on the algorithms a programmer
chooses in just a few critical areas.

A lisp programmer who can try out a dozen different algorithms in the
time it takes, say, a C programmer to implement one, will, all other
things being equal, wind up with faster "executables." And there are
other performance-tuning techniques when they're needed. On the rare
occasions that still isn't enough, it's not *that* difficult to
implement the best algorithm in C, or even assembler.

> > - possibility of storing part of the executable in a shared library,
> > amongst others.
>
> I'm not sure what that means but my preference is to have everything
> staticly linked.

That's certainly possible (for some definition of "static"). I'm under
the impression that it's more useful to have at least one back-door
you can sneak into to fix any problems that might turn up (http://
www.flownet.com/gat/jpl-lisp.html is an interesting perspective on
lisp's history, and gives a perfect example of what I mean). Also,
there's at least a reasonable chance you'll want to give whoever uses
your executable some sort of access to the REPL. At that point, the
idea of "static linking" becomes a lot less less meaningful.

The reasoning behind the LLGPL is informative in this regard.

> > An interesting feature of Common Lisp, is that since it has a standard,
> > a program written conformingly to this standard will run equally on all
> > the conforming implementations. This allows you to choose a different
> > implementation for different phases of a project, or for different
> > deployment strategies.
>
> That is important if indeed it really works.

It seems to work very well.

clisp seems to be the weakest common implementation in this regard. At
least, that's the one I've noticed people having the most issues
porting to/from. Which is a real shame, because it seems to have the
best support on Windows (assuming you're the sort of person who cares
about that sort of thing).

> > The consequence is that it makes the question of an implementation quite
> > irrelevant and not something that you should bother with too early.
>
> Thanks, I realize that now except I don't want to get started with an
> interpreted system and have to spend time later moving to one that compiles
> to an executable.

As others have pointed out, you really aren't going to know enough to
decide which lisp (if any) you want to use until you just buckle down
and start learning one.

I'll go ahead and add another vote to the people recommending
_Practical Common Lisp_. Even just reading through it (without messing
with any of the examples) will give you an excellent overview of a big
chunk of the higher-level aspects of the language. And a pretty good
peek at the lower-level pieces.

Lisp *is* one of the (if not *the*) highest level programming
languages to be discovered yet. But it also has its low-level aspects.
Instead of dealing with pointers, registers, and opcodes, you deal
with cons cells and special operators (if you're so inclined).

BTW, the "common lisp gardeners" recommend starting out with Clozure--
not Clojure, they're very distinct animals--until you know why you
should be using one of the others.

> > Lisp is a late binding language, which allows you to commit to a
> > specific compiler later than most other programming languages.
>
> Excellent

One of the hallmarks of CL is its flexibility.

Anyway, I'll close with just a few random thoughts from other pieces
of this thread that caught my eye:

When you were first stated your criteria, I had pretty much the same
reaction as Mr. Rubin very early on: it sounded like you're looking
for Forth. I understand your reasons for rejecting it, and I've read
some unfortunate things about their community. Still...it might not
hurt to look into it.

I'm a little surprised that no one's mentioned ECL. That may be
exactly what the OP's looking for. (Embedded in this sense refers to
the ease of hiding it in a C program...not in the OP's day job sense).
What am I missing there?

For anyone who's even vaguely interested, I wrote a blog post, based
on my research while I was trying to decide "which lisp." I think it's
an answer to the OP's original request for a side-by-side comparison
(as arrogant of me as that is).
http://www.dotnetmafia.com/blogs/jamesashley/archive/2011/03/11/4471.aspx

It's nothing more than a casual overview. I hope it doesn't seem
overly biased, and that I didn't make too many factual errors (which
is one reason I tried to avoid any facts at all <G>).

Thanks for a great discussion,
James

unread,

Mar 11, 2011, 8:11:40 PM3/11/11

to

Paul Rubin wrote:

> But, it seems to me that Snobol/Spitbol, while technically awesome, are
> absolutely terrible as programming languages by today's standards,
> mainly of historical/retrocomputing interest unless you're a longtime
> user with some legacy code to keep running, or something like that.

Icon is sort of a successor to SNOBOL.

WJ

unread,

Mar 12, 2011, 6:13:25 AM3/12/11

to

Paul Rubin wrote:

> > SNOBOL for scripting
>
> OMG, now THERE's a blast from the past. Really, try something more
> modern, like Python or Ruby, for that sort of thing.

Here's what Paul Graham, author of On Lisp, says about Ruby and
Python:

I like Lisp but my company won't let me use it. What should I do?

Try to get them to let you use Python. Often when your employer
won't let you use Lisp it's because (whatever the official
reason) the guy in charge of your department is afraid of the
way Lisp source code looks. Python looks like an ordinary dumb
language, but semantically it has a lot in common with Lisp, and
has been getting closer to Lisp over time.

They might even let you use Ruby, which is even more Lisp-like.

http://www.paulgraham.com/lispfaq1.html

Antti J Ylikoski

unread,

Mar 12, 2011, 6:37:41 AM3/12/11

to

10.3.2011 21:28, Tim Bradshaw kirjoitti:
> On 2011-03-10 17:46:27 +0000, loca...@example.org said:
>
>> it's how to find comparative information
>> for Lisp beginners. There's too much information in a way.
>
> If you mean "information about how to pick an implentation or dialect"
> then I think the answer is "don't try and make that kind of choice yet".
> As you can probably tell by looking at the responses so far there are
> strong feelings about this kind of thing, which are almost entirely
> irrational (indeed, in some cases you have to wonder about the mental
> state of the people expressing these opinions).
>
> Instead pick *something* and learn it, until you decide if it's what
> you're after. Then make your own decision. I think it is now the case
> that all the implementations of Common Lisp and certainly many
> implementations of Scheme are of very high quality, and there is also
> Clojure which, while neither a CL nor a Scheme also seems to be good, so
> it's more important just to pick one, and learn the language (whichever
> one you choose), and then, later, decide if it suits you when you're in
> a better position to make a choice.
>
> The fear people have is that making the wrong choice will somehow doom
> them, but I don't think this is the case: I would particularly not want
> to use any of the dialects I used when I started learning Lisp (which
> were the only dialects available to me, none of them being really
> anything like a modern Lisp), but I don't think they have somehow warped
> my mind.
>
> So, just pick *something*: it will be OK.
>

Well to my knowledge not all [in this very case, freeware] LISPs are
OK... The day before yesterday I downloaded the GNU CLISP, i. e. the
Posix emulator equipped CLISP, from the GNU site -- and the downloading
process destroyed the contents of my PC's %PATH% environment variable.

I don't know how to return the (very long) original %PATH% -- but this
is not the first crippling bug I have come across in a "free" LISP.

I never encountered any problems with the Clozure Common LISP, BTW.
SBCL would be even better if it had a full-quality Windows port.
Decided to run the Ubuntu Maverick Linux inside the Oracle VM VirtualBox
to get in my hands a quality SBCL implementation.

Just my two cents' worth of opinions from a user.

yours, Antti J Ylikoski
Helsinki, Finland, the E.U.

Pascal J. Bourguignon

unread,

Mar 12, 2011, 10:21:25 AM3/12/11

to

How would that be possible? Well, actually, I don't know anything about
MS-Windows, but on a normal unix system, environment variables just
cannot be destroyed by subprocesses.

I never had any problem with clisp on MS-Windows, be it the native
binaries, or clisp running over cygwin.

> I don't know how to return the (very long) original %PATH% -- but this
> is not the first crippling bug I have come across in a "free" LISP.

I guess on MS-Windows you could always reboot...

> I never encountered any problems with the Clozure Common LISP,
> BTW. SBCL would be even better if it had a full-quality Windows port.
> Decided to run the Ubuntu Maverick Linux inside the Oracle VM
> VirtualBox to get in my hands a quality SBCL implementation.
>
> Just my two cents' worth of opinions from a user.
>
> yours, Antti J Ylikoski
> Helsinki, Finland, the E.U.

--

bluejay7

unread,

Mar 12, 2011, 11:53:45 AM3/12/11

to

On 12 maalis, 17:21, "Pascal J. Bourguignon" <p...@informatimago.com>
wrote:

> Antti J Ylikoski <antti.yliko...@elisanet.fi> writes:
>
>
>
>
>
>
>
>
>
> > 10.3.2011 21:28, Tim Bradshaw kirjoitti:

The MS Windows is not as durable a system as the Unix/Linux/VMUNIX
are.

The value of %Path%, so it seems to me, is stored in a particular
place in the OS (on the hard disk) which will live
from one incarnation of the OS to another. I. e. if the value of %Path
% is ruined then after the reboot
the poor user will get the same ruined value of %Path% again in his
hands, and et cetera ad infinitum.

I just checked this at this very PC with which I'm writing this.

yours sincerely, Antti J Ylikoski
Helsinki, Finland, the E.U.

Raymond Wiker

unread,

Mar 12, 2011, 4:52:29 PM3/12/11

to

bluejay7 <antti.y...@gmail.com> writes:

> The MS Windows is not as durable a system as the Unix/Linux/VMUNIX
> are.
>
> The value of %Path%, so it seems to me, is stored in a particular
> place in the OS (on the hard disk) which will live
> from one incarnation of the OS to another. I. e. if the value of %Path
> % is ruined then after the reboot
> the poor user will get the same ruined value of %Path% again in his
> hands, and et cetera ad infinitum.
>
> I just checked this at this very PC with which I'm writing this.

The deault/startup value of %PATH% is stored somewhere, but changes to
%PATH% do not survive a reboot. If you get a bad %PATH% after a reboot,
it will be because the default/startup value of %PATH% has been
changed. This can happen in a number of ways, including by running an
installer.

The equivalent case under Unix would be if an install script edits the
user's shell initialization files, or (possibly) the system-wide
environment setup.

Tim Bradshaw

unread,

Mar 13, 2011, 8:40:20 AM3/13/11

to

On 2011-03-12 21:52:29 +0000, Raymond Wiker said:

> The equivalent case under Unix would be if an install script edits the
> user's shell initialization files, or (possibly) the system-wide
> environment setup.

Assuming the installer doesn't run as root, it can't do the latter. In
either case some variant of

touch x
<install>
find <appropriate root dir> -newer x

is terribly useful (obviously you get spurious hits, depending on how
noisy the system is).

George Neuner

unread,

Mar 13, 2011, 3:48:13 PM3/13/11

to

On 12 Mar 2011 11:13:25 GMT, "WJ" <w_a_...@yahoo.com> wrote:

>Often when your employer won't let you use Lisp it's because
>(whatever the official reason) the guy in charge of your department
>is afraid of the way Lisp source code looks.

I very much doubt that. An honest manager will tell you the real
problem is the potential difficulty of replacing a Lisp programmer if
there should be a need to do so.

Half-decent C(++) and Java programmers are pretty easy to find, but a
lone Lisper in a non-Lisp shop needs to be a really good programmer.
Really good programmers are not easy to find regardless of language.

George

Pascal J. Bourguignon

unread,

Mar 13, 2011, 4:13:34 PM3/13/11

to

George Neuner <gneu...@comcast.net> writes:

There are two lies there.

Google has no difficulties finding very good programmers. By the
hundreds.

Google still doesn't use lisp.

The first lie is that corporations don't want, in general, good
programmers. They want cheap programmers.

The second lie is that corporations don't want to be ten times better
than the competition (therefore they don't need lisp, and using it would
be bad for them). The problem lies in the Law of Means. Which
basically says that to earn the biggest profit, you must catter the
needs of the average customer, therefore you must provide an average
product.

See "Ainsi marchait l'humanité" by Jean-François Geneste
http://www.amazon.fr/Ainsi-marchait-lhumanit%C3%A9-Jean-Fran%C3%A7ois-Geneste/dp/2756311030/ref=sr_1_1?ie=UTF8&s=books&qid=1240491439&sr=8-1

This explains why we don't have flying cars, why we have Microsoft
Windows, and why lisp is not used in corporations (apart from very
specific, small and temporary exceptions).

The only niche lisp can find is that of a small and beginning start up.
As soon as its size increases or it's bought, its software quality will
have to be averaged down, and any lisp program will be rewritten by
average programmers for an average customer. Because this is where the
most profit is made.

The relative disappearance of lisp in academia and research, is only
symptomatic of the decrease of quality in these areas.

Edmunds Cers

unread,

Mar 13, 2011, 4:22:27 PM3/13/11

to

"Pascal J. Bourguignon" <p...@informatimago.com> writes:

> The only niche lisp can find is that of a small and beginning start up.
> As soon as its size increases or it's bought, its software quality will
> have to be averaged down, and any lisp program will be rewritten by
> average programmers for an average customer. Because this is where the
> most profit is made.

I don't know, this seems like a strange line of reasoning. Couldn't the
company make the same average quality program using Lisp, only with
less resources?

> The relative disappearance of lisp in academia and research, is only
> symptomatic of the decrease of quality in these areas.

Caused by a "democratization" of programming, I'd add.

Pascal J. Bourguignon

unread,

Mar 13, 2011, 4:36:11 PM3/13/11

to

Edmunds Cers <edm...@laivas.lv> writes:

> "Pascal J. Bourguignon" <p...@informatimago.com> writes:
>
>> The only niche lisp can find is that of a small and beginning start up.
>> As soon as its size increases or it's bought, its software quality will
>> have to be averaged down, and any lisp program will be rewritten by
>> average programmers for an average customer. Because this is where the
>> most profit is made.
>
> I don't know, this seems like a strange line of reasoning. Couldn't the
> company make the same average quality program using Lisp, only with
> less resources?

Yes, that'd be a niche, as witnessed by several lispers.

But to a corporation (even a small one), relying on fewer programmers is
higher risk.

It's better to pay S * 6 Java programmers than 2S * 3 average Lisp
programmers or worse, 3S * 2 good Lisp programmers.

Tim Bradshaw

unread,

Mar 13, 2011, 4:48:03 PM3/13/11

to

On 2011-03-13 20:13:34 +0000, Pascal J. Bourguignon said:

> This explains why we don't have flying cars,

I agree pretty much with the rest of your article, but I suspect the
reason we don't have flying cars is that they're not very practical in
terms of energy and so on (though I would like to be proved wrong).

frankenstein

unread,

Mar 13, 2011, 5:45:42 PM3/13/11

to

On Mar 11, 8:25 pm, Bakul Shah <use...@bitblocks.com> wrote:

> On 3/10/11 12:29 PM, localh...@example.org wrote:
>
> > Hi Paul, great questions! This newsgroup is a goldmine!
>
> >> - What languages do you already know? What do you like the most/least
> >> about them and why?
>
> > I work on non x86 hardware and software for my day job. I write assembler
> > and have for many years. I didn't find any language or implementation on the
> > PC I feel gives me all that I want. I don't like C or C++ aesthetically
> > they bother me. I like languages that expose details as much as possible and
> > let you work in small steps rather than higher level ones that do many
> > things to you/for you. I like building my own bits and pieces for long term
> > reuse rather than relying on libraries but when it comes to something like
>
> This makes me think you'd be happier with Scheme. Somewhere else you said
> you like `small, high performance executables'. For that you can use Stalin
> (a slow compiler but it generates very efficient code). You will have to
> stick with R4RS dialect (which is plenty good).

The thing here is: no one uses Stalin and Stalin compile time is
hilarious.

The only way for number crunching is Bigloo because you may specify
types. Every other Scheme is completely uselss in this respect. If all
the Scheme implementors were philosophers, I shall applaud because we
would get something out by having them doing - in they eye of the
uneducated - useless stuff. However, most of the Scheme
implementations are a waste of time and no great a contribution to any
intellectual endeaveor; quite the opposite to philosophy.

Pascal J. Bourguignon

unread,

Mar 13, 2011, 6:06:04 PM3/13/11

to

Tim Bradshaw <t...@tfeb.org> writes:

Yes, but the universe is full of energy. There's no reason each human
could not use exajoules of energy daily if they wanted (agreed, there
are some technological problems to solve, but the energy is there
E=mc²). Besides, energy is spent only when you change altitude, so a
flying car could actually be cheap enough in energy.

Anyways, the question is whether we want to spend your economic
resources in improving 1% the gaz consumption of 200 years old
technology, or whether we want to be slightly smarter, and invent a new
way. In the meantime, I put my money where my mouth is: I don't buy any
car, and almost never use them. But of course, it doesn't matter, by
the "Law of the Means". Manufacturer still produces cars for the
average people.

Bakul Shah

unread,

Mar 13, 2011, 6:28:39 PM3/13/11

to

Look up Terrafugia Transition. They call it a roadable light aircraft
though the media like to call it flying car.

http://www.guardian.co.uk/technology/2011/mar/13/flying-car-transition

TheFlyingDutchman

unread,

Mar 13, 2011, 6:44:08 PM3/13/11

to

>
> Google has no difficulties finding very good programmers. By the
> hundreds.
>

If so, I doubt that is what Google says on their H1-B filings. Google
is a typical US company employing software developers, in that they
tell the US government that they cannot find enough programmers within
the pool that is offered by the 308 million citizens of the United
States (the third most populous country on the earth). They annually
request participation in an exception to US immigration law (H1-B visa
program) that allows them to bring in foreigners for programming jobs.

Tim Bradshaw

unread,

Mar 14, 2011, 6:47:38 AM3/14/11

to

On 2011-03-13 22:06:04 +0000, Pascal J. Bourguignon said:

> es, but the universe is full of energy. There's no reason each human
> could not use exajoules of energy daily if they wanted (agreed, there
> are some technological problems to solve, but the energy is there
> E=mc²).

I guess you're arguing for fusion (fission is only a short-term stopgap
I think as there's not enough fissile material), and that's obviously a
good thing. Of coure we won't get it because we don't have the
political willing. It's always worried me slightly that the only
stable fusion-powered systems we know about are stars: may be fusion
reactors need to be very big...

> Besides, energy is spent only when you change altitude, so a
> flying car could actually be cheap enough in energy.

Well, there are other losses...

Tim Bradshaw

unread,

Mar 14, 2011, 6:48:56 AM3/14/11

to

On 2011-03-13 21:45:42 +0000, frankenstein said:

> The only way for number crunching is Bigloo because you may specify
> types. Every other Scheme is completely uselss in this respect.

Racket has a typed variant (as in fully statically-typed I think). Not
sure the compiler takes advantage of that, but it clearly could.

George Neuner

unread,

Mar 14, 2011, 12:01:49 PM3/14/11

to

On Sun, 13 Mar 2011 21:13:34 +0100, "Pascal J. Bourguignon"
<p...@informatimago.com> wrote:

>George Neuner <gneu...@comcast.net> writes:
>
>> On 12 Mar 2011 11:13:25 GMT, "WJ" <w_a_...@yahoo.com> wrote:
>>
>>>Often when your employer won't let you use Lisp it's because
>>>(whatever the official reason) the guy in charge of your department
>>>is afraid of the way Lisp source code looks.
>>
>> I very much doubt that. An honest manager will tell you the real
>> problem is the potential difficulty of replacing a Lisp programmer if
>> there should be a need to do so.
>>
>> Half-decent C(++) and Java programmers are pretty easy to find, but a
>> lone Lisper in a non-Lisp shop needs to be a really good programmer.
>> Really good programmers are not easy to find regardless of language.
>
>There are two lies there.

You are free to disagree with my opinion, but to say publicly, that I
am lying is potentially libelous.

>Google has no difficulties finding very good programmers. By the
>hundreds.

Really? Does Google truly have hundreds of really good programmers?
Or do they have a handful of experts and an army of decent
implementers?

>Google still doesn't use lisp.

NA

>The first lie is that corporations don't want, in general, good
>programmers. They want cheap programmers.

No, they want *interchangeable* programmers. At the lowest cost, of
course, but the goal is interchangeability with cost being second.

>The second lie is that corporations don't want to be ten times better
>than the competition (therefore they don't need lisp, and using it would
>be bad for them). The problem lies in the Law of Means. Which
>basically says that to earn the biggest profit, you must catter the
>needs of the average customer, therefore you must provide an average
>product.

??? I didn't say anything even remotely connected to this.

George

Paul Rubin

unread,

Mar 14, 2011, 3:42:37 PM3/14/11

to

"Pascal J. Bourguignon" <p...@informatimago.com> writes:

> Google has no difficulties finding very good programmers. By the
> hundreds.
>
> Google still doesn't use lisp.
>
> The first lie is that corporations don't want, in general, good
> programmers. They want cheap programmers.

Google might not use Lisp but it does use Haskell, so I'm not sure how
well the rest of your explanation holds together.

Mario S. Mommer

unread,

Mar 14, 2011, 6:10:11 PM3/14/11

to

Tim Bradshaw <t...@tfeb.org> writes:
> I guess you're arguing for fusion (fission is only a short-term
> stopgap I think as there's not enough fissile material),

It seems fission is going to run out of political steam long before it
runs out of fissile material...

> and that's
> obviously a good thing. Of coure we won't get it because we don't
> have the political willing.

No, as far as I know it is not lack of political will, but lack
of... well. For practical purposes it is impossible, it seems. There was
an article a short while ago, I think in Scientific American, which
described the engineering challenges. They loocked positively
insurmountable. Not as bad as teleportation or warp drive, but still
pretty much impossible.

Tim Bradshaw

unread,

Mar 15, 2011, 3:19:40 AM3/15/11

to

On 2011-03-14 22:10:11 +0000, Mario S. Mommer said:

> It seems fission is going to run out of political steam long before it
> runs out of fissile material...

I suspect the current Japanese thing represents a turning point: after
this it will become politically impossible to build nuclear power
stations, with the standard bad consequences.

Pascal J. Bourguignon

unread,

Mar 15, 2011, 4:04:20 AM3/15/11

to

Tim Bradshaw <t...@tfeb.org> writes:

Yep, we're doomed.

Nicolas Neuss

unread,

Mar 15, 2011, 4:12:19 AM3/15/11

to

I did not read that article, sorry. But this reminds me of Clarke's
First Law:

When a distinguished but elderly scientist states that something is
possible, he is almost certainly right. When he states that something
is impossible, he is very probably wrong.

Nicolas

Ankur

unread,

Mar 15, 2011, 4:31:34 AM3/15/11

to

* Tim Bradshaw <t...@tfeb.org>
> I guess you're arguing for fusion [...]

>
> Of coure we won't get it because we don't have the political
> willing. It's always worried me slightly that the only stable
> fusion-powered systems we know about are stars: may be fusion
> reactors need to be very big...

There is work being done on fusion power:

<http://en.wikipedia.org/wiki/ITER>

--
Ankur

Mario S. Mommer

unread,

Mar 15, 2011, 7:40:08 AM3/15/11

to

Or, alternatively, without the non-standard bad consequences.

Patrick May

unread,

Mar 15, 2011, 11:54:39 AM3/15/11

to

I thought it was because we've seen how people drive in two
dimensions and no one wants the carnage that would ensue from taking it
to three.

Patrick

------------------------------------------------------------------------
http://www.softwarematters.org
Large scale, mission-critical, distributed OO systems design and
implementation. (C++, Java, Common Lisp, Jini, middleware, SOA)

Tim Bradshaw

unread,

Mar 15, 2011, 1:48:08 PM3/15/11

to

On 2011-03-15 11:40:08 +0000, Mario S. Mommer said:

> Or, alternatively, without the non-standard bad consequences.

I don't know if I can parse that, but I'm also not sure if I can now
parse my article that you're following-up to. Anyway my "standard bad
consequences" were meant to be what would follow if we do not use
nuclear power.

Pascal J. Bourguignon

unread,

Mar 15, 2011, 2:23:31 PM3/15/11

to

Patrick May <pat...@softwarematters.org> writes:

> Tim Bradshaw <t...@tfeb.org> writes:
>> On 2011-03-13 20:13:34 +0000, Pascal J. Bourguignon said:
>>> This explains why we don't have flying cars,
>>
>> I agree pretty much with the rest of your article, but I suspect the
>> reason we don't have flying cars is that they're not very practical in
>> terms of energy and so on (though I would like to be proved wrong).
>
> I thought it was because we've seen how people drive in two
> dimensions and no one wants the carnage that would ensue from taking it
> to three.

Who said it was up to people to drive?

Raffael Cavallaro

unread,

Mar 15, 2011, 4:21:24 PM3/15/11

to

On 2011-03-15 04:31:34 -0400, Ankur said:

> There is work being done on fusion power:

Yes, fusion power, like strong AI, is just five years away...

... and has been since 1975!

warmest regards,

Ralph

--
Raffael Cavallaro

Raffael Cavallaro

unread,

Mar 15, 2011, 4:23:36 PM3/15/11

to

On 2011-03-15 14:23:31 -0400, Pascal J. Bourguignon said:

> Who said it was up to people to drive?

In all seriousness, I think it can be argued that we may finally get
flying vehicles now that we have AI good enough to drive them.

Mario S. Mommer

unread,

Mar 15, 2011, 5:02:42 PM3/15/11

to

Raffael Cavallaro <raffaelc...@pas.despam.s.il.vous.plait.mac.com>
writes:

> On 2011-03-15 14:23:31 -0400, Pascal J. Bourguignon said:
>> Who said it was up to people to drive?
> In all seriousness, I think it can be argued that we may finally get
> flying vehicles now that we have AI good enough to drive them.

Yes, although now that it works, it isn't called AI anymore.

Arguably, a autonomous airplane with mammalian payload is safer than an
autonomous land vehicle due to the fact that there is relatively little
unpredictable stuff going on in airspace, and due to the much simpler
structure of the environment. In fact, the space shuttle has been able
for some time to land autonomously all the way from space, but an
autonomous land vehicle cannot reliably cross a desert.

The problem is acceptance by the public.

Robert Uhl

unread,

Apr 4, 2011, 3:56:17 PM4/4/11

to

Paul Rubin <no.e...@nospam.invalid> writes:
>
>>> Or Erlang, if you want massive concurrency.
>> Not until they start selling PCs with 16 sockets...until then I do my
>> massively parallel stuff at work :-)
>
> Parallelism (multiple CPU's) and concurrency (multitasking, like
> having several network connections active at the same time) are not
> the same thing. I just read an interview with someone who wrote a
> BitTorrent client in Erlang and he said Erlang was great for that.

That makes sense. I've been learning a bit of Erlang recently and can
report that it really is a _neat_ little language, with some really good
ideas (e.g. immutability and shared-nothing concurrency) and a few
really bad ones (e.g. the string/list-of-integers congruence). I kinda
like it, although for real work I definitely still prefer CL.

Trying to cast about for a fun little problem to apply it to...

--
Robert A. Uhl

gavino

unread,

Apr 5, 2011, 12:05:03 AM4/5/11

to

On Mar 10, 9:13 am, Peter Keller <psil...@cs.wisc.edu> wrote:
> WJ <w_a_x_...@yahoo.com> wrote:
> > localh...@example.org wrote:
>
> >> Hi guys! Last time I looked at Lisp was mumble years ago. Looks like
> >> alot has changed. I see there are numerous implementations of common
> >> Lisp and there is Scheme and probably tons of other variations I
> >> haven't heard of. Is there any place I could read about what all
> >> these languages and implementations are all about and how to choose
> >> one to get started with? Honestly I'm not sure what I would use it
> >> for but I seem to be attracted to unusual programming languages. I
> >> believe thinking outside the box makes you a better programmer. I am
> >> using Linux if that matters.
>
> >http://groups.google.com/group/comp.lang.lisp/browse_frm/thread/31d55cbe
> > 4b65fd13#
>
> >http://groups.google.com/group/comp.lang.lisp/browse_frm/thread/4021fc01
> > d9955a96#
>
> > Here's what the experts say about Commune Lisp:
>
> [snip]
>
> This poster had Common Lisp get he/she/its daughter pregnant out of
> wedlock or something, so he/she/it will generally disparage Common
> Lisp and its users. However, if you'd like to see the answers to your
> Common Lisp questions in a variety of other languages, he/she/it will
> glady comply. So that's a bonus at least.
>
> -pete

lolz

Brandon Van Every

unread,

Apr 14, 2011, 7:54:08 PM4/14/11

to

On Saturday, March 12, 2011 6:37:41 AM UTC-5, Antti J Ylikoski wrote:
>
> Well to my knowledge not all [in this very case, freeware] LISPs are
> OK... The day before yesterday I downloaded the GNU CLISP, i. e. the
> Posix emulator equipped CLISP, from the GNU site -- and the downloading
> process destroyed the contents of my PC's %PATH% environment variable.

This just happened to me as well, when installing the CLISP 2.49 Windows binary. This bug was filed 16 August 2010; I have now confirmed it. https://sourceforge.net/tracker/index.php?func=detail&aid=3046401&group_id=1355&atid=101355

> I don't know how to return the (very long) original %PATH%

Fortunately I noticed this before I rebooted. If you notice it in time, you may be able to recover a copy of an older path by starting regedit and looking under HKLM\System\ControlSetXXX\Control\Session Manager\Environment\Path, where "XXX" is a number such as "004". Otherwise once you reboot you are SOL.

> -- but this
> is not the first crippling bug I have come across in a "free" LISP.
>
> I never encountered any problems with the Clozure Common LISP, BTW.
> SBCL would be even better if it had a full-quality Windows port.

I've been trying to run cl-bench on Windows. So far, Clozure CL and Cygwin CLISP 2.48 will run it. The CLISP 2.49 Windows binary, SBCL, Allegro CL 8.2 Express Edition, and Lispworks 6.0.1 Personal Edition will not. More details at http://www.cliki.net/Performance_Benchmarks .

Cheers,
Brandon Van Every