<?xml version="1.0" encoding="UTF-8"?><rss version="2.0"
	xmlns:content="http://purl.org/rss/1.0/modules/content/"
	xmlns:dc="http://purl.org/dc/elements/1.1/"
	xmlns:atom="http://www.w3.org/2005/Atom"
	>
<channel>
	<title>Comments on: Rant about Common Lisp and implementations</title>
	<atom:link href="http://eli.thegreenplace.net/2007/08/20/rant-about-common-lisp-and-implementations/feed/" rel="self" type="application/rss+xml" />
	<link>http://eli.thegreenplace.net/2007/08/20/rant-about-common-lisp-and-implementations/</link>
	<description>Eli Bendersky's personal website</description>
	<pubDate>Tue, 07 Oct 2008 09:35:22 +0000</pubDate>
	<generator>http://wordpress.org/?v=2.6.2</generator>
		<item>
		<title>By: Daniel Weinreb</title>
		<link>http://eli.thegreenplace.net/2007/08/20/rant-about-common-lisp-and-implementations/#comment-120897</link>
		<dc:creator>Daniel Weinreb</dc:creator>
		<pubDate>Sat, 10 May 2008 12:58:40 +0000</pubDate>
		<guid isPermaLink="false">http://eli.thegreenplace.net/2007/08/20/rant-about-common-lisp-and-implementations/#comment-120897</guid>
		<description>There are a lot of good points above.  As one of the Common Lisp designers, I try hard not to be a partisan.  I've learned over the years that being a language bigot is a very bad idea.  Based on what I've read above, I want to learn about Newlisp.

Documentation: The open source implementors don't seem to put a lot of attention into documentation.  I'd like to see what LispWorks and Allegro provide, though.  As for the language itself (as opposed to any one implementation), "Practical Common Lisp" is a great textbook.  However, the ANSI standard, even the very improved HyperSpec from Kent Pitman, is pretty bad.  (Personally, I liked "The Lisp Machine Manual" a lot, but I wrote half of it so I'm not totally unbiased.)  A new version of "Common Lisp: The Langauge" that was updated to the X3J13 standard would be great.  More online documentation would be nice, too.  There are some good Emacs commands around that access the HyperSpec (I think this is all in Slime) for those of you who like Emacs, so that's better than nothing.

Many implementations: As was pointed out, this is the norm for older languages.  Even Python has several implementations (Jython, IronPython), for good reasons.  The Lisp implementations vary in many ways; see my survey paper at 

http://common-lisp.net/~dlw/LispSurvey.html

And I didn't do any benchmarking there.  For example, some implementations have highly optimized bignums (arbitrary precision integer arithmetic) and others don't; only some people care about that.

Windows: More than half (six of eleven) of the current implementations run on Windows.  Some of the others are working on it.  Corman Common Lisp is quite interesting in that it ONLY runs on Windows, and has many useful features to fit into the Microsoft ecosystem, for those who are interested in that.  I think all the others were originally for Linux/Unix and then were ported to Windows.  Again, LispWorks and Allegro may do a great job; I've never used them, but these guys are real pro's in a for-money business, so they have serious motivation as well as high-quality hackers.

Libraries: Yes, there should be a centralized source a la CPAN.  Marco Baringer and the Clozure guys have finally announced CLornucopia, which is just getting started.  I think it will be the answer to this very important requirement.  It's not ready to be used yet (it's in alpha and lots of projected cool features haven't been done yet), but it's on its way.</description>
		<content:encoded><![CDATA[<p>There are a lot of good points above.  As one of the Common Lisp designers, I try hard not to be a partisan.  I&#8217;ve learned over the years that being a language bigot is a very bad idea.  Based on what I&#8217;ve read above, I want to learn about Newlisp.</p>
<p>Documentation: The open source implementors don&#8217;t seem to put a lot of attention into documentation.  I&#8217;d like to see what LispWorks and Allegro provide, though.  As for the language itself (as opposed to any one implementation), &#8220;Practical Common Lisp&#8221; is a great textbook.  However, the ANSI standard, even the very improved HyperSpec from Kent Pitman, is pretty bad.  (Personally, I liked &#8220;The Lisp Machine Manual&#8221; a lot, but I wrote half of it so I&#8217;m not totally unbiased.)  A new version of &#8220;Common Lisp: The Langauge&#8221; that was updated to the X3J13 standard would be great.  More online documentation would be nice, too.  There are some good Emacs commands around that access the HyperSpec (I think this is all in Slime) for those of you who like Emacs, so that&#8217;s better than nothing.</p>
<p>Many implementations: As was pointed out, this is the norm for older languages.  Even Python has several implementations (Jython, IronPython), for good reasons.  The Lisp implementations vary in many ways; see my survey paper at </p>
<p><a href="http://common-lisp.net/~dlw/LispSurvey.html" rel="nofollow">http://common-lisp.net/~dlw/LispSurvey.html</a></p>
<p>And I didn&#8217;t do any benchmarking there.  For example, some implementations have highly optimized bignums (arbitrary precision integer arithmetic) and others don&#8217;t; only some people care about that.</p>
<p>Windows: More than half (six of eleven) of the current implementations run on Windows.  Some of the others are working on it.  Corman Common Lisp is quite interesting in that it ONLY runs on Windows, and has many useful features to fit into the Microsoft ecosystem, for those who are interested in that.  I think all the others were originally for Linux/Unix and then were ported to Windows.  Again, LispWorks and Allegro may do a great job; I&#8217;ve never used them, but these guys are real pro&#8217;s in a for-money business, so they have serious motivation as well as high-quality hackers.</p>
<p>Libraries: Yes, there should be a centralized source a la CPAN.  Marco Baringer and the Clozure guys have finally announced CLornucopia, which is just getting started.  I think it will be the answer to this very important requirement.  It&#8217;s not ready to be used yet (it&#8217;s in alpha and lots of projected cool features haven&#8217;t been done yet), but it&#8217;s on its way.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Daniel Weinreb</title>
		<link>http://eli.thegreenplace.net/2007/08/20/rant-about-common-lisp-and-implementations/#comment-99088</link>
		<dc:creator>Daniel Weinreb</dc:creator>
		<pubDate>Wed, 16 Jan 2008 11:23:31 +0000</pubDate>
		<guid isPermaLink="false">http://eli.thegreenplace.net/2007/08/20/rant-about-common-lisp-and-implementations/#comment-99088</guid>
		<description>I've written extensively elsewhere, so I'll keep this short. Check out  &lt;a href="http://common-lisp.net/~dlw/LispSurvey.html" rel="nofollow"&gt;survey&lt;/a&gt; to learn about the implementations and get plenty of links to textbooks, Wiki's, libraries, and so on.  Check out this &lt;a href="http://dlweinreb.wordpress.com/2007/12/25/complaints-im-seeing-about-common-lisp/" rel="nofollow"&gt;blog posting&lt;/a&gt; for my feelings about Common Lisp's general drawbacks.  Yes, the situation with free implementations for Windows is not as good as the situation for non-free for Windows, or free for non-Windows.  Yes, the library situation needs a lot of improvement, which may actually happen; there are people thinking about it and trying to pull together resources to fix it.</description>
		<content:encoded><![CDATA[<p>I&#8217;ve written extensively elsewhere, so I&#8217;ll keep this short. Check out  <a href="http://common-lisp.net/~dlw/LispSurvey.html" rel="nofollow">survey</a> to learn about the implementations and get plenty of links to textbooks, Wiki&#8217;s, libraries, and so on.  Check out this <a href="http://dlweinreb.wordpress.com/2007/12/25/complaints-im-seeing-about-common-lisp/" rel="nofollow">blog posting</a> for my feelings about Common Lisp&#8217;s general drawbacks.  Yes, the situation with free implementations for Windows is not as good as the situation for non-free for Windows, or free for non-Windows.  Yes, the library situation needs a lot of improvement, which may actually happen; there are people thinking about it and trying to pull together resources to fix it.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Robert Goldman</title>
		<link>http://eli.thegreenplace.net/2007/08/20/rant-about-common-lisp-and-implementations/#comment-80949</link>
		<dc:creator>Robert Goldman</dc:creator>
		<pubDate>Fri, 26 Oct 2007 16:23:53 +0000</pubDate>
		<guid isPermaLink="false">http://eli.thegreenplace.net/2007/08/20/rant-about-common-lisp-and-implementations/#comment-80949</guid>
		<description>First, I must agree with wkempf --- you have extrapolated from a few, relatively new languages to a generalization about what is normal.  It is &lt;em&gt;not&lt;/em&gt; normal to have a single implementation for a language.  Yes, that's true of the modern scripting languages --- perl. ruby, and python --- and of the proprietary languages --- C#, Visual Basic, and (somewhat) Java.  But it most certainly is &lt;em&gt;not&lt;/em&gt; true of the most popular and well-established programming languages: C++, C, Fortran, COBOL, Pascal, Common Lisp, Scheme, etc.

A second point that seems very odd is your proposed requirement that "If you want a library that does *whatever*, you can easily download it from some central repository and install it, &lt;em&gt;without the need to compile anything with your own compiler&lt;/em&gt;.[my emphasis]"  With all due respect, this seems to be totally missing the point of dynamic languages like Common Lisp, Scheme, etc.  A huge advantage of these languages is that &lt;em&gt;you always have the compiler there to help you&lt;/em&gt;.  Why on earth would you &lt;em&gt;want&lt;/em&gt; a library distributed as object code, if you could get the source?  You are never going to use CL without the compiler.  That's the beauty of it.

For that matter, perl has been exquisitely successful with a huge volume of source-form libraries through CPAN.  Yes, you can ignore the fact that you are getting source (but you can ignore that with ASDF-INSTALL, as well), but you are nevertheless....

I think what you &lt;em&gt;really&lt;/em&gt; want is an environment that makes it easy for you to not worry about the fact that you're getting source libraries.  That environment, as others have pointed out, is Linux with SBCL, because that's the place where the overwhelming preponderance of the CL libraries are developed and tested.  There just aren't enough users out there to test them on some of the others.

I understand that you would rather be able to use Windows, but that's the price you pay for demanding open source, free software.  You get the software that people want to write, for the platforms those people enjoy.  The people who write Lisp libraries overwhelmingly prefer to code on Unix variants like Linux and MacOS.

If you want a well-supported Common Lisp for Windows, feel free to pay some money to LispWorks or Franz.  Both of them offer excellent products for that platform.  They each offer free trial versions of their software for you to test out, or for you to use as tools for learning the language.  These software packages will install smoothly, come with substantial support libraries (not portable, though), have IDEs, and will Just Work.  The more I think about it, the more I think you should just download one of these and take it for a spin, instead of raising your blood pressure.

If you want free as in freedom, you are going to have to either bend to the preferences of the people who write the free code, or you will have to port the stuff yourself.</description>
		<content:encoded><![CDATA[<p>First, I must agree with wkempf &#8212; you have extrapolated from a few, relatively new languages to a generalization about what is normal.  It is <em>not</em> normal to have a single implementation for a language.  Yes, that&#8217;s true of the modern scripting languages &#8212; perl. ruby, and python &#8212; and of the proprietary languages &#8212; C#, Visual Basic, and (somewhat) Java.  But it most certainly is <em>not</em> true of the most popular and well-established programming languages: C++, C, Fortran, COBOL, Pascal, Common Lisp, Scheme, etc.</p>
<p>A second point that seems very odd is your proposed requirement that &#8220;If you want a library that does *whatever*, you can easily download it from some central repository and install it, <em>without the need to compile anything with your own compiler</em>.[my emphasis]&#8221;  With all due respect, this seems to be totally missing the point of dynamic languages like Common Lisp, Scheme, etc.  A huge advantage of these languages is that <em>you always have the compiler there to help you</em>.  Why on earth would you <em>want</em> a library distributed as object code, if you could get the source?  You are never going to use CL without the compiler.  That&#8217;s the beauty of it.</p>
<p>For that matter, perl has been exquisitely successful with a huge volume of source-form libraries through CPAN.  Yes, you can ignore the fact that you are getting source (but you can ignore that with ASDF-INSTALL, as well), but you are nevertheless&#8230;.</p>
<p>I think what you <em>really</em> want is an environment that makes it easy for you to not worry about the fact that you&#8217;re getting source libraries.  That environment, as others have pointed out, is Linux with SBCL, because that&#8217;s the place where the overwhelming preponderance of the CL libraries are developed and tested.  There just aren&#8217;t enough users out there to test them on some of the others.</p>
<p>I understand that you would rather be able to use Windows, but that&#8217;s the price you pay for demanding open source, free software.  You get the software that people want to write, for the platforms those people enjoy.  The people who write Lisp libraries overwhelmingly prefer to code on Unix variants like Linux and MacOS.</p>
<p>If you want a well-supported Common Lisp for Windows, feel free to pay some money to LispWorks or Franz.  Both of them offer excellent products for that platform.  They each offer free trial versions of their software for you to test out, or for you to use as tools for learning the language.  These software packages will install smoothly, come with substantial support libraries (not portable, though), have IDEs, and will Just Work.  The more I think about it, the more I think you should just download one of these and take it for a spin, instead of raising your blood pressure.</p>
<p>If you want free as in freedom, you are going to have to either bend to the preferences of the people who write the free code, or you will have to port the stuff yourself.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Jeff</title>
		<link>http://eli.thegreenplace.net/2007/08/20/rant-about-common-lisp-and-implementations/#comment-67055</link>
		<dc:creator>Jeff</dc:creator>
		<pubDate>Mon, 27 Aug 2007 12:58:01 +0000</pubDate>
		<guid isPermaLink="false">http://eli.thegreenplace.net/2007/08/20/rant-about-common-lisp-and-implementations/#comment-67055</guid>
		<description>newLisp has reference passing.  You can pass by symbol and evaluate the symbol or you can wrap the data in a context functor.  Rather than:

&lt;code&gt;(set 'foo '(large list))
(apply bar foo)&lt;/code&gt;

...you instead use the context and functor (a context with an internal symbol of the same name, such as context foo, internal symbol foo):

&lt;code&gt;(set 'foo:foo '(large list))
(apply bar foo)&lt;/code&gt;

I agree that a language should have a base implementation from which fork other, more use-specific implementations.  While I personally wouldn't use Windows, a lot of people do.  Any language that does not aim to be truly cross-platform, without a lot of work on the part of the user, is not going to gain a lot of adherents.

CL suffers from academia in this respect; there are too many affluent common lispers with the attitude that if it were easy then anyone, even undesirable people, could use the language (including, god forbid, people who aren't computer scientists).

Scheme is slightly better in that respect in that it has a series of add-on standards that each distribution can implement.  Each implementation typically lists which parts of the language it has so that it is much easier to find a language to use.

Scheme's big win over CL is it's documentation.  That is the real key for new users of a language.  Better online documentation is make-or-break for many users.  Starting with CL is very difficult because of very sparse documentation, which then doesn't apply uniformally.  Scheme has very nice documentation, and each language tends to have useful docs which highlight what it does and does not implement as well as extensions to the standard.

newLisp has some of the best documentation of any Lisp I've found.  It has a listing of every function with example code.  Contrast that with CL docs, which typically spend more time explaining changes to the function throughout the years than how to actually use a function.</description>
		<content:encoded><![CDATA[<p>newLisp has reference passing.  You can pass by symbol and evaluate the symbol or you can wrap the data in a context functor.  Rather than:</p>
<p><code>(set 'foo '(large list))<br />
(apply bar foo)</code></p>
<p>&#8230;you instead use the context and functor (a context with an internal symbol of the same name, such as context foo, internal symbol foo):</p>
<p><code>(set 'foo:foo '(large list))<br />
(apply bar foo)</code></p>
<p>I agree that a language should have a base implementation from which fork other, more use-specific implementations.  While I personally wouldn&#8217;t use Windows, a lot of people do.  Any language that does not aim to be truly cross-platform, without a lot of work on the part of the user, is not going to gain a lot of adherents.</p>
<p>CL suffers from academia in this respect; there are too many affluent common lispers with the attitude that if it were easy then anyone, even undesirable people, could use the language (including, god forbid, people who aren&#8217;t computer scientists).</p>
<p>Scheme is slightly better in that respect in that it has a series of add-on standards that each distribution can implement.  Each implementation typically lists which parts of the language it has so that it is much easier to find a language to use.</p>
<p>Scheme&#8217;s big win over CL is it&#8217;s documentation.  That is the real key for new users of a language.  Better online documentation is make-or-break for many users.  Starting with CL is very difficult because of very sparse documentation, which then doesn&#8217;t apply uniformally.  Scheme has very nice documentation, and each language tends to have useful docs which highlight what it does and does not implement as well as extensions to the standard.</p>
<p>newLisp has some of the best documentation of any Lisp I&#8217;ve found.  It has a listing of every function with example code.  Contrast that with CL docs, which typically spend more time explaining changes to the function throughout the years than how to actually use a function.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Jon Harrop</title>
		<link>http://eli.thegreenplace.net/2007/08/20/rant-about-common-lisp-and-implementations/#comment-66528</link>
		<dc:creator>Jon Harrop</dc:creator>
		<pubDate>Fri, 24 Aug 2007 08:18:09 +0000</pubDate>
		<guid isPermaLink="false">http://eli.thegreenplace.net/2007/08/20/rant-about-common-lisp-and-implementations/#comment-66528</guid>
		<description>If you're using Windows then I would strongly recommend using native Windows software and, in particular, .NET. Microsoft's F# programming language is a modern functional programming language neatly integrated into their flagship platform, for example.</description>
		<content:encoded><![CDATA[<p>If you&#8217;re using Windows then I would strongly recommend using native Windows software and, in particular, .NET. Microsoft&#8217;s F# programming language is a modern functional programming language neatly integrated into their flagship platform, for example.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Mark</title>
		<link>http://eli.thegreenplace.net/2007/08/20/rant-about-common-lisp-and-implementations/#comment-66287</link>
		<dc:creator>Mark</dc:creator>
		<pubDate>Wed, 22 Aug 2007 19:27:57 +0000</pubDate>
		<guid isPermaLink="false">http://eli.thegreenplace.net/2007/08/20/rant-about-common-lisp-and-implementations/#comment-66287</guid>
		<description>You made some excellent points here. 

It drives me crazy when people  say things like "Windows is dead."  Get your head out of your ass.  I'm no Windows-lover, but this is simply ignoring reality.  LOTS of people use Windows and you can bet that the popularity of a tool/framework/language can only be helped by making it available on Windows.  

I agree that there should be an easy installation/setup for Windows that allows newbies to do something productive with CL.  As some people have pointed out, several of the Linux distributions have used some form of apt-get to automate the installation of add-on libraries to CL installations under Linux.  That's great, but there has got to be a way that will work on other systems.  I've tried using asdf to install libraries on CL installations and it has failed enough times (with some obscure error message) to make the process less-than-pleasant.

It's almost like there is a "rite of passage" for people who want to use CL.  I can only imagine the number of people who give up quickly because it can been too hard to get started with CL and produce something useful.</description>
		<content:encoded><![CDATA[<p>You made some excellent points here. </p>
<p>It drives me crazy when people  say things like &#8220;Windows is dead.&#8221;  Get your head out of your ass.  I&#8217;m no Windows-lover, but this is simply ignoring reality.  LOTS of people use Windows and you can bet that the popularity of a tool/framework/language can only be helped by making it available on Windows.  </p>
<p>I agree that there should be an easy installation/setup for Windows that allows newbies to do something productive with CL.  As some people have pointed out, several of the Linux distributions have used some form of apt-get to automate the installation of add-on libraries to CL installations under Linux.  That&#8217;s great, but there has got to be a way that will work on other systems.  I&#8217;ve tried using asdf to install libraries on CL installations and it has failed enough times (with some obscure error message) to make the process less-than-pleasant.</p>
<p>It&#8217;s almost like there is a &#8220;rite of passage&#8221; for people who want to use CL.  I can only imagine the number of people who give up quickly because it can been too hard to get started with CL and produce something useful.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: m i c h a e l</title>
		<link>http://eli.thegreenplace.net/2007/08/20/rant-about-common-lisp-and-implementations/#comment-66117</link>
		<dc:creator>m i c h a e l</dc:creator>
		<pubDate>Wed, 22 Aug 2007 10:50:14 +0000</pubDate>
		<guid isPermaLink="false">http://eli.thegreenplace.net/2007/08/20/rant-about-common-lisp-and-implementations/#comment-66117</guid>
		<description>Hi Eli,

Sorry if it seemed like you were being accused of bashing newLISP. Based on this and your earlier post, I can see you have been quite complimentary of the language. Unfortunately, the pejorative connotations of the word 'inferior' conjure up images of an 'elite' that degrades others by referring to them as 'inferior.' Not, I think, what you intended. Who knows, maybe we newLISPers just have an inferiority complex ;-)


m i c h a e l</description>
		<content:encoded><![CDATA[<p>Hi Eli,</p>
<p>Sorry if it seemed like you were being accused of bashing newLISP. Based on this and your earlier post, I can see you have been quite complimentary of the language. Unfortunately, the pejorative connotations of the word &#8216;inferior&#8217; conjure up images of an &#8216;elite&#8217; that degrades others by referring to them as &#8216;inferior.&#8217; Not, I think, what you intended. Who knows, maybe we newLISPers just have an inferiority complex <img src='http://eli.thegreenplace.net/wp-includes/images/smilies/icon_wink.gif' alt=';-)' class='wp-smiley' /> </p>
<p>m i c h a e l</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: eliben</title>
		<link>http://eli.thegreenplace.net/2007/08/20/rant-about-common-lisp-and-implementations/#comment-66048</link>
		<dc:creator>eliben</dc:creator>
		<pubDate>Wed, 22 Aug 2007 03:05:47 +0000</pubDate>
		<guid isPermaLink="false">http://eli.thegreenplace.net/2007/08/20/rant-about-common-lisp-and-implementations/#comment-66048</guid>
		<description>I did not mean to bash Newlisp, not at all. I wrote quite favorably about it in this post and before. But its core language *is* inferior to Common Lisp and Scheme, there's no doubt in that. Especially some key things like lexical binding and by-reference parameter passing which aren't available "natively" but only through concepts.

See also my post and the comments on it here: http://eli.thegreenplace.net/2006/04/20/newlisp-an-intriguing-dialect-of-lisp/</description>
		<content:encoded><![CDATA[<p>I did not mean to bash Newlisp, not at all. I wrote quite favorably about it in this post and before. But its core language *is* inferior to Common Lisp and Scheme, there&#8217;s no doubt in that. Especially some key things like lexical binding and by-reference parameter passing which aren&#8217;t available &#8220;natively&#8221; but only through concepts.</p>
<p>See also my post and the comments on it here: <a href="http://eli.thegreenplace.net/2006/04/20/newlisp-an-intriguing-dialect-of-lisp/" rel="nofollow">http://eli.thegreenplace.net/2006/04/20/newlisp-an-intriguing-dialect-of-lisp/</a></p>
]]></content:encoded>
	</item>
	<item>
		<title>By: wkempf</title>
		<link>http://eli.thegreenplace.net/2007/08/20/rant-about-common-lisp-and-implementations/#comment-65976</link>
		<dc:creator>wkempf</dc:creator>
		<pubDate>Tue, 21 Aug 2007 20:48:42 +0000</pubDate>
		<guid isPermaLink="false">http://eli.thegreenplace.net/2007/08/20/rant-about-common-lisp-and-implementations/#comment-65976</guid>
		<description>C/C++ don't have a "base" implementation.  GCC is just one of many implementations, and not necessarily even the most popular/used, especially if you're talking about for any given platform.  For example, it's most definately not the most popular/used implementation on Windows.</description>
		<content:encoded><![CDATA[<p>C/C++ don&#8217;t have a &#8220;base&#8221; implementation.  GCC is just one of many implementations, and not necessarily even the most popular/used, especially if you&#8217;re talking about for any given platform.  For example, it&#8217;s most definately not the most popular/used implementation on Windows.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Richard Cook</title>
		<link>http://eli.thegreenplace.net/2007/08/20/rant-about-common-lisp-and-implementations/#comment-65975</link>
		<dc:creator>Richard Cook</dc:creator>
		<pubDate>Tue, 21 Aug 2007 20:47:51 +0000</pubDate>
		<guid isPermaLink="false">http://eli.thegreenplace.net/2007/08/20/rant-about-common-lisp-and-implementations/#comment-65975</guid>
		<description>SBCL on Linux is "where the action is". There are adequate versions for Windows and Mac OS X, but I have trouble with asdf-install on Windows and neither the Windows or OS X has multithreading.

I'd say the most painless way to SBCL on Linux is get Knoppix on a CD-ROM and a small external USB hard disk. Boot from Knoppix and set up a "permanent home partition" on the external hard disk, then from now on boot with the "knoppix home=..." options. You can do more than just a home directory, you can install software into /bin, change files in /etc and the knoppix "union" file system merges your changes with the Knoppix on the CD-ROM. If you have the RAM you can also run some Linuxes in partitions with QEmu or the like.

The above is theoretical for me - I have a Mac, and what I do is have a Parallels VM set up with a small "hard disk", 5 gig, and boot from a Knoppix .ISO file in Parallels. This keeps the overall file sizes small, and upgrades to the next Knoppix will just be a matter of pointing to a different .ISO file.</description>
		<content:encoded><![CDATA[<p>SBCL on Linux is &#8220;where the action is&#8221;. There are adequate versions for Windows and Mac OS X, but I have trouble with asdf-install on Windows and neither the Windows or OS X has multithreading.</p>
<p>I&#8217;d say the most painless way to SBCL on Linux is get Knoppix on a CD-ROM and a small external USB hard disk. Boot from Knoppix and set up a &#8220;permanent home partition&#8221; on the external hard disk, then from now on boot with the &#8220;knoppix home=&#8230;&#8221; options. You can do more than just a home directory, you can install software into /bin, change files in /etc and the knoppix &#8220;union&#8221; file system merges your changes with the Knoppix on the CD-ROM. If you have the RAM you can also run some Linuxes in partitions with QEmu or the like.</p>
<p>The above is theoretical for me - I have a Mac, and what I do is have a Parallels VM set up with a small &#8220;hard disk&#8221;, 5 gig, and boot from a Knoppix .ISO file in Parallels. This keeps the overall file sizes small, and upgrades to the next Knoppix will just be a matter of pointing to a different .ISO file.</p>
]]></content:encoded>
	</item>
</channel>
</rss>
