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