Should I learn Lisp? And which dialect?

[LakatosIstvan]

So hey guys. I'm an aspiring programmer/computer-scientist. I have fairly good knowledge of Python, Pascal, I recently started learning C/C++, and right now I starting to consider learning Lisp( or Fortran, but that's only a "backup plan"). I am fascinated that it is still used and mentioned in these days despite his(or is it her?) age. I guess it has much to offer. But I'm not entirely sure if I should try learning it, because I'm not entirely sure if I'll ever use it. Also, I'm a bit confused about Lisp dialects, and which one to choose as a starter.

So dear xkcd readers( some of which I also believe know Lisp and it's variants ), will you help me out?

[stephentyrone]

So hey guys. I'm an aspiring programmer/computer-scientist. I have fairly good knowledge of Python, Pascal, I recently started learning C/C++, and right now I starting to consider learning Lisp

yes.

( or Fortran, but that's only a "backup plan").

Dear god, no.

I am fascinated that it is still used and mentioned in these days despite his(or is it her?) age. I guess it has much to offer. But I'm not entirely sure if I should try learning it, because I'm not entirely sure if I'll ever use it. Also, I'm a bit confused about Lisp dialects, and which one to choose as a starter.

Common Lisp (for outstanding libraries) or MIT Scheme (for abundant pedagogical material). Or something else.

[qbg]

Yes, you should learn lisp^*. Not only is it theoretically beautiful, it contains ideas that are years later making their way into other languages. Lisp macros are awesome. For some quotes to die for, see The Most Important Idea in Computer Science.

Common Lisp is a good dialect to learn. It is an industrial strength lisp, and has many powerful features standard, such as CLOS.

* Warning: Learning lisp may impart onto the learner smug lisp weenie syndrome, which makes nearly all other languages horribly painful to use.

[Dark567]

Yes, even though you might never use it, but because learning LISP makes you a better programmer in any language.

[LakatosIstvan]

Ok, so I decided to learn Common Lisp. I found this book on the internet, Practical Common Lisp, which is awesome as far as I can tell.

My question is now: which Common Lisp implementation should I use? Right now on my Windows XP I have Allegro installed, together with SLIME and Emacs, which works pretty well, but Allegro, which is feature-full, isn't free, and has certain limitations. And I would also like to use Common Lisp on my Ubuntu x64 computer, and I am not sure if I should install Allegro, or a completely free, even open-source Common Lisp implementation, like CLISP( looking through the documentation, I noticed that CLISP doesn't have threads. Is that a problem? ). Any help?

[Briareos]

I've always used SBCL as my go-to common lisp implementation.

[qbg]

On Windows I use the LispWorks Personal Edition; it is also not free software and has certain limitations, but it's good and has the IDE built in. I also have SBCL installed, but SBCL has the "Your Kitten of Death Awaits" message, and I believe that you can't build it with threads currently. I've also have had CCL on windows in the past.

Under Linux I use SBCL and CCL. SBCL seems to be the most popular open source implementation (and if the lispforum poll is to be true universally, then it is THE most popular implementation), it's nice and fast with a good compiler that produces many useful diagnostics, and many libraries support it. CCL is also very nice, has a smaller image, and a very fast compiler. Recently I have used CCL with Emacs+SLIME a lot because the compilation speed is really the only visible difference between the two most of the time for me.

Some libraries (such as HUNCHENTOOT) need threads to work well. Having native threads (like SBCL and CCL have) is also useful because it allows multiple lisp threads to run at once. Of course you should only use threads when it makes sense, so using an implementation without threads would be okay until you need them. (and note that threads aren't part of the standard).

[aleflamedyud]

Bah, learn Chicken Scheme. It's the Python of Lisp implementations.

[LakatosIstvan]

To be honest, I'm more inclined to learn Common Lisp, not Scheme for the time being, but I'm sure I'll give it a try in the near future.

[Screamer]

Making my first post ever to strongly advise you not to learn Common Lisp unless you have some direct intention to use a particular book that uses the language (ie, Norvig's AIMA).

I know you can't tell at the moment, but Common Lisp is a LONG dead dialect. There has been some strange revival going on recently (thanks for being a horrendous propaganda machine, Paul Graham!), but pretty please don't get into it. I learnt Common Lisp as my first language. There are a number of serious, unfixable shortcomings in the language. One of which is the fact that everyone uses the LOOP macro or perhaps that ITERATE macro if you aren't a beginner (which is quite rare - a lot of people get out of CL as soon as they see what Scheme can do). Another of which is the fact that because of the lack of an important optimisation in many implementations (and in the standard), functional programming is basically not possible. In fact, 99% of all Common Lisp code out there is imperative.

If you want to get into Lisp (and I think that is a _great_ idea), please use Scheme or better yet, Clojure instead. Scheme has the best teaching materials of any language, ever, making it a doddle to get into. Clojure has less good teaching materials, though the video lectures are quite good, but includes concurrency primitives that make it worth learning.

The thing you never hear from Common Lisp evangelists is that Common Lisp died because it was inferior to the other, more interesting directions other languages were going in at the time. I'm talking about Scheme and ML. If you learn Common Lisp all you are learning is the level of the mathematical/functional programming research community's progress as of early 1980s. The long and short of it is that everyone decided to move towards greater purity. Better to just pick up at somewhere a few decades nearer to the cutting edge now by learning Scheme or Clojure (or Haskell, if you are interested). There is a reason that the guy who literally wrote [b]the[/b] book on Common Lisp (and Scheme as a matter of fact) is now publishing a paper that looks at parallelism for Haskell at this year's ICFP (the most prestigious publishing venue for this research).

If I have not managed to change your mind, I would advise you to use a book that treats Common Lisp as a vehicle for functional programming, rather than a book that treats Common Lisp uncritically as a cargo cult in it's own right (PCL): http://www.cs.cmu.edu/~dst/LispBook/index.html

[LakatosIstvan]

Thanks for the friendly advise.

Clojure seems like a really useful language to learn, seeing that it runs on Java virtual machines. Does that mean that after writing my program and compiling it, it can run on any computer on which Java is installed?

[Hijax]

i've also considered learning lisp, and i must say, this thread was really helpful

@screamer: damn, i just bought a common lisp book. rats. well, i hope that will at least come in handy learning scheme/clojure. i mean, same language, just a different dialect, right?

[LakatosIstvan]

Well, as far as I can tell the basic syntax is the same, only the names of the commands change from dialect to dialect, and also certain dialects have special features and such.

[LakatosIstvan]

Ok, now I don't know what to do In the city library I found a nice thick book about Artificial Intelligence programming, and the source code is written in Common Lisp. And I would really like to read and understand the book.

Oh well, I guess I'll just have to learn both Common and Clojure Lisp

[Screamer]

Clojure seems like a really useful language to learn, seeing that it runs on Java virtual machines. Does that mean that after writing my program and compiling it, it can run on any computer on which Java is installed?

Yes.

@screamer: damn, i just bought a common lisp book. rats. well, i hope that will at least come in handy learning scheme/clojure. i mean, same language, just a different dialect, right?

Kinda. Of the book you've bought, most likely CLOS and LOOP are a complete waste of time. Also, macros vary significantly by dialect. In addition, a CL book will not have the same "stricter" approach to functional programming (for example, most CL books don't have a very deep explanation of recursion, with the exception of the book I linked). Basically, the benefits you get from functional programming are directly proportional to how "strict" you are about it. Unless you treat it as something very different, you don't get much benefit.

Ok, now I don't know what to do In the city library I found a nice thick book about Artificial Intelligence programming, and the source code is written in Common Lisp.

Sounds like you've found Norvig's earlier AI book: PAIP. If it is, the AI stuff is pretty out of date. AIMA is his later book, which focuses more on the concepts of AI than a language (though the examples are available in CL and Python).

Hope you have fun with whatever you decide to do.

[Berengal]

Basically, the benefits you get from functional programming are directly proportional to how "strict" you are about it. Unless you treat it as something very different, you don't get much benefit.

I agree with your first sentiment, but not with your second.

Perhaps I'm just too used to a functional style of programming (Haskell being my main language), but I find I use functional idioms in other languages all the time (depending on how hard they are to use. Java gets little love from me). My pythonic style, for example, is something like regualr python style but with fewer objects and unrestrained use of closures and generators.

Functional programming is more than just functions, and the more functional your language and your style, the better your code will be (in my opinion that is), but even a tiny sprinkle of the functional paradigm can have good benefits.

[Screamer]

Basically, the benefits you get from functional programming are directly proportional to how "strict" you are about it. Unless you treat it as something very different, you don't get much benefit.

I agree with your first sentiment, but not with your second.

Perhaps I'm just too used to a functional style of programming (Haskell being my main language), but I find I use functional idioms in other languages all the time (depending on how hard they are to use. Java gets little love from me). My pythonic style, for example, is something like regualr python style but with fewer objects and unrestrained use of closures and generators.

Functional programming is more than just functions, and the more functional your language and your style, the better your code will be (in my opinion that is), but even a tiny sprinkle of the functional paradigm can have good benefits.

Well, relative to Haskell, Python has little of the benefits of fp. Try and do concurrency for example: without referential transparency guarantees and STM, it becomes quite difficult.

[Berengal]

Basically, the benefits you get from functional programming are directly proportional to how "strict" you are about it. Unless you treat it as something very different, you don't get much benefit.

I agree with your first sentiment, but not with your second.

Perhaps I'm just too used to a functional style of programming (Haskell being my main language), but I find I use functional idioms in other languages all the time (depending on how hard they are to use. Java gets little love from me). My pythonic style, for example, is something like regualr python style but with fewer objects and unrestrained use of closures and generators.

Functional programming is more than just functions, and the more functional your language and your style, the better your code will be (in my opinion that is), but even a tiny sprinkle of the functional paradigm can have good benefits.

Well, relative to Haskell, Python has little of the benefits of fp. Try and do concurrency for example: without referential transparency guarantees and STM, it becomes quite difficult.

Sure, you don't gain all the benefits, and e.g. easier concurrency is something you don't get (also message passing is the superior concurrency paradigm, something the GIL practically forces you into in python anyway) but that doesn't mean the benefits you do get are "little" or any other synonym of "insignificant".

Also, please enable bbcode in your posts.

[Screamer]

They really are little, insignificant and the rest of the thesaurus entry for "small". You might get some benefits relative to how well Python works, but it's not as if you are suddenly using Haskell. The datastructures and flow control techniques in Python are just incompatible with the modern functional style. For one, Python's "lists" are actually mutable arrays (ouch, there goes time complexity). For two, Python has no TCO - "for" is passable for simple loops, but complex mappings quickly get silly. For three, explicit laziness has tradeoffs that don't really play to the favour of a functional style. For four, Python's syntax choices make defining anonymous functions difficult. For five, Python functions have to be written in a currying style manually. I could go on...but let's not.

Also, for the record, STM is an abstraction over message passing that's feasible when you have immutability and side effect guarantees.

[quintopia]

I'm gonna give my support for CLISP on Emacs as well. Screamer is just a ninny. The loop macro is very useful if you don't overuse it.

[Screamer]

^ Even the people who like Common Lisp use ITERATE. Considering that LOOP is the only constant space iteration facility in CL, what you're saying amounts to "don't loop too much and you'll be fine".

[scarecrovv]

Kinda. Of the book you've bought, most likely CLOS and LOOP are a complete waste of time. Also, macros vary significantly by dialect.

WOAH! Hang on a minute there. Did you just call CLOS a waste of time?

I leared CL back in January, and my favorite book since then has been, you guessed it, Practical Common Lisp. I'm still a relative newbie, and my general impression so far (coming from a background of Perl, C, C++, and Python) is that CL is the best thing since sliced bread, CLOS especially. I don't know what incredible joy you've found in the object systems of languages and lisp dialects yet unknown to me, but nothing I've ever heard of can touch CLOS. Method combination and multi-methods are especially awesome to me. Aside from a few relatively minor nitpicks, Common Lisp is miles ahead of all other languages I know.

Now in all seriousness, if there is something better than CLOS specifically, and Common Lisp in general, I need to know about it before I waste any more time with something big I'm doing in CL (and having a jolly good time with, by the way). If you could point me to a wikipedia article, or something else that would make a great jumping off point for future research, I would be immensely indebted to you. Of course, I'm also about to investigate Clojure now, since you seem to like it.

Another thing that's important to me is either an OpenGL implementation, another other 3D graphics library, or a decent FFI to C.

[qbg]

Now in all seriousness, if there is something better than CLOS specifically, and Common Lisp in general, I need to know about it before I waste any more time with something big I'm doing in CL (and having a jolly good time with, by the way). If you could point me to a wikipedia article, or something else that would make a great jumping off point for future research, I would be immensely indebted to you. Of course, I'm also about to investigate Clojure now, since you seem to like it.

Another thing that's important to me is either an OpenGL implementation, another other 3D graphics library, or a decent FFI to C.

For a language for futher research, Factor is a rather awesome language which is very lispy, and is very different from Lisp. Its CLOS inspired object system doesn't have multimethods yet, but it is better integrated with the rest of the language (sequences are generic, for instance). It also has easy FFI and many libraries come with it (mainly because there is only one implementation, but anyways...). Main difference is that it's stack based, so it will likely be very different than anything you have used before...

Still, Common Lisp is a great language.

[quintopia]

^ Even the people who like Common Lisp use ITERATE. Considering that LOOP is the only constant space iteration facility in CL, what you're saying amounts to "don't loop too much and you'll be fine".

Actually, that is what I'm saying. About half the time you can find a recursive method that works just as well (and I do believe that CLISP optimizes tail recursion to be constant space, correct?)

[Briareos]

(and I do believe that CLISP optimizes tail recursion to be constant space, correct?)

I do not think that CLISP demands this. Scheme definitely demands it, of course.

[qbg]

(and I do believe that CLISP optimizes tail recursion to be constant space, correct?)

The Common Lisp spec doesn't require it, but many compilers will do it with the appropriate settings in the simple case. (Having to unbind dynamic variables after the function is an example of a hard case.)

[phlip]

^ Even the people who like Common Lisp use ITERATE. Considering that LOOP is the only constant space iteration facility in CL, what you're saying amounts to "don't loop too much and you'll be fine".

Actually, that is what I'm saying. About half the time you can find a recursive method that works just as well (and I do believe that CLISP optimizes tail recursion to be constant space, correct?)

CLISP is a pretty weak implementation in the respect that the answer is "yes" if you compile and "no" if you do not. The problem being that debugging is pretty hard if you compile and so you end up in a dynamically typed language, unable to properly debug functional-style code. SBCL is better in this respect (and others).

That said, the CL standard doesn't ever guarantee TCO (hence the fruitiness between different implementations) and the frequent use of things like ITERATE are pretty nasty, imo. Better just to use a language which properly supports it.

CLOS and LOOP are a waste of time if you're trying to learn functional programming from a CL book.

[zbeekman]

A quick note about Fortran. People love to knock it. Some features are worth complaining about. The language, however, has undergone significant changes, with the f77, f90, f95, f2003, and f2008 revisions. Just like any language, one should only choose Fortran if it suits the task at hand. If that task is extremely large parallel numerical simulations fortran is an excellent choice. If your simulation is cheap, then god yes, by all means use python or Matlab. If however you are computing the flow around a spacecraft entering Titan's atmoshphere at 60km/s then yes, you probably should consider using Fortran. Fortran is designed and maintained explicitly for scientific computations. It even plays nice with Python.

The good language features are:
liberal language specification (gives compiler vendors lots of flexibility and freedom in implementing optimizing compilers)
syntactic parallelism
rich mathematical and array functionality

Fortran 2008 is even fully object oriented (although not fully supported by compiler vendors yet) vs f77 which doesn't quite qualify as a structured programming language due to lack of free-form source

The bad features are:
VERBOSE (It takes a lot of typing to say things well)
liberal language specification (e.g. new language features are buggy or take a long time to roll out, also integer representation is not specified so it might be twos compliment or something else, so if you want to write say a simple hash function to hash text you're better off using c)
hard to make GUIs (but you can call Fortran from Python,c,etc.)

Any way this is just a quick rant to say that people love to bash Fortran, but, just like any other languiages, there are some jobs it does very well and others that you should not even attempt. Also these people usually have no experience with Fortran, or only experience with older Fortran written poorly by some scientist or engineer with no programming background. I share your pain here, old Fortran ( <= 77) is particularly painful to deal with especially if it's not well written, but MODERN Fortran serves it's purpose and is a lovely langauge to use when solving the types of problems it was designed for.

[Screamer]

Congratulations on finding and resurrecting a four year old thread.

[EvanED]

Especially to post something that is only very tangentially related to the thread.

But since it's up, I'll say that I really Clojure. I'm not too too familiar with it, but I have written a bit. I really like the immutability model, and I like the other benefits you get over stuff like Scheme and Common Lisp with stuff like first-class dictionaries. (And the implementation of their hash-based persistent dictionary is really interesting; it'd dead simple and is basically unlike anything I've seen in any class.)