I would like to try some programming in Lisp, could you give me some advice? I have noticed that in the programming community this topic is prone to heavy mindkilling, which is why I ask on LW instead of somewhere else.
There are many variants of Lisp. I would prefer to learn one that is really used these days for developing real-world applications. Something I could use to make e.g. a Tetris-like game. I will probably need some libraries for input and output; which ones do you recommend? I want a free software that works out of the box; preferably on a Windows machine, without having to install a Linux emulator first. (If such thing does not exist, please tell me; and recommend me a second best possibility.)
I would also like to have a decent development environment; something that allows me to manage multiple source code files, does syntax highlighting, shows documentations to the functions I am writing. Again, preferably free, working out of the box on a Windows machine. Simply, I would like to have an equivalent of what Eclipse is for Java.
Then, I would like some learning resources, and information where can I find good open-source software written in Lisp, preferably games.
My research suggests Clojure is a lisp-like language most suited to your requirements. It runs on the JVM so should be relatively low hassle on Windows. I believe there’s some sort of Eclipse support but I can’t confirm it.
If you do end up wanting to do something with Common Lisp, I recommend Practical Common Lisp as a good free introduction.
Well, if your goal is trying out for education, but on Windows, you could start with DrRacket. http://racket-lang.org/
It is a reasonable IDE, it has some GUI libraries included, open-source, cross-platform, works fine on Windows.
Racket is based on Scheme language (which is a part of Lisp language family). It has a mode for
Scheme as described in R6RS or R5RS standard, and it has a few not-fully-compatible dialects.
I use Common Lisp, but not under Windows. Common Lisp has more cross-implementation libraries, it could be useful sometimes. Probably, EQL is the easiest to set up under Windows (it is ECL, a Common Lisp implementation, merged with Qt for GUI; I remember there being a bundled download). Maybe CommonQt or Cells-GTK would work. I remember that some of the Common Lisp package management systems have significant problems under Windows or require either Cygwin or MSys (so they can use tar, gzip, mkdir etc. as if they were on a Unix-like system)
My goals are: 1) to get the “Lisp experience” with minimum overhead; and 2) to use the best available tools.
And I hope these two goals are not completely contradictory. I want to be able to write my own application on my computer conveniently after a few minutes, and to fluently progress to more complex applications. On the other hand, if I happen to later decide that Lisp is not for me, I want to be sure it was not only because I chose the wrong tools.
Thanks for all the answers! I will probably start with Racket.
For a certain value of “the Lisp experience”, Emacs may be considered more or less mandatory. In order to recommend for or against it I would need more precise knowledge of your goals.
I tried Emacs and decided that I dislike it. I understand the reason why it is like that, but I refuse to lower my user interface expectations that low.
Generally, I have noticed the trend that a software which is praised as superior often comes with a worse user interface, or ignores some other part of user experience. I can understand that a software with smaller userbase cannot put enough resources to its non-critical parts. That makes sense. But I suspect there later appears a mindkilling thread of though, which goes like this: “Our software is superior. Our software does not have a feature X. Therefore, not having a feature X is an advantage, because .” As in: we don’t need 21st-century-style user interface, because good programmers don’t need such things.
By wanting a “Lisp experience” I mean I would like to experience (or falsify the existence of) the nirvana frequently described by Paul Graham. Not to replicate 1:1 Richard Stallman’s working conditions in 1980s. :D
A perfect solution would be to combine the powerful features of Lisp with the convenience of modern development tools. I emphasize the convenience for pragmatic reasons, but also as a proxy for “many people with priorities similar to me are using it”.
Generally, I have noticed the trend that a software which is praised as superior often comes with a worse user interface, or ignores some other part of user experience.
Consider an equilibrium of various software products none of which are strictly superior or inferior to each other. Upon hearing that the best argument someone can make for software X is that it has feature Y (which is unrelated to UI), should your expectation of good IU go up or go down?
(To try it a different way: suppose you are in a highly competitive company like Facebooglazon and you meet a certain programmer who is the rudest most arrogant son of a bitch you ever met—yet he is somehow still employed there. What should you infer about the quality of the code he writes?)
This is a nice example how with different models the same evidence can be evaluated differently.
My model is that programming languages are used for making programs, and for languages used in real production part of that effort goes to the positive-feedback loop of creating better tools and libraries for given language. So if some language makes the production easier—people like Paul Graham suggest that Lisp is 10 times more productive than other languages --, I would expect better everything.
In other words, the “equilibrium of various software products none of which are strictly superior or inferior to each other” is an evidence against the claim that a language X is 10 times more productive than other languages. Or if it is more productive in some areas, then it must have a huge disadvantage somewhere else.
suppose you are in a highly competitive company like Facebooglazon and you meet a certain programmer who is the rudest most arrogant son of a bitch you ever met—yet he is somehow still employed there. What should you infer about the quality of the code he writes?
Fast, reliable, undocumented, obfuscated. :D
Or he is really imployed for some other reason than writing code.
In other words, the “equilibrium of various software products none of which are strictly superior or inferior to each other” is an evidence against the claim that a language X is 10 times more productive than other languages. Or if it is more productive in some areas, then it must have a huge disadvantage somewhere else.
Yup! It’s the old ‘if you’re so good, why aren’t you rich’ question in more abstract guise. Of course, in the real world, new languages are being developed all the time, so a workable answer is already ‘I’m not rich because I’m so new, but I’m getting richer’. This is the sort of answer an up and coming language like Haskell or Scala or Go can make.
My current understanding of present IDEs is that they are both very language-bound and need a huge amount of work to become truly usable. That means that for any language that doesn’t currently enjoy large industry acceptance, I basically don’t expect to have any sort of modern usable IDE.
I’m not personally hung up on the Emacs thing, but then again my recipe for a development environment is Your Favorite General Purpose Text Editor, printf statements for debugging code, a console to read the printf output, and a read-eval-print-loop for the programming language if has one (Lisp does).
If most of the people who are in position to develop modern development tools for Lisp are in fact happy using Emacs and SLIME, the result is going to be that there won’t be much of a non-Emacs development environment ecosystem for Lisp. And it’s unlikely that there are any unearthed gems that turn out to be outstanding modern Lisp IDEs if IDEs really do require lots and lots of work and a wide user base giving feedback to be truly useful. Though Lisp does have commercial niche companies who are still around and who have had decades of income to develop whatever proprietary tools they are using. I’ve no idea what kind of stuff they have got.
Speaking of the general Lisp experience, you might also want to take a look at Factor. It’s primarily modeled after Forth instead of Lisp, but it basically matches all of Graham’s “What made Lisp different” checklist. The code is data, the metaprogramming machinery is extensive and so on. The idiom is also somewhat more weird than Lisp’s, and the programs are constantly threatening to devolve into a soup of incomprehensible three-letter opcodes, but I found the thing fun to work with. Oh, and the only IDE Factor has is Emacs-based, unless you count the language REPL, I think its ecosystem is small enough that I haven’t missed any significant competitors.
Well, for me Vim bindings are something that (after some learning) started to make a lot of sense. Emacs (after the same amount of learning) didn’t make that much sense… As text editors, modern IDEs are still weaker than any of them; the choice what to forfeit usually has to be done—sometimes you can embed your editor inside IDE instead of the native one, though.
For satisfying your curiousity, I guess you could try out free-of-charge Allegro Common Lisp version. It is personal no-deployment no-commercial-use no-commercial-research no-university-research no-government researh edition. I never looked at it because I am OK with Vim and I don’t want to have something dependent on ACL that I cannot use in my day-job projects. Neither is a good reason for you not to try it...
a worse user interface, or ignores some other part of user experience
Many people say that most things that aren’t emacs (or vim, depending on their religion...) have bad user interfaces, myself included. The keyboard-only way of working is very nice if you can get the hang of it. (Emacs is hard to begin with.)
That said, SLIME is basically the canonical Common Lisp editing environment and many the environment for other dialects emulate many of its features (e.g. Geiser for Racket), were you using one of those when you were using Emacs with a Lisp?
I used Emacs very shortly, only as a text editor. The learning curve is horrible—my impression is that you need to memorize dozens of new keyboard shortcuts (and unlearn dozens of keyboard shortcuts more or less consistently accepted by many other applications, also clicking right mouse button for a context menu). There seem to be some interesting features, but again only for those who memorize the keyboard shortcuts. And the whole design seems like a character terminal emulator.
So the problem is that it looks interesting, but one has to pay a huge price ahead. That would make sense if I were already convinced that Emacs is the only editor and Lisp the only programming language I will use, but I just want to try them.
By the way, what exactly is so great about “the keyboard-only way of working”? Is it the speed of typing? I usually spend more time thinking about the problem than typing. Are some powerful features invoked by keyboard combos? I would prefer them to be available from the menu and context menu. Or both from menu and as a keyboard shortcut, so I can memorize the frequently-used ones, but not the rest. (Maybe this is possible in Emacs too. If yes, the tutorial should mention it.)
To me it now seems that learning Lisp with Emacs would be having two problems instead of one. More precisely, to make the learning curve even worse.
There’s a solution to the unfamiliar shortcuts problem: turn on CUA mode. CUA mode enables the familiar Ctrl-Z, Ctrl-X, Ctrl-C, Ctrl-V for undo, cut, copy, and paste, respectively. For basic text navigation, I use Emacs mostly like an editor with standard bindings (the aforementioned undo-cut-copy-paste, arrow keys to move by character, Control plus arrow keys to move by word, &c.). There are other things to learn, but the transition isn’t really that bad.
By the way, what exactly is so great about “the keyboard-only way of working”? Is it the speed of typing? I usually spend more time thinking about the problem than typing. Are some powerful features invoked by keyboard combos?
Speed, features and working well for many languages (i.e. people have written Emacs modes for most language).
Having everything on the keyboard means that you don’t have to do so many context switches (which are annoying and I find they can distrupt my train of though). As an example, in most word processors, bolding text with Shift+arrow keys then Ctrl+B is much much nicer than moving to the mouse, carefully selecting the text and then going up to the menu bar to click the little icon.
And Emacs has been around for decades, so there are hundreds of little (or not so little) packages that do anything and everything, e.g. editing a file via SSH transparently is pretty nice.
Having one environment for writing a LaTeX report, a Markdown file, a C, Haskell, Python or Shell (etc) program is nice because the basic shortcuts are the same and every environment is guaranteed to act how you expect, so, for example, doing a regex string replacement is the same process.
And on the note of keyboard combos, they are something that you end up learning by muscle memory, so it takes a little while but they become second nature, to the point of not being able to say what the shortcut is straight out, only able to work it out by actually doing the action.
(That said, Emacs/Vim isn’t for everyone: maybe it’s the time investment is too large, or it doesn’t really suit one’s way of working.)
Well, I have a paid job where I write in Common Lisp, and I use Vim, and both statements (paid job with CL and Vim usage) are true for multiple years.
It is a good idea to know there are different options and have a look at them, of course.
It is a good idea to look at Cream-for-Vim, too—it has Vim as a core, and most mode allow you to use Vim bindings for a while, but default bindings are more consistent with modern traditions.
There are no “best available tools” without specified target, unfortunately. When you feel that Racket constraints you, come back to the open thread of week, and ask what you would like to see in it—SBCL has better performance, ECL is easier to use for standalone executables, etc. Also, maybe someone would recommend you an in-Racket dialect that would work better for you for those tasks.
Peter Norvig’s out-of-print Paradigms of Artificial Intelligence Programming: Case Studies in Common Lisp can be interesting reading. It develops various classic AI applications like game tree search and logic programming, making extensive use of Lisp’s macro facilities. (The book is 20 years old and introductory, it’s not recommended for learning anything very interesting about artificial intelligence.) Using the macro system for metaprogramming is a big deal with Lisp, but a lot of material for Scheme in particular doesn’t deal with it at all.
The already mentioned Clojure seems to be where a lot of real-world development is happening these days, and it’s also innovating on the standard syntax conventions of Common Lisp and Scheme in interesting ways. Clojure will interface with Java’s libraries for I/O and multimedia. Since Clojure lives in the Java ecosystem, you can basically start with your preconceptions for developing for JVM and go from there to guess what it’s like. If you’re OK with your games ending up JVM programs, Clojure might work.
I would like to try some programming in Lisp, could you give me some advice? I have noticed that in the programming community this topic is prone to heavy mindkilling, which is why I ask on LW instead of somewhere else.
There are many variants of Lisp. I would prefer to learn one that is really used these days for developing real-world applications. Something I could use to make e.g. a Tetris-like game. I will probably need some libraries for input and output; which ones do you recommend? I want a free software that works out of the box; preferably on a Windows machine, without having to install a Linux emulator first. (If such thing does not exist, please tell me; and recommend me a second best possibility.)
I would also like to have a decent development environment; something that allows me to manage multiple source code files, does syntax highlighting, shows documentations to the functions I am writing. Again, preferably free, working out of the box on a Windows machine. Simply, I would like to have an equivalent of what Eclipse is for Java.
Then, I would like some learning resources, and information where can I find good open-source software written in Lisp, preferably games.
My research suggests Clojure is a lisp-like language most suited to your requirements. It runs on the JVM so should be relatively low hassle on Windows. I believe there’s some sort of Eclipse support but I can’t confirm it.
If you do end up wanting to do something with Common Lisp, I recommend Practical Common Lisp as a good free introduction.
Well, if your goal is trying out for education, but on Windows, you could start with DrRacket. http://racket-lang.org/
It is a reasonable IDE, it has some GUI libraries included, open-source, cross-platform, works fine on Windows.
Racket is based on Scheme language (which is a part of Lisp language family). It has a mode for Scheme as described in R6RS or R5RS standard, and it has a few not-fully-compatible dialects.
I use Common Lisp, but not under Windows. Common Lisp has more cross-implementation libraries, it could be useful sometimes. Probably, EQL is the easiest to set up under Windows (it is ECL, a Common Lisp implementation, merged with Qt for GUI; I remember there being a bundled download). Maybe CommonQt or Cells-GTK would work. I remember that some of the Common Lisp package management systems have significant problems under Windows or require either Cygwin or MSys (so they can use tar, gzip, mkdir etc. as if they were on a Unix-like system)
My goals are: 1) to get the “Lisp experience” with minimum overhead; and 2) to use the best available tools.
And I hope these two goals are not completely contradictory. I want to be able to write my own application on my computer conveniently after a few minutes, and to fluently progress to more complex applications. On the other hand, if I happen to later decide that Lisp is not for me, I want to be sure it was not only because I chose the wrong tools.
Thanks for all the answers! I will probably start with Racket.
For a certain value of “the Lisp experience”, Emacs may be considered more or less mandatory. In order to recommend for or against it I would need more precise knowledge of your goals.
I tried Emacs and decided that I dislike it. I understand the reason why it is like that, but I refuse to lower my user interface expectations that low.
Generally, I have noticed the trend that a software which is praised as superior often comes with a worse user interface, or ignores some other part of user experience. I can understand that a software with smaller userbase cannot put enough resources to its non-critical parts. That makes sense. But I suspect there later appears a mindkilling thread of though, which goes like this: “Our software is superior. Our software does not have a feature X. Therefore, not having a feature X is an advantage, because .” As in: we don’t need 21st-century-style user interface, because good programmers don’t need such things.
By wanting a “Lisp experience” I mean I would like to experience (or falsify the existence of) the nirvana frequently described by Paul Graham. Not to replicate 1:1 Richard Stallman’s working conditions in 1980s. :D
A perfect solution would be to combine the powerful features of Lisp with the convenience of modern development tools. I emphasize the convenience for pragmatic reasons, but also as a proxy for “many people with priorities similar to me are using it”.
Consider an equilibrium of various software products none of which are strictly superior or inferior to each other. Upon hearing that the best argument someone can make for software X is that it has feature Y (which is unrelated to UI), should your expectation of good IU go up or go down?
(To try it a different way: suppose you are in a highly competitive company like Facebooglazon and you meet a certain programmer who is the rudest most arrogant son of a bitch you ever met—yet he is somehow still employed there. What should you infer about the quality of the code he writes?)
This is a nice example how with different models the same evidence can be evaluated differently.
My model is that programming languages are used for making programs, and for languages used in real production part of that effort goes to the positive-feedback loop of creating better tools and libraries for given language. So if some language makes the production easier—people like Paul Graham suggest that Lisp is 10 times more productive than other languages --, I would expect better everything.
In other words, the “equilibrium of various software products none of which are strictly superior or inferior to each other” is an evidence against the claim that a language X is 10 times more productive than other languages. Or if it is more productive in some areas, then it must have a huge disadvantage somewhere else.
Fast, reliable, undocumented, obfuscated. :D
Or he is really imployed for some other reason than writing code.
Yup! It’s the old ‘if you’re so good, why aren’t you rich’ question in more abstract guise. Of course, in the real world, new languages are being developed all the time, so a workable answer is already ‘I’m not rich because I’m so new, but I’m getting richer’. This is the sort of answer an up and coming language like Haskell or Scala or Go can make.
My current understanding of present IDEs is that they are both very language-bound and need a huge amount of work to become truly usable. That means that for any language that doesn’t currently enjoy large industry acceptance, I basically don’t expect to have any sort of modern usable IDE.
I’m not personally hung up on the Emacs thing, but then again my recipe for a development environment is Your Favorite General Purpose Text Editor, printf statements for debugging code, a console to read the printf output, and a read-eval-print-loop for the programming language if has one (Lisp does).
If most of the people who are in position to develop modern development tools for Lisp are in fact happy using Emacs and SLIME, the result is going to be that there won’t be much of a non-Emacs development environment ecosystem for Lisp. And it’s unlikely that there are any unearthed gems that turn out to be outstanding modern Lisp IDEs if IDEs really do require lots and lots of work and a wide user base giving feedback to be truly useful. Though Lisp does have commercial niche companies who are still around and who have had decades of income to develop whatever proprietary tools they are using. I’ve no idea what kind of stuff they have got.
Speaking of the general Lisp experience, you might also want to take a look at Factor. It’s primarily modeled after Forth instead of Lisp, but it basically matches all of Graham’s “What made Lisp different” checklist. The code is data, the metaprogramming machinery is extensive and so on. The idiom is also somewhat more weird than Lisp’s, and the programs are constantly threatening to devolve into a soup of incomprehensible three-letter opcodes, but I found the thing fun to work with. Oh, and the only IDE Factor has is Emacs-based, unless you count the language REPL, I think its ecosystem is small enough that I haven’t missed any significant competitors.
Well, for me Vim bindings are something that (after some learning) started to make a lot of sense. Emacs (after the same amount of learning) didn’t make that much sense… As text editors, modern IDEs are still weaker than any of them; the choice what to forfeit usually has to be done—sometimes you can embed your editor inside IDE instead of the native one, though.
For satisfying your curiousity, I guess you could try out free-of-charge Allegro Common Lisp version. It is personal no-deployment no-commercial-use no-commercial-research no-university-research no-government researh edition. I never looked at it because I am OK with Vim and I don’t want to have something dependent on ACL that I cannot use in my day-job projects. Neither is a good reason for you not to try it...
Many people say that most things that aren’t emacs (or vim, depending on their religion...) have bad user interfaces, myself included. The keyboard-only way of working is very nice if you can get the hang of it. (Emacs is hard to begin with.)
That said, SLIME is basically the canonical Common Lisp editing environment and many the environment for other dialects emulate many of its features (e.g. Geiser for Racket), were you using one of those when you were using Emacs with a Lisp?
I used Emacs very shortly, only as a text editor. The learning curve is horrible—my impression is that you need to memorize dozens of new keyboard shortcuts (and unlearn dozens of keyboard shortcuts more or less consistently accepted by many other applications, also clicking right mouse button for a context menu). There seem to be some interesting features, but again only for those who memorize the keyboard shortcuts. And the whole design seems like a character terminal emulator.
So the problem is that it looks interesting, but one has to pay a huge price ahead. That would make sense if I were already convinced that Emacs is the only editor and Lisp the only programming language I will use, but I just want to try them.
By the way, what exactly is so great about “the keyboard-only way of working”? Is it the speed of typing? I usually spend more time thinking about the problem than typing. Are some powerful features invoked by keyboard combos? I would prefer them to be available from the menu and context menu. Or both from menu and as a keyboard shortcut, so I can memorize the frequently-used ones, but not the rest. (Maybe this is possible in Emacs too. If yes, the tutorial should mention it.)
To me it now seems that learning Lisp with Emacs would be having two problems instead of one. More precisely, to make the learning curve even worse.
There’s a solution to the unfamiliar shortcuts problem: turn on CUA mode. CUA mode enables the familiar Ctrl-Z, Ctrl-X, Ctrl-C, Ctrl-V for undo, cut, copy, and paste, respectively. For basic text navigation, I use Emacs mostly like an editor with standard bindings (the aforementioned undo-cut-copy-paste, arrow keys to move by character, Control plus arrow keys to move by word, &c.). There are other things to learn, but the transition isn’t really that bad.
Speed, features and working well for many languages (i.e. people have written Emacs modes for most language).
Having everything on the keyboard means that you don’t have to do so many context switches (which are annoying and I find they can distrupt my train of though). As an example, in most word processors, bolding text with
Shift+arrow keysthenCtrl+Bis much much nicer than moving to the mouse, carefully selecting the text and then going up to the menu bar to click the little icon.And Emacs has been around for decades, so there are hundreds of little (or not so little) packages that do anything and everything, e.g. editing a file via SSH transparently is pretty nice.
Having one environment for writing a LaTeX report, a Markdown file, a C, Haskell, Python or Shell (etc) program is nice because the basic shortcuts are the same and every environment is guaranteed to act how you expect, so, for example, doing a regex string replacement is the same process.
And on the note of keyboard combos, they are something that you end up learning by muscle memory, so it takes a little while but they become second nature, to the point of not being able to say what the shortcut is straight out, only able to work it out by actually doing the action.
(That said, Emacs/Vim isn’t for everyone: maybe it’s the time investment is too large, or it doesn’t really suit one’s way of working.)
Well, I have a paid job where I write in Common Lisp, and I use Vim, and both statements (paid job with CL and Vim usage) are true for multiple years.
It is a good idea to know there are different options and have a look at them, of course.
It is a good idea to look at Cream-for-Vim, too—it has Vim as a core, and most mode allow you to use Vim bindings for a while, but default bindings are more consistent with modern traditions.
There are no “best available tools” without specified target, unfortunately. When you feel that Racket constraints you, come back to the open thread of week, and ask what you would like to see in it—SBCL has better performance, ECL is easier to use for standalone executables, etc. Also, maybe someone would recommend you an in-Racket dialect that would work better for you for those tasks.
Peter Norvig’s out-of-print Paradigms of Artificial Intelligence Programming: Case Studies in Common Lisp can be interesting reading. It develops various classic AI applications like game tree search and logic programming, making extensive use of Lisp’s macro facilities. (The book is 20 years old and introductory, it’s not recommended for learning anything very interesting about artificial intelligence.) Using the macro system for metaprogramming is a big deal with Lisp, but a lot of material for Scheme in particular doesn’t deal with it at all.
The already mentioned Clojure seems to be where a lot of real-world development is happening these days, and it’s also innovating on the standard syntax conventions of Common Lisp and Scheme in interesting ways. Clojure will interface with Java’s libraries for I/O and multimedia. Since Clojure lives in the Java ecosystem, you can basically start with your preconceptions for developing for JVM and go from there to guess what it’s like. If you’re OK with your games ending up JVM programs, Clojure might work.
For open-source games in Lisp, I can point you to David O’Toole’s projects. There are also some roguelikes developed in Lisp.