[pro] Learning Lisp the Bump Free Way

[Alessio Stalla]

On Thu, Jan 20, 2011 at 5:04 PM, Alexander Repenning
<ralex at cs.colorado.edu> wrote:
> One point made:
>
>> It’s probably faster than most dynamic languages.
>
> is still mostly true but as I am tracking the speed of JavaScript versus Common Lisp I can see a scary performance cross over point > in the near future (months).

Are there big systems written in JS? I'm not aware of any. It would be
interesting to compare big, real-world production systems in both
languages; I suspect CL would win outright. I'm also interested in how
these dynamic languages perform in a multithreading context. As far as
I know, both Python and Ruby (in their C implementation) suffer from
the "global interpreter lock" i.e. are basically single-threaded; and
JavaScript is single-threaded as well in browsers, its most common
environment.

> Already, in some of our benchmarks JavaScript running in OS X Chrome is getting very close (10% gap) to Clozure Common Lisp. Why is that? Common Lisp has gone STALE. The Common Lisp community preserves Lisp instead of advancing it. The result: flatline! As far as I can tell non of the exciting JIT compiler technologies developed in the last couple of years have made it into any CL implementation. If you follow this trend you may conclude the right thing to do, if you want to continue to use Lisp, would be to compile it down to JavaScript, yes, JavaScript, not C or direct to binary.

I don't see how compiling it to JS is supposed to be better than
compiling to C (or even Java bytecode). JIT compilation is certainly
very powerful, but JS is very dynamic and has no provisions for type
annotations (heck, it doesn't even have a type system, as far as I
know). Anyway, a subset of CL already compiles to JS (Parenscript).

> Same thing with IDEs: stale, flatline.. Perhaps with the exception of LispWorks it appears that most Lisp programmers are just fine > with Emacs. Well, Emacs was great 35 years ago. Remember the actually innovative IDEs of Lisp on Lisp machines? Is SLIME really the best we can do now? Take Clozure CL. As far as I can tell most people, including some the developers perhaps, are using SLIME too. Start using something new. For instance start using the Cocoa based CCL IDE. Yes, still primitive but with real opportunities to create some fine IDE tools that actually would look OK even to a 21 Century computer science students. Nowadays, even browser (e.g., Safari and FireFox) have debugging tools built in that make SLIME look like last century technology that belongs to a computer museum.

Emacs+SLIME is not the best possible IDE for sure; but it's enough of
a sweet spot that there's little push for developing a (free)
alternative while there's a lot of work to do in other areas. Also,
apart from Java, C#, VB.NET and perhaps Objective-C (which are all
commercially supported), no language - especially dynamic ones - has a
native IDE that is superior to Emacs+SLIME. What is the IDE of choice
for Javascript? Python? Ruby? PHP? Haskell? C? I suspect most people
use either generic editors like vim or Emacs, or "foreign" IDEs like
Eclipse or IntelliJ IDEA that happen to have a plugin for their
language of choice.

> The Lisp community is not only small but also fragmented. The 21 century computer science world need no more essays explaining > why Common Lisp is the way it is (stale). It is time to leap into action and to IMPLEMENT stuff that is not just interesting to the Common Lisp community but to computer science in general. Play with Clozure Common Lisp the IDE version (Mac and Window). Do > not just get frustrated and switch back to Slime but ask yourself "what can YOU do for Common Lisp (or more specifically CCL) to make it cool again"

We have different opinions; I don't think developing free IDEs is
worth the effort. I think developing libraries and applications is far
more needed for Lisp to succeed. IDEs are big projects that are best
done by commercial companies or by big groups of volunteers. For any
of those to show up, the community needs to be much bigger, so that
the IDE has many potential users.

Regards,
Alessio