A Video Tutorial of SLIME 50
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."
That's nice.... (Score:2)
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';
'$' is the self reference operat
Re:That's nice.... (Score:2, Informative)
-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 sta
Re:That's nice.... (Score:1, Informative)
Re:That's nice.... (Score:2)
Re:That's nice.... (Score:2)
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 O
Re:That's nice.... (Score:2)
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 i
Re:That's nice.... (Score:2)
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 thi
Re:That's nice.... (Score:2)
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 sa
Re:That's nice.... (Score:2)
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
Re:That's nice.... (Score:2)
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
Re:That's nice.... (Score:2)
Re:That's nice.... (Score:2)
It's like arguing over whether Guiness or Murphy's is better, when everyone else is drinking Miller and Bud.
Re:That's nice.... (Score:2)
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 symbo
Common Lisp (Score:4, Informative)
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.
Common Lisp vs. OCaml? (Score:2)
Re:That's nice.... (Score:1)
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 suppor
Re:That's nice.... (Score:2)
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.... (Score:2)
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 contr
Re:Haskell - another write-only language like Perl (Score:2)
Re:Lisp is D.O.A. (Score:2, Interesting)
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
Re:Lisp is D.O.A. (Score:2)
Re:Lisp is D.O.A. (Score:2)
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
Re:Lisp is D.O.A. (Score:2)
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. (Score:2)
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 (cont
Re:Lisp is D.O.A. (Score:2)
Re:Lisp is D.O.A. (Score:2)
Ruby has continuations. It's Python that lacks them.
Re:Lisp is D.O.A. (Score:1)
Uncommon Web / Slime (Score:2, Informative)
Marco is the author of Uncommon Web [common-lisp.net], a continuation based lisp framework for web applications.
Last week he did a video for that, torrent here [common-lisp.net] that was well received. It's still in the early stages, but combined with Lisp-on-Lines [tech.coop] (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 [tech.coop]
I started working with UCW/Slime/mod_lisp a couple of weeks ago, and I'm pleased to see better getting started v
Effective presentation (Score:1)
I'd like to see more software tutorials in this format. There's something more exciting here than rehashing language wars, guys!