A Video Tutorial of SLIME

← Back to Stories (view on slashdot.org)

Posted by timothy on Saturday July 30, 2005 @06:51AM from the no-really-that's-the-name dept.

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."

50 comments

Min score:

Reason:

Sort:

I suck by Anonymous Coward · 2005-07-30 06:57 · Score: 0

first post
That's nice.... by jericho4.0 · 2005-07-30 07:21 · Score: 1

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.

--
"A language that doesn't affect the way you think about programming, is not worth knowing" - Alan Perlis
1. Re:That's nice.... by Anonymous Coward · 2005-07-30 07:43 · Score: 2, Informative
  
  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).
2. Re:That's nice.... by Anonymous Coward · 2005-07-30 07:56 · Score: 0
  
  Lisp is not purely functional like Haskell.
  
  Also I believe Lisp can be coaxed into being quite fast, much faster than Haskell or OCaml. I've written some toy programs that are nearly as fast as C.
  
  Personally, I can't stand the syntax of Haskell, it looks like a bunch of nuts and bolts thrown all over the place, so that's one advantage of Lisp IMO. :-)
3. Re:That's nice.... by Anonymous Coward · 2005-07-30 08:09 · Score: 1, Informative
  
  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.
4. Re:That's nice.... by Anonymous Coward · 2005-07-30 08:19 · Score: 0
  
  The quite recent video at http://bc.tech.coop/blog/050711.html
  should have been mentioned as well. It shows how to develop in lisp - atleast a short example.
5. Re:That's nice.... by aCapitalist · 2005-07-30 09:31 · Score: 1
  
  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.
6. Re:That's nice.... by jericho4.0 · 2005-07-30 10:43 · Score: 1
  
  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.
  
  --
  "A language that doesn't affect the way you think about programming, is not worth knowing" - Alan Perlis
7. Re:That's nice.... by brpr · 2005-07-30 12:55 · Score: 1
  
  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.
  
  --
  Freedom is not increased by mere diminuation of government. Anarchy is freedom for the strong and slavery for the weak.
8. Re:That's nice.... by snorklewacker · 2005-07-30 17:46 · Score: 1
  
  > 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.
  
  --
  I am no longer wasting my time with slashdot
9. Re:That's nice.... by Anonymous Coward · 2005-07-30 22:16 · Score: 0
  
  N.B. Commmon Lisp compilers such as CMUCL and SBCL do type-inferencing. There are lazy-evaluation packages for Lisp, it's another programming technique. There has long been a pure functional subset of Lisp one can program in if one is a bit of a masochist.
  
  Common Lisp is best described as a multiparadigm language. Saying Haskell is "more modern" is bias towards a particular paradigm, like claiming dogs are "more modern" than cats. Evolution doesn't work that way, and Lisp is subject to somewhat different evolutionary pressure than Haskell. Existence of Qi, for example, shows that Lisp can functional it up with the best of 'em. 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.
10. Re:That's nice.... by brpr · 2005-07-31 01:27 · Score: 1
  
  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.
  
  --
  Freedom is not increased by mere diminuation of government. Anarchy is freedom for the strong and slavery for the weak.
11. Re:That's nice.... by Anonymous Coward · 2005-07-31 03:32 · Score: 0
  
  It's not as good as Haskell, though it's an interesting project.
  
  For some subjective value of "good".
  
  on top of Lisp
  
  As predicted, point missed. Languages like Qi aren't just implemented "on top" of a lisp (well, they could be, but that's beside the point): one extends lisp to incorporate their concepts in borg-like fashion, like extending english with technical jargon for a particular subject: One can mix Qi and Common Lisp code with pretty gay abandon if one desires. This "level mixing" is something that's pervasive in lisp and positively discouraged in many other languages. This goes back to the nature of lisp as the "big ball of dirt" - you slap more stuff onto it and you have a bigger ball of dirt that's just as "beautiful" as it was before, retaining the
  dirtball nature. 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.
12. Re:That's nice.... by brpr · 2005-07-31 08:23 · Score: 1
  
  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.
  
  --
  Freedom is not increased by mere diminuation of government. Anarchy is freedom for the strong and slavery for the weak.
13. Re:That's nice.... by Anonymous Coward · 2005-07-31 09:35 · Score: 0
  
  You seem to be arguing "since I can merge the ideas from any language into Lisp, no language is better than Lisp".
  
  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. You're the one who insists on seeing languages on a one-dimensional better/worse axis, I would simply assert that Lisp is a better specialised-nonspecialist language than Haskell.
  
  Actually, I can imagine languages that would be rather better specialised nonspecialists than common lisp existing, perhaps ones with better notions of parallelism (enter Erlisp...) Or quantum computation or something. But they'd probably look like lisp to the point of being called a "lisp" just like scheme is.
  
  What does Haskell-on-Lisp buy me that plain old Haskell doesn't?
  
  (Disregarding stupid turing-equivalence arguments, of course:) All the stuff that isn't Haskell? Non- nausea-inducing syntax? :-)
  If all your world's a Haskell, then by all means stick to it. But in my experience, Haskell would be annoying for programs I'm interested in (mostly ones which rewrite themselves...).
14. Re:That's nice.... by brpr · 2005-07-31 11:11 · Score: 1
  
  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.
  
  --
  Freedom is not increased by mere diminuation of government. Anarchy is freedom for the strong and slavery for the weak.
15. Re:That's nice.... by Anonymous Coward · 2005-07-31 11:33 · Score: 0
  
  but in its baseline configuration Haskell is more modern in design than Lisp.
  
  That's like saying a TV is more modern than a electronic equipment factory.
  
  Nobody wants to do the extra work when Haskell exists already as a fully functional, mature programming language.
  
  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 ;-) )
  
  Haskell's syntax works very well, and it's certainly not nausea-inducing
  
  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!
16. Re:That's nice.... by brpr · 2005-07-31 12:38 · Score: 1
  
  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.
  
  --
  Freedom is not increased by mere diminuation of government. Anarchy is freedom for the strong and slavery for the weak.
17. Re:That's nice.... by Anonymous Coward · 2005-08-01 01:02 · Score: 0
  
  No it isn't. Think.
  
  Yes it is. Lisp has features optimised for embedding little languages. It's got a quite modern array of such features (though could have more). A TV might have more modern "TV" features, but because the factory ISN'T A TV it doesn't have to have those features, it's a fallacy to say that a modern factory built in the 1990s is "less modern" than a modern TV built in the 1990s. 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?
  
  Sorry! I forgot that your opinion is inherently more important than mine.
  
  Gaah. I'm the one saying the lisp syntax is preferable FOR ME. I freely acknowledge you might prefer Haskell, just as some weirdos prefer Perl. Just because someone's a weirdo doesn't make their opinon less valid! (if it did, there are a whole lotta compscis whose opinions would be worthless)!
18. Re:That's nice.... by hding · 2005-08-01 01:52 · Score: 1
  
  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.
19. Re:That's nice.... by brpr · 2005-08-01 03:42 · Score: 1
  
  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!
  
  --
  Freedom is not increased by mere diminuation of government. Anarchy is freedom for the strong and slavery for the weak.
20. Re:That's nice.... by sleepingsquirrel · 2005-08-01 04:28 · Score: 1
  
  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.
21. Re:That's nice.... by Anonymous Coward · 2005-08-01 08:18 · Score: 0
  
  when you don't have the abstraction offered by lazy lists/streams.
  
  SERIES 2000 has been a free download for a long time now. Series was in CLTL2, f.f.s.
  
  Haskell syntax is very minimal
  
  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".
  
  Now, maybe it's a good fit for your brain, it takes all sorts.
  
  I don't want to extend Lisp, I want to write a program!
  
  Writing idiomatic programs in lisp IS extending lisp. If you're not, you're doing it, well, not wrong as such, but rather suboptimally.
22. Re:That's nice.... by Anonymous Coward · 2005-08-02 02:07 · Score: 0
  
  (*)Actually, you couldn't properly add laziness to Lisp without creating a new compiler or interpreter for a lazy variant of Lisp.
  
  Sounds like someone does not properly understand macros and bottom-up programming. Sigh, loud mouths never really know what they are talking about.
23. Re:That's nice.... by jovlinger · 2005-08-09 05:27 · Score: 1
  
  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.
24. Re:That's nice.... by brpr · 2005-08-09 06:40 · Score: 1
  
  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.
  
  --
  Freedom is not increased by mere diminuation of government. Anarchy is freedom for the strong and slavery for the weak.
Common Lisp by Julian+Morrison · 2005-07-30 08:21 · Score: 3, Informative

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.
Structures and Interpretation of Computer Programs by Anonymous Coward · 2005-07-30 08:29 · Score: 0

I'd recommend the SICP lectures at
http://swiss.csail.mit.edu/classes/6.001/abelson-s ussman-lectures/
for an introduction of what Lisp can do. And if you're a programmer and havn't read the SICP book yet - please do, it teaches you a thing or 10 applicable to all programming languages.

(Yes - so SICP is about Scheme, a much simpler dialect of Lisp than Common Lisp of the topic here.. still..)
Lisp is D.O.A. by Anonymous Coward · 2005-07-30 08:48 · Score: 0

Don't get me wrong, I love the essence of Lisp and wish I could use it every day.

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.

I'm waiting patiently for a smart person (who is not Paul Graham) to create a "unix lisp" which comes with all this stuff "in the box". Wouldn't that kick serious ass? Imagine taking a Ruby program and translating it directly into Lisp, and then refactoring it using macros and all that cool stuff.

I *REALLY* want to see this. I want to see the "One Modern Lisp" emerge. Anybody??
1. Re:Lisp is D.O.A. by Anonymous Coward · 2005-07-30 08:54 · Score: 0
  
  Try this implementation for instance. It has all the features you are looking for.
2. Re:Lisp is D.O.A. by csrhodes · 2005-07-30 10:10 · Score: 2, Interesting
  
  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.
3. Re:Lisp is D.O.A. by sleepingsquirrel · 2005-07-30 12:03 · Score: 1
  
  Maybe you want Dr Scheme?
4. Re:Lisp is D.O.A. by brpr · 2005-07-30 12:48 · Score: 1
  
  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.
  
  --
  Freedom is not increased by mere diminuation of government. Anarchy is freedom for the strong and slavery for the weak.
5. Re:Lisp is D.O.A. by snorklewacker · 2005-07-30 17:52 · Score: 1
  
  > 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.
  
  --
  I am no longer wasting my time with slashdot
6. Re:Lisp is D.O.A. by Anonymous Coward · 2005-07-30 18:01 · Score: 0
  
  Ruby would have a hard time turning into lisp, given the lack of continuations.
  Except that Ruby does have continuations, and Common Lisp doesn't...
  The reason Ruby would have a hard time turning into lisp is the syntax, the lack of macros, and the fact that Lisp has such an emphasis on minimalism (provide a really small core that can be used to implement the rest of the language in itself).
7. Re:Lisp is D.O.A. by snorklewacker · 2005-07-30 18:36 · Score: 1
  
  > 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".
  
  --
  I am no longer wasting my time with slashdot
8. Re:Lisp is D.O.A. by stesch · 2005-07-30 22:42 · Score: 1
  
  Show me the standards for Ruby or Python.
9. Re:Lisp is D.O.A. by pkhuong · 2005-07-30 23:14 · Score: 1
  
  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.
  
  --
  Try Corewar @ www.koth.org - rec.games.corewar
10. Re:Lisp is D.O.A. by Anonymous Coward · 2005-07-31 09:54 · Score: 0
  
  How could anyone not love lisp, with all its friendly users like yourself.
11. Re:Lisp is D.O.A. by CatGrep · 2005-07-31 16:52 · Score: 1
  
  Ruby would have a hard time turning into lisp, given the lack of continuations.
  
  Ruby has continuations. It's Python that lacks them.
Uncommon Web / Slime by uits · 2005-07-30 09:52 · Score: 2, Informative

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.
Common Lisp vs. OCaml? by sleepingsquirrel · 2005-07-30 12:24 · Score: 1

FWIW, it looks like the shootout shows O'Caml besting CMUCL on speed, memory, and lines of code.
Slime rules! by Anonymous Coward · 2005-07-30 13:45 · Score: 0

I always preferred the original! The Slime with worms was pretty disgusting!
Who posted this? by Anonymous Coward · 2005-07-30 21:44 · Score: 0

Pearls before swine. Telling the slashbots about the Lisp world is a mistake :-(
Haskell - another write-only language like Perl? by Anonymous Coward · 2005-07-30 22:08 · Score: 0

I never would have recognized this line as quicksort. You should have posted

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

In my experience well-readable languages like C# or Java together with tools like VisualStudio.NET or Eclipse are a better choice because code maintenance (afterwards) is much easier in big projects. In small projects languages don't matter.
Re:Haskell - another write-only language like Perl by sleepingsquirrel · 2005-07-31 06:20 · Score: 1

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:Haskell - another write-only language like Perl by Anonymous Coward · 2005-07-31 07:54 · Score: 0

Obviously your experience isn't too much :-). Modern functional and dynamic languages produce more concise and readable code than the usual run of the mill Java/C#.

Of course, if you don't learn them first, you can't obviously read them (which certainly seems to be the case with you since your code is not Haskell)
Re:Haskell - another write-only language like Perl by Anonymous Coward · 2005-07-31 10:41 · Score: 0

Interesting, using filter instead of list comprehensions. Is it any faster than the original?
Re:Haskell - another write-only language like Perl by Anonymous Coward · 2005-07-31 16:52 · Score: 0

qsort [] = [] qsort (x:xs) = qsort [y | y <- xs, y<x ] ++ [x] ++ qsort [y | y <- xs,y>=x]
Effective presentation by try_anything · 2005-08-01 08:31 · Score: 1

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!