The German School of Lisp ("Fluchtpunkt Lisps")

Many people ask the same question(about lisps advantages), expecting a big list of features that will magically make their life instantly easier, i have no such list, but many people claim to do, and you can find them with some googling(i think theres one clojure specific on their site :).

Instead I'll just give you a few words about what value I've gained by learning scheme, clojure and common lisp. This is personal, and specific to me :)

Scheme taught me the basics of CS, It is an exceptionally good teaching language, when ESR said that lisp was worth learning because of the enlightenment, he probably meant(or should have) scheme. I've never actually used scheme for anything, so i won't talk about how actually useful it is.

After scheme i got into clojure, about the time 1.0 came out(i think?). For me, theres a lot to love and a lot to hate in clojure. I loved this language, It took the stuff scheme taught me, and showed me how to actually use them well. It made me think, it made me learn, and it made me get better. It didn't make me better, i made myself better inspired by it(same is true of all lisp i know actually). I ultimately concluded that clojure and i are headed in different directions, so we parted, but I'm sure our paths will cross again, when are both better.

Now common lisp is something special. Everything i said about clojure applies to common lisp. The languages are very different, but the end goal is the same: good software. Common lisp taught me how much of what i took for granted was just contemporary fashion trends, it showed me that theres value in knowing the history of lisp well, it showed me that i had accepted the front page of HN as what reality was like, and freed me of this world view. It showed me that software truly CAN be good if I put in the effort to make it that way.

I no longer blame my tools for my failures, because it is I who chose them, and I who used them. This attitude is maybe the most valuable thing i got from learning lisp, just fucking do it, because you can. And it pisses me off when people claim lisp can make you more productive, it won't unless you learn it well and use it wisely.

There are some things that are actually quite difficult or simply impossible to express in Ruby, Python, and other mainstream OO languages. The promise of Lisp has always been (to me at least), powerful runtime dynamism without sacrificing performance, I wrote about this yesterday, http://dosync.posterous.com/51626638.

It's also quite difficult in my experience to explore and implement more sophisticated and powerful OO and FP concepts like predicate dispatch (think CLOS generic methods or ML pattern matching but more useful) or ad-hoc type systems in these languages - especially when your goal is to produce something that is not a toy. Or think about embedding an efficient logic programming DSL a la Paradigms of Artificial Intelligence.

Of course for various reasons, that this kind of flexibility and power can be applied to real software development might not interest you. But it is why I find Lisp compelling.

It depends who you ask. I'm also a beginner in lisp. Wrote some hobby projects in it but it felt like swimming against the current.

lisp appeared a long time ago, when non lisp languages were really primitive. So a lot of the arguments you might read on the net might be outdated (comparing it to C or FORTRAN).

Ruby and Python give you a lot of power that a lisp language has. I guess the only thing that lisp has, which the other languages don't, is the "macro". Which (in my opinion) is like a lisp "program" running before your lisp get compiled and changes the code. So several lines can be expanded to lots of dynamically generated code.

C guys will say they have #define & such, but this is a "program" with most of lisp syntax not just some primitive ifdefs. So you can do a lot of advanced stuff.

On the other side, python & ruby have a lot more libraries. I see that common lisp has picked up steam again, with stuff like quicklisp which can be seen as "ruby gem".

So to sum it up, lisp is a powerful language, it has constructs which are still not available in other languages but you don't get the free stuff you would have in big communities as python or ruby.

I mostly agree with tdrgabi, and I think Python has a big advantage over the Lisps I've used (Common Lisp and Racket) in its "batteries included" standard library. Plus, Python is more readable and has powerful list comprehensions that make it competitive with Lisp in expressiveness in most cases. And, of course, the biggest advantage of Python or Ruby over Lisp is political -- if you hand off a well-written Python script to your coworker and he complains about you using Python, then he looks like an idiot instead of you. Try that with Lisp.

However, I think Common Lisp and Racket have two big advantages over Python. Number one is performance. They're dynamic, but they're also compiled, which means they can be big and featureful when that's what you want (e.g., CLOS) but they can be fast when you need them to be. I haven't tried this in Racket yet, but when you're optimizing a function in Common Lisp, you can ask the REPL for the compiled form and it will spit out the assembly. You can tweak the safety and optimization settings, recompile the function, and look at the assembly again. Iterate until you eliminate whatever is killing your performance. Python lets you call out to C, of course, but so do Common Lisp and Racket.

Number two is the development experience. The typical workflow is to set up a running instance of Lisp, connect to it from your editor, and then send code to it. You can write a bunch of code in your editor, highlight a couple of functions and send them to your Lisp instance, and then play with those functions in the REPL. Need to tweak something or fix a bug? Edit a function and send the new version to the Lisp instance. Then see how it works. Maybe you can do the same thing in Python with the correct setup. If so, I'd love to hear it. (I'm sure it's possible with some Python IDE or other, but why give up your favorite text editor?)

Number three, if it came into play more often, would be that Lisp really is more expressive than Python. Honestly, I almost never see the difference in the work I do for a living. The more interesting the problem, though, the more likely you are to see a difference.

If you're writing a programming language, Lisp's terse syntax makes writing the boring parts like the parser very simple. That's why many of these cool projects use it.

But for the more everyday tasks, other languages work just fine. Lisp isn't always going to be a big productivity win over Ruby or Python. If you're looking at it from that angle, you'll be disappointed.

But yes, it's worth reading On Lisp and SICP, and working through the examples. Afterward you'll find yourself missing features that Lisp has when you work with other languages; at that point you can make an informed decision which one fits your problem best.

You might try common lisp then, as it has an object system (CLOS), and does not enforce functional purity. The one downside is that a lot of people like to complain about it, for reasons that don't really make sense to me.

The first advantage is that you can use the entirety of the language at compile time. (This means you can use CLOS, structs, functions, methods, anything). Basically what this gives you is an easily programmable compiler.

The second advantage is that programs written in common lisp can be very fast. The compilers in general are very mature, and tend to compete with speeds of languages like C and C++ when properly optimized. In addition to proper declarations, if you know what a C compiler would do to make a bit of code run fast, you can easily duplicate it. You also have clever/tricky things like eval, with which you can (for example) use run-time information to re-generate a piece of code in a better optimized way.

The third advantage is that I like the syntax, it is simple, and I don't have to fuss with balancing different types of brace or worry about order of operations.

I've never read SICP personally, my impression is that it is much more focused on the principles of computer science than it is on lisp or scheme, generally. Nowadays to learn I might start with practical common lisp or one of the Clojure books, and then move on to one of the more advanced books, like 'On Lisp' or 'Let over Lambda.'

I'll get burned at the stake for saying it, but there isn't really a lisp 'style'. (A lot of people will tell you there is). Just start writing programs that work with pieces of the language that you know (in common lisp there is some redundancy), and eventually you'll have enough knowledge of the language to have a reasonable style. You can fix it to be pretty later (or not, I call this the PHP approach).

There is a ton of information on line in HTML and PDF form, also, many of the older books have been released into the public domain on line (on lisp being an example) Just use google and they should show up.

It also helps to learn a bunch of other languages, I regularly steal convenient idioms from other languages and implement them as macros.

I think you would struggle (at least initially) to feel more productive in Scheme than Ruby / Python (although Racket seems like it would probably be equivalent to Ruby/Python in capability).

However, I'm concentrating on Common Lisp these days, and there are things about it (it's object system (CLOS) and probably macros) that feel much more flexible and productive than even Ruby or Python.

Here is the order of books I'd recommend if you want to explore Common Lisp:

  1. Land of Lisp by Conrad Barski
  2. Practical Common Lisp by Peter Seibel
  3. ANSI Common Lisp by Paul Graham
  4. On Lisp by Paul Graham (available online)
  5. Paradigms of Artificial Intelligence by Peter Norvig

  Then maybe:
  6. Art of the Metaobject Protocol

What makes Lisp unique, in my opinion, is its elegant unification of code and data. The 'eval' function and of course Lisp macros are very powerful features that come out of this immediately, and theoretically you can implement any other language feature on top.

In most other languages, to do the same things you have to parse the syntax, build an AST (Abstract Syntax Tree), do whatever transformations you need, and if you're very lucky you can then call the compiler as a library. Lisp makes the AST directly executable with 'eval', and provides a syntax parser already. Moreover, the AST is made of lists and symbols, which Lisp is naturally perfectly suited to manipulating.

All this makes Lisp quite beautiful as a mathematical object. I can't speak on its practicality ;)

Ruby programmers love domain-specific languages implemented in Ruby (eg RSpec). A Lisp dialect lets you implement libraries with fewer restrictions on what the DSL can do and more expressive power. Lisp takes Rails-style succinctness through metaprogramming to the next level.

I've done a bit of programming in lisps and scheme, and have recently been working on a ruby project. While I enjoy ruby, I'm finding it difficult to reason precisely about the code I write in it, because the semantics are so complex and everything is so dynamic and fragile. It makes me anxious as a build and add complexity.

With lisps and other languages like haskell, the semantics are extremely simple.

That's probably pretty vague, but it's another perspective.

While I've heard a number of justifications for Lisp, based on feature A or B, to me the power of Lisp is pretty simple.

Essentially, lisp is the parse tree that all other programming languages convert their syntax into.

This means that all language features can be embedded as DSLs in Lisp using its macro system. No other language I know of can do this as conveniently as Lisp.

The small (2K) RAM size is the limiting factor, not so much the code space.

You'll find a few more options if you look beyond the atmega328 in the Arduino: 'avr lisp', 'avr scheme'

The Lisps I've seen targeting AVRs have all used the atmega128 with 4KB of RAM and they still use external memory of some sort.

Scrying (w/ 64KB external RAM): http://scrying.org/doku.php?id=scrying:interpreter_notes

ActorNet (w/ 512KB external serial flash as virtual memory): http://osl.cs.uiuc.edu/nest/ActorNet-1.1.tar.gz http://osl.cs.uiuc.edu/docs/actornet/kwonActorNet.pdf

Femto microlisp http://code.google.com/p/robobuilderlib/wiki/Femto

For my own REPL-fun on AVR microcontrollers, I've gone with amforth: http://amforth.sourceforge.net

There's Arduino Lisp, a Common Lisp (sort of) to Arduino C++ translator:

http://arduino.cc/forum/index.php/topic,55873.0.html