A Video Tutorial of SLIME

An anonymous reader writes "Ok, maybe I exaggerated a bit with the subject; however, you can check it out for yourself and decide. Marco Baringer has published a video (.mov available for the bittorent impaired) showing off the Common Lisp IDE SLIME. It's a long movie (almost an hour) and provides an in-depth description of many of SLIMES's features which just aren't available (or even possible) in 'modern' IDEs/languages."

Comments

That's nice....

[jericho4.0]

but what I really need is a decent Haskell IDE (that's hopefully not emacs).

Can anyone point out any strong advantages Lisp has over more modern functional languages? I've been learning Haskell, and really enjoying it, and wouldn't mind another FP language...I was thinking O'Caml, for performance reasons.

On the subject of those wacky FP languages, here's something I ran across last night, quicksort in 'J';

qsort =: id ` (($: o selLEF),first,($: o selGTF)) choose notEmpty

'$' is the self reference operator, making this an anonymous recursive function. Pretty cool.

Re:That's nice....

[Anonymous Coward]

Can anyone point out any strong advantages Lisp has over more modern functional languages?

-1. (Aside: Lisp can be used for functional programming. It is NOT a purely functional (it does not strive to be side-effect free in everything) programming language like Haskell.)

0. (Aside: "More modern?" - lisp started a long time ago but has been evolving continuously. The latest Lisp standard is from the 1990s, not the newest standard, but hardly "old")

1. It's dynamically latently strongly typed with optional static typing (popular compilers do type inferencing). (let the flamewars begin). latent: values have types. dynamic: types are available and if necessary checked at run time (if necessary! compilers like CMUCL make use of type information at compile time for static typing!) Strong: type system can't be violated like in C.

2. It's got nice, uniform syntax. This is mostly just a preference thing, I HATE complicated syntax and just can't sympathise with people who like, say, Haskell or C++ syntax, but I know other people feel just the opposite. With languages with more complicated syntax, I have to mentally maintain an image of the real program tree, lisp just is the tree (context: other languages I find pleasant to read are APL (with the original charset so the meanings aren't obscured!) and Forth). The uniform syntax also makes the "symbolic macros" (NOT like C macros!) characteristic of advanced lisp code easy.

3. It's a beautiful meta-language. Meta-language? Lisp is mostly a language for writing domain-specific languages in. An idiomatic lisp program extends the language in the direction of the problem domain (a characteristic shared with Forth). It's a playground for new programming paradigms.

4. It's got one of the most powerful generic-function ("multimethod") object oriented programming systems around (CLOS), even more powerful with the de-facto standard meta-object programming system (MOP) that allows you to fuck around with the object system and make strange programming paradigms like "Cells" (auto-updating members of objects that work like spreadsheet cells).

Re:That's nice....

[Anonymous Coward]

One seldom mentioned but cool other feature: The condition system. Think like exceptions, but when they are thrown, the catcher may be presented with a list of options ("restarts") from the thrower that are the thrower asking the catcher "okay, I'm stuck, which of these should I do, smart guy?", and the catcher can pick one to return control to the thrower, informing the thrower how it is to proceed. This makes dealing safely with external transactional systems much less hazardous, and is great at the interactive REPL prompt (really a bit like the unix shell prompt, if you think back to the days there were entire lisp machines) - in that case the "catcher" is you. e.g. So if you make a typo in a filename input, you'll get a "file not found" condition, with 2 potential restarts "try this other filename" and "abort".

(be careful of using "throw" and "catch" terminology though once in LispLand, in Lisp they mean something different, a low level feature close to goto/setjmp/longjmp in C)

Each time I use exceptions I feel like banging my head against a wall, they're very much "half-assed" compared to conditions.

Re:That's nice....

[aCapitalist]

It's funny you bring that up because over at lamda-the-ultimate all the Smug Lisp Weenies (TM) have been replaced by Smug Haskell Weenies.

I'll never dig Lisp/Scheme prefix notation so I'll probably take a look at Haskell or O'Caml eventually.

Emacs and Vim (I love vim) just aren't suited for IDEs. They're still stuck in a console world no matter what kind of gui is slapped on the front end. Last time I checked Emacs/Xemacs on Unix still didn't have xft fonts, and Vim has so many obscure platforms it supports that it's limited on what it can do.

Re:That's nice....

[jericho4.0]

Actually, it was reading lamda-the-ultimate that motivated me to learn Haskell. I was sick of reading about all those cool features and having most of it go over my head. I had done some Lisp in school, but didn't grok it at all at the time, probably due to an instructor who couldn't care less.

That, LTU, and one guy writing a Perl 6 compiler/interpeter in ~3 months convinced me it was worth having a look at.

Re:That's nice....

[brpr]

0. (Aside: "More modern?" - lisp started a long time ago but has been evolving continuously. The latest Lisp standard is from the 1990s, not the newest standard, but hardly "old")

Haskell is more modern in the sense that it makes use of more modern ideas in computer science. E.g. lazy evaluation, type inference, pure functional programming, monads, etc. Common Lisp is an old-fashioned imperative language, though it does have decent support for higher order functions and closures, and is perhaps the best OO/imperative language ever designed.

Re:That's nice....

[snorklewacker]

> Can anyone point out any strong advantages Lisp has over more modern functional languages?

It's multi-paradigm. Compared to the ML family, I'd have a hard time calling Common Lisp functional. Maybe scheme, but I'm not even sure about that. Modern FP tends to revolve heavily around type theory, while lisp only ever tends to use types as a compiler optimization or ala carte when some amount of type discipline is desired here or there.

Haskell is still nigh unreadable whenever complex state or flow control is involved. Haskell also encourages people to really play golf with folds and eta reduction as well. It's not that I don't appreciate that expressiveness being there, but the culture is certainly prone to abusing it.

Ocaml is nice, but no overloading? Blech.

Re:That's nice....

[brpr]

N.B. Commmon Lisp compilers such as CMUCL and SBCL do type-inferencing.

Sure, but it's not part of the language. It's also nowhere near as sophisticated as Haskell's type inference (e.g. you can't even specify the type of the members of a list using the CL type system).

There are lazy-evaluation packages for Lisp, it's another programming technique.

It's nowhere near as easy to use lazy evaluation in Lisp as it is in Haskell.

There has long been a pure functional subset of Lisp one can program in if one is a bit of a masochist.

Precisely -- if one is a masochist. Lisp doesn't make pure functional programming easy. Haskell does.

Now, you might argue "that's Qi, not Lisp!", but to do so is to miss the point of Lisp as a metalanguage. Lisp, like a human, is a "specialised non-specialist": if evolved "for" anything, is evolved for dealing with continuous change - Qi is Lisp pushed heavily in the Haskell/ML direction.

Qi isn't Lisp, it's a programming language implemented on top of Lisp. It's not as good as Haskell, though it's an interesting project.

If you want to argue, "I can implement any language on top of Lisp, therefore no language is better than Lisp", that's your perogative, but if we're interested in the real world, it's pretty clear that in practice Lisp's support for functional programming is very poor compared to Haskell's. This doesn't stop Lisp being a great language, but it's a fact nontheless.

Re:That's nice....

[brpr]

It's not that one can implement any language "on top" of lisp, it's that one can nick the ideas of any language and merge them with lisp and any other languages you might have implemented "on top". I'd say "synergy" if it didn't cause a learned barf-reaction due to working in a corporate environment.

The distinction you're making is misses the point. You seem to be arguing "since I can merge the ideas from any language into Lisp, no language is better than Lisp". My previous points still stand against this argument. In practice, no-one has developed a pure, lazy, functional programming evironment on top of, to the side of, under, over or around Lisp that's as good as Haskell. And if you're going to counter that by saying that my value of "good" is subjective, then guess what, yours is too! Yeah, you could write a Haskell compiler that targetted common lisp and which integrated Haskell with Lisp. But no-one has done this, and to do it would require an enormous waste of time and effort which would be better spent writing the program in Haskell and compiling it using a normal Haskell compiler. What does Haskell-on-Lisp buy me that plain old Haskell doesn't? A few things, maybe, but nothing worth shouting about.

Re:That's nice....

[brpr]

No, I'm arguing that since one can merge the ideas from any language into lisp, lisp is perhaps the best language for merging ideas from any language into it.

So what's that argument got to do with the original bone of contention, which was whether Haskell is more modern than Lisp? Sure, you can shoe-horn all of Haskell's modern features into Lisp (in a way that you absolutely can't in say C++ or Java) (*), but in its baseline configuration Haskell is more modern in design than Lisp. As I've repeatedly said, it's no use saying, "Oh well Lisp doesn't have that feature by default, but you could add it". Nobody wants to do the extra work when Haskell exists already as a fully functional, mature programming language.

All the stuff that isn't Haskell? Non- nausea-inducing syntax? :-)

Haskell syntax is a lot more concise than Lisp syntax. In fact, I once tried to come up with an S-expr syntax for Haskell, and it's almost impossible to come up with anything that isn't considerably more verbose and less expressive. I like S-expr syntax, but Haskell's syntax works very well, and it's certainly not nausea-inducing. You need to take off you LISP IS GOD glasses and try to see design decisions in a sympathetic light, instead of automatically discounting them because they're not the Lisp Way.

To be clear, I like Lisp, and I don't think that Haskell is better than Lisp. But it's undoubtably a more modern programming language, and it's undoubtably better as a pure functional programming language.

(*)Actually, you couldn't properly add laziness to Lisp without creating a new compiler or interpreter for a lazy variant of Lisp.

Re:That's nice....

[brpr]

That's like saying a TV is more modern than a electronic equipment factory.

No it isn't. Think.

s/fully/purely/ functional - meaning it DOESN'T HAVE all the other stuff, at least not without hideous kludgery of inelegant monads and arrows (yes, I think monads are INELEGANT. You should take off your HASKELL IS GOD glasses if you don't ;-) )

More kludgey thn uncontrolled side effects dependent on eager evaluation for predictable semantics? Whatever.

For you, maybe. It just sucks royally, as far as I'm concerned. Compare: "Perl syntax works very well, and it's certainly not nausea-inducing" - there are people in the world who honestly believe that!

Sorry! I forgot that your opinion is inherently more important than mine.

Re:That's nice....

[hding]

Just to amplify the previous poster's message, I must admit that I had programmed in Common Lisp for some time without completely "getting" the condition system (which is still not terrible as one can trivially use it as a "typical" exception system without its the extra power). I think Peter Seibel really gave me the light bulb moment in Practical Common Lisp. Whereas a typical exception mechanism has two points of relevance in the code, the point where the exception is raised and the point where it is caught and handled, the Lisp condition system can be seen as breaking the latter into two parts: a point (or for that matter multiple points) in the code where a potential way of handling a condition is established, and a point (or multiple points) where it is decided which of these ways will actually be used. This is key to the added flexibility of Lisp conditions and to the ability to not unwind the stack all the way to the point where it is decided how to handle the condition.

Re:That's nice....

[brpr]

Yes it is. Lisp has features optimised for embedding little languages.

So has Haskell (see for example Parsec). Often, I find Haskell more suitable than Lisp for developing domain specific minilanguages because of its more modern features (e.g. currying, lazy evaluation, better support for HOFs, pattern matching...), all of which are built into the language, well-tested, widely used and standardised. It's possible to develop a parser combinator library in Lisp (I've done it), but it's a lot more work when you don't have the abstraction offered by lazy lists/streams.

Lisp and Haskell are different languages out-of-box. Given an electronic components factory and a TV, which is more likely to be able to churn out new electronic components?

This is where your silly analogy breaks down. Haskell is fully capable of churning out new components, just as Lisp is. Out-of-box, Lisp is less capable than Haskell. I agree that Lisp is very extensible, but Haskell already exists and you don't have to waste time extending it. And when you do need to extend it, it's almost as extensible as Lisp.

I freely acknowledge you might prefer Haskell, just as some weirdos prefer Perl.

Why are you comparing Haskell syntax to Perl? Haskell syntax is very minimal. It's almost entirely function application by juxtaposition and function application by infix operator. There's not much else to it. Haskell's concise syntax is a win over S-exprs in terms of productivity and readability, and Haskell is still pretty extensible despite not having S-exprs.

Lisp certainly does have some advantages over Haskell. Mostly that if you want to write low-level, eficient code you can do it very easily. But Lisp's relatively low-level of programming comes at a price. When you want to do the heavy-lifting of abstraction, you have to use clumsy devices like macros instead of the much nicer alternatives in Haskell (mostly, HOFs, laziness and user-defined operators).

And you're still arguing that "Lisp is extensible therefore no language is better than Lisp". This argument is fine in the abstract but it doesn't work in the real world. I don't want to extend Lisp, I want to write a program!

Re:That's nice....

[sleepingsquirrel]

Haskell syntax is very minimal. It's almost entirely function application by juxtaposition and function application by infix operator. There's not much else to it.

Not that I disagree with your other points, but Haskell isn't that regular. Or at least the Haskell code that I write is littered with list comprehensions, and do-notation, and lambda abstractions, etc.

Re:That's nice....

[jovlinger]

Joe Marshall had a great comment about this sort of discussion, over on the ll-discuss mailing list:

It's like arguing over whether Guiness or Murphy's is better, when everyone else is drinking Miller and Bud.

Re:That's nice....

[brpr]

SERIES 2000 has been a free download for a long time now. Series was in CLTL2, f.f.s.

Yes, but the abstraction isn't integrated into the standard library, and you can't use the list functions to operate on series.

Come off of it. It just plain isn't. Let's look at the spec, shall we? "Dear lord", he said with remembered horror, "Layout? Haskell syntax is FREAKING 2-DIMENSIONAL".

The use of layout is just a feature of the lexer. You could just as easily use indentation instead of brackets to group symbols in lisp code (in fact Guile has an extension to allow you to do this in Scheme). It doesn't really make the syntax as such any more complicated. Obviously, Haskell syntax is somewhat more complex than Lisp syntax, but it's also much more concise. How long is the Lisp equivalent of the following?

reverse = foldl (flip (:)) []

Writing idiomatic programs in lisp IS extending lisp. If you're not, you're doing it, well, not wrong as such, but rather suboptimally.

Yes, but there's a difference between "extending lisp" in the usual sense and "writing a new language on top of lisp", which is a waste of time when the new language already exists! It's absurd to argue that if I want to write a program using lazy functional idioms that I should first spend days/months extending Lisp to fully support these idioms, instead of just using Haskell.

Common Lisp

[Julian Morrison]

CL is much "closer to the metal" than Haskell or even OCAML and it's designed to compile to efficient code. As a result it's not particularly "functional" (nowhere near as much as Scheme, for example). CMUCL compiled lisp should approximately match native-compiled OCAML in speed, and CL has an advantage in being a multiple-sourced standard.

Main advantages of CL

- Scalable ratio of easy:fast. Prototype lazily and tune iteratively.

- Macros facilitate "little languages" for task areas, making core algorithms terse and readable.

- Running apps can be hot-debugged, tested and recompiled in situ.

- Exception mechanism provides something I've seen nowhere else, namely the ability to catch an exception, repair the problem, and reverse the thow to resume where the code left off.

Main serious problems with CL

- Too many fiddly features makes writing a compiler hard

- Lack of a good standalone-binary compiler.

- Weakly standardized library mechanism makes cross-implementation libraries unnecessarily hard and hence rare. (NB: "common lisp controller" is a fix for this and standard in Debian.)

- No fixed standard for foreign function interface (or requirement that one even exist).

- No sockets or threading in the standard library.

Uncommon Web / Slime

[uits]

Marco is the author of Uncommon Web, a continuation based lisp framework for web applications.

Last week he did a video for that, torrent here that was well received. It's still in the early stages, but combined with Lisp-on-Lines (in development) it's hopefully going to attract some mindshare.

Bill Clementson also discusses lisp webserver options in his (slighty dated - Oct-2004) blog entry

I started working with UCW/Slime/mod_lisp a couple of weeks ago, and I'm pleased to see better getting started videos, ala Ruby on Rails.

Re:Lisp is D.O.A.

[csrhodes]

But compared to a language like Ruby or Python, Lisp is an anachronism. No standardization. No standard Unicode, threads. No XML or RSS libs, no web server, no web framework, no GUI tools, just a bunch of incompatible implementations.

This is a very common wish, but there's a fallacy in the first sentence. The implied comparison is between language implementations (Ruby, Python) and a language specification (Common Lisp, Scheme) or a metalanguage idealisation (Lisp). There are plenty of implementations of Lisp and Scheme which have available for them all of the elements on the wishlist: but they are not standard across all implementations of a specification, or all instantiations of the metalanguage.

There is indeed a need for better distribution integration for the various Free lisps out there (of which there are many) for the newcomers not to feel so intimidated by the need to assemble their systems themselves: but the inherently misleading comparison between specification and implementation should not frame the discussion, because those who need the bits and pieces can assemble them.

Re:Lisp is D.O.A.

[sleepingsquirrel]

Maybe you want Dr Scheme?

Common Lisp vs. OCaml?

[sleepingsquirrel]

FWIW, it looks like the shootout shows O'Caml besting CMUCL on speed, memory, and lines of code.

Re:Lisp is D.O.A.

[brpr]

Maybe you want Dr Scheme?

First, Dr Scheme is obviously a Scheme IDE, not a Common Lisp IDE. The differences between Scheme and Common Lisp are not so trivial that someone looking for a good CL IDE will be just as satisfied with a good Scheme IDE.

Second, while Dr. Scheme is in many ways superb, it's maddeningly simple in others. It has an unforgiveably awful multiple document interface. I don't want a new toplevel window for every file I'm editing! And why can't I transparently use the same REPL with multiple buffers? For all the fancy features in Slime, the biggest productivity gain for me is the ease of managing multiple buffers in Emacs, and C-c-c to compile a file and load it into the currently running REPL. Without these simple features, the other (excellent) features of Dr. Scheme are more or less irrelavent.

Having said all this, Slime could really use the brilliant debugger and code-stepper in Dr. Scheme. Unfortunately, the underlying Emacs environment would probably make it difficult to do such a good job.

Re:Lisp is D.O.A.

[snorklewacker]

> But compared to a language like Ruby or Python, Lisp is an anachronism. No standardization. No standard Unicode, threads.

It's interesting you mention Ruby, as it also lacks unicode.

clisp has good unicode support, and its CLOS implementation has gotten quite mature these days. No idea on how speed is doing, but it's always run dizzyingly tight little circles around python.

Ruby would have a hard time turning into lisp, given the lack of continuations. Scheme might do all right.

Re:Lisp is D.O.A.

[snorklewacker]

> Except that Ruby does have continuations, and Common Lisp doesn't...

And scheme does. What's the "except" about? I thought it would be obvious which one I was saying had them. I guess "turning into lisp" is kind of backward. I meant "translated into lisp".

I don't find CL all that minimal, unfortunately. The fact that it can be bootstrapped is uninteresting to me. In fact, having to deal with the hyperspec as a reference makes me imagine it to be an elephantine design-by-committee abomination (contrast to R5RS). I know this isn't quite true of the language, but the documentation and the CUMBERSOMELY-LONG-IDENTIFIERS just don't give an overall impression of "lean".

Re:Lisp is D.O.A.

[stesch]

Show me the standards for Ruby or Python.

Re:Lisp is D.O.A.

[pkhuong]

Oh yeah, those bad libraries with descriptive function-names! Too many of them.. Or is it not enough? Wow, I'm just too confuzzled for all this thinking.

Re:Haskell - another write-only language like Perl

[sleepingsquirrel]

Eh, that was quicksort in the J language. Quicksort in Haskell looks like...

qsort [] = []
qsort (x:xs) = qsort less ++ [x] ++ qsort more
____where less = filter (<x) xs
__________more = filter (>=x) xs

Re:Lisp is D.O.A.

[CatGrep]

Ruby would have a hard time turning into lisp, given the lack of continuations.

Ruby has continuations. It's Python that lacks them.

Effective presentation

[try_anything]

I've never seen a software tutorial in this format, and I think it rocks. From one incomplete, casual viewing, I picked up a couple of features and added them to my repertoire, and I've been using slime for a couple of months. Thanks, Marco!

I'd like to see more software tutorials in this format. There's something more exciting here than rehashing language wars, guys!