The fact that it’s built on Emacs is a problem, as telling a new user they
have to learn Emacs before using SLIME (which is not strictly true) is a
significant artificial barrier to entry.
Yes, it is true. It's ridiculous to expect a person new to a language to also learn Emacs. It is absolutely a significant barrier to entry.
It is a significant barrier to entry for everyone else, no doubt. But what are you going to do? There isn't any money in commercial Lisp environments anymore, at least outside certain niches. And the people who like Lisp enough to write an IDE for it already know how to use Emacs.
But you're not everyone else. Individually, it's worth learning for sure! I haven't encountered an environment quite as productive as SLIME/SBCL. I hear Clojure is all the rage these days and it has an IDE, but functional programming with immutable objects is a bit over my head.
There is little reason to use Eclipse or Intellij with Common Lisp. That's a non-starter.
Editors like vim can be used with Common Lisp just fine.
Most people I know just use Emacs/SLIME because it's reasonably advanced and can be used nicely via GUI or a terminal connection.
Personally I use the LispWorks for editing code, mostly. It has a Emacs/Hemlock-like editor written in Common Lisp built-in. I also use the Clozure CL on the Mac, which also has a hemlock-derived editor built-in.
Where Clojure naturally has better integration into the Java ecosystem (Java IDEs, too), Common Lisp has the better IDEs written in itself.
Since Clojure runs on the JVM and has a good interoperability with Java, it's easier to write plugins to for developing in Clojure using IDEs written in Java (mainly) for Java, like Eclipse or IntelliJ.
When I started learning CL, I tried Emacs for a week, but then gave up. I was a VIM user already.
So this is my development environment and I have been using it ever since, professionally as well. I have one tab in terminal which has VIM, another tab that runs CL REPL (I mostly use LW Professional that allows building a non IDE image or SBCL).
I start my REPL as such:
rlwrap -D 2 -m " \ " sbcl OR
rlwrap -D 2 -m " \ " lw-console
Then I my REPL I can just press: [Ctrl + ^] and it opens a temporary VIM Buffer, so I can type away my Lisp expression and when I quit the buffer, the expression is available on the REPL prompt.
I have the usual suspects: tagbar and exuberant ctags, to help. I don't use auto complete much (a quirk probably).
But the fact that I can save my lisp image and come back later and start where I left is the big difference, which I can't do in Python or C++ (AFAIK).
So a simple setup with Vim, rlwrap (with ability to open temp vim buffer) in a Lisp REPL is possible and also productive. Still Vim is another beast, so the rider here is one knows Vim, but may be another text editor should also work.
It would be nice if there was something like DrRacket[1] for Common Lisp, or maybe something like Haskell for Mac[2] that was on HN yesterday[3]. You could package it with SBCL and a link to "Practical Common Lisp" and newcomers could be typing in code within 5 minutes.
I like using Emacs myself, but a lot of people find it intimidating. I know coders who are smarter than me, (vim using C++ finance programmers even!) and I can't persuade them to try SBCL/SLIME.
Emacsophobia may be irrational (I didn't find it hard to learn once I stopped expecting to use modern ui conventions) but asking people to face up to their misgivings about a product is a hard sell compared to offering something slick and attractive.
I'd build it in a heartbeat if I thought there was any money in it. I really like Emacs/SLIME but the IDE story can be far better with integrated graphics and sound, FFI wrappers to system libraries, and built-in package management.
Unfortunately the Lisp meetups I go to are sparsely populated for a big city and they mostly talk about other languages; sometimes Clojure gets mentioned but hardly anyone uses Common Lisp. The whole, "not modern," thing seems to turn people off.
Are there even more than a couple hundred commercial Lisp users?
edit: I mean "build it," as in "build the Haskell for Mac" equivalent for CL. Something affordable and meant to be a tool; not a Lispworks or Clozure competitor.
I used emacs for about 10 years. Then I switched to vim, and I have no intention of switching back. It's not a phobia, it's a rational realization that modal editing fits well with how I do editing.
I tried learning lisp with SLIME and I hated it so much (especially compared to Visual Studio) that switched to notepad++ and running SBCL in my console. Eventually I lost interest in lisp, id like to get back to it, but SLIME has really left a bad impression on me.
I won't argue, slime, like a lot of emacs tools, are not necessarily the right tool for everybody, at all stage.
For very beginners, any editor they're familiar with will do (but if they're beginner, how would they be familiar with any editor? Just start with emacs, it's as simple as any other, click and point etc; you can try it anything you do with Notepad, do exactly the same with emacs and you will get the same results).
And indeed, using a CL implementation in the terminal (but with rlwrap if you're use a read-line deficient implementation; clisp has it included), for your first steps can be a better learning experience than using sophisticated GUIs.
Just like I wouldn't advise to use Xcode or Visual Studio to a beginner starting to learn C or C++: just edit your code with ed(1), and run { cc -o hw hw.c } in the terminal.
Be sure to teach in advanced lessons about the ed(1) command:
! cc -o hw hw.c && ./hw RET
like:
$ ed hw.lisp
hw.lisp: No such file or directory
i
(defun main ()
(princ "Hello World!")
(terpri))
(main)
.
w
59
!clisp -norc -q hw.lisp
Hello World!
!
1,$n
1 (defun main ()
2 (princ "Hello World!")
3 (terpri))
4 (main)
q
$
Somebody who lacks this experience, cannot understand the benefits of "IDE" or of emacs and slime. But also, the feature of calling out external programs like a compiler from an editor, exists in any good editor, not just emacs. Only it's emacs it's easier because you can customize it much more. It becomes clear when the newbie will have typed a hundred times:
!clisp -l myprogram.lisp -x '(main)' RET
Then you introduce him to emacs and slime and he will feel you're Jesus came back to save him.
If you lost interest in the language and won't take it up again because a feature you don't NEED (and is in fact unrelated to the language itself), then I'm prepared to say that's not really the problem here.
You're just not that into it and blaming SLIME or anything else that's part of the ecosystem is just misguided and wrong.
You compare SLIME with Visual Studio when they have almost nothing in common and most lispers detest the idea that you have to have something like Visual <anything> to work with a language.
If you really want to learn Lisp, sit down with an editor and start running code instead of trying to optimize for a problem you're likely never to stumble upon. When you get it, you'll gladly write Lisp even if they mandate that you're only allowed to use a chisel and stone tablets.
Are you aware that Smalltalk and Interlisp-D/Lisp Machines kind of defined how the first IDEs looked like?
It is kind of sad that one of the oldest languages that was in the genesis of IDEs and interactive programming should be like, only has Emacs nowadays in its open source offerings.
If you're talking about Symbolics Lisp machines I fail to see how the mess that is today's crowded IDEs full of crap have much in common with them. They had powerful tools for introspection and inspection and that seems to me like their defining features. That's a legacy that SLIME carries with it way more than any IDE for any IDE-heavy language.
I should have expanded on the 'not strictly true' bit: for a while I wrote code on Sublime Text and used the REPL from SLIME, with the windows side by side, as SublimeREPL was pretty terrible. And I was fairly productive, too.
Why? When someone learns Java they learn Eclipse or IntelliJ IDEA. When someone learns C++ they learn Visual Studio or QtCreator/KDevelop/CodeBlocks... And so on.
I don't think one can compare the difficulty of learning IntelliJ IDEA with the difficulty of learning Emacs. All of the editors you mentioned use a paradigm of text editing familiar to everyone who has used Notepad. When starting out with Emacs, you even need to learn how to quit it.
> I don't think one can compare the difficulty of learning IntelliJ IDEA with the difficulty of learning Emacs.
Of course you can. Granted, I don't use IntelliJ, but I used PyCharm, Komodo and Visual Studio, among others. Emacs is easier to learn: despite decades of cruft it's more consistent and follows the rule of least astonishment closer than PyCharm. The problem is that PyCharm and other IDEs build on conventions already familiar to most users (locking themselves to these conventions, which limits their usability for powerusers, but that's another matter), while Emacs doesn't. That's because Emacs predates these conventions. Still, there are many efforts which make Emacs much more familiar to "normal people".
As LightTable failed (and I'm not sure what's happening with Atom) Emacs is once again the most modern text and code editor.
> When starting out with Emacs, you even need to learn how to quit it.
I think you're thinking about VIM, and even there (with gVIM) it's not true. Do you seriously believe what you wrote or is it just flamebait?
Don't get me wrong, I love Emacs and I love Vim and I strongly recommend learning them — the effort is worth it. However, I don't think it's the case that you can compare their difficulty curves with those of a "normal" editor. You do, however, make a good point that Emacs is more consistent.
Anyhow, just for fun, decided to install Emacs, SBCL and Slime. Each is available in the standard Ubuntu repository. Open Emacs, M-x slime, and I'm programming in Common Lisp. Different for sure, but that's the point of Common Lisp. No one uses it because it's similar to Java or C, but because it promises things like interactive development, flexibility and customization.
By this argument, if I shipped a customized emacs with e.g. C-c for copy C-v for paste and C-q for quit, and slime and sbcl bundled inside, that would make slime as accessible as eclipse/intellij/visual studio?
I'm willing to try it (really not that hard to do), but I bet good money that many people would still balk because it's spelled E-M-A-C-S.
It absolutely is. I have spent some time hacking on the Eclipse Lisp plugin in an effort to remediate this, but I simply don't have the motivation anymore to do it for free - the code is in Java (and the codebase is in disrepair), the Eclipse plugin system is fragile, and I'd not really use the output (I use Emacs... a lot). If someone came to me and said that they'd like to use the tool, or offered to compensate me somehow, I'd go on and make it better.
OP is getting hate, but I write a lot of Clojure code in Emacs, and I find the following commands cover 97%+ of my usage, maybe more. For config I use Emacs Live out-of-the-box, and remap Command on OSX to be my Ctrl. That's it.
C-o for Ace-jump to go to the start of any words I see on the page.
C-d to delete.
C-s to search for words not on the page.
C-k, C-y, and also how to use them with paredit to yank whole s-expression chunks.
Buffer switching and killing.
File saving and opening.
I teach the above to any friends who want to learn Emacs/Clojure/LISP, leaving out a few other features like whole word deletion and more advanced paredit. With halfway decent aptitude and a little practice, they become productive very quickly (within a few hours, which is a pretty good investment relative to "normal" text editors in my book).
Also, you can use a lot of the commands for normal OSX text editing, which further improves the investment.
I think about three years went by between the first time I opened the Emacs tutorial and when I started using Emacs seriously.
So, sure, the barrier to entry doesn't look so high once you're past it, but insurmountable before. Specially when the official tutorial tells new users to move around the file using obscure key combinations and even the standard copy/paste/kill key combinations don't work.
> Specially when the official tutorial tells new users to move around the file using obscure key combinations
If you're a Mac user, they're actually - in all likelihood - not that obscure; you can use the same exact key combinations in pretty much every OS X application.
The built-in tutorial is indeed exceissively comprehensive, but those "obscure" keybindings are incredibly useful, particularly C-a and C-e (much faster than using "Home" or "End", respectively), which is why they're covered. And really, the Emacs bindings aren't any harder than the CUA bindings; they're just different, and can be easily gleaned (in graphical Emacs installations, at least) by poking around in the menu and looking at the shortcuts for certain commands, like opening/saving files or killing/yanking.
> and even the standard copy/paste/kill key combinations don't work.
This is easily fixable by going to Options -> Use CUA Keys, which enables C-x for kill, C-v for yank, and C-c for copy. OS X users can also just use Command-C/V/X like normal, with or without this option enabled.
> If you're a Mac user, they're actually - in all likelihood - not that obscure; you can use the same exact key combinations in pretty much every OS X application.
Apple doesn't go out of their way to really point this out. Ordinary Mac users have no idea about this. None!
It's easy to learn C-x C-s to save, C-x C-c to quit, C-x C-f to open a file. That's how I got by with emacs for about 6 months, just because I liked the tab/indent behaviour so much.
Then after that it's easy to learn the C-x chords for splitting windows, and you're at about the level where I used emacs for about 5 years, with maybe some C-c C-c to compile things.
Honestly emacs is not that hard and you can be pretty productive with just the bare minimum. I still don't use the arcane commands to move the cursor around. I don't even know what they are. I use the arrow keys and pgup/pgdown.
The standard copy and paste work for me. Just use the arrow keys and page up/down keys to navigate. Skip the complicated stuff and pretend you're using Notepad.
Skip the complicated stuff and pretend you're using Notepad.
No?
Being a beginner to Lisp doesn't imply being a beginner to programming. Why would an experienced non-Lisp programmer find being subjected to a Notepad-like development experience worth even the slightest consideration?
(EDIT: And non-experienced non-Lisp programmers also have a preferred tool-set, which is likely superior to Notepad.)
Emacs can be great - to some people. The "You have to use Emacs to program in Lisp" meme is not great.
You don't. Nobody stops you to use vim and fire
a clisp repl instead if you want.
Of course. And there could very well be a service that accepts handwritten source code via the post, transcribes it, executes it, and mails you the output.
In context, I'm responding to the following:
• the article's preference for beginner-friendly suggestions (e.g. don't overwhelm beginners with an abundance of choice)
• the specific text I quote in my original comment above, and
• the fact that Emacs+SLIME is the de facto standard answer to every Lisp beginner who asks for an IDE.
"Emacs+SLIME is the de facto standard answer to every Lisp beginner who asks for an IDE"
Is a good advice because emacs is awesome, multipurpose, and free.
But, you have choices. You could use also slimv, the "slime for vim" for example. And Vim is also awesome, multipurpose and free.
If you are a total beginner that do not want to learn neither vim nor emacs (something that you will regret when you finally learn one of them some years later) just forget all about superior modes, fire a clisp repl in bash and use your favourite text editor to write and copy-paste. If you want a simple plan to start, is pretty simple
If you want it more simple, just save some bucks and buy a commercial lisp, like allegro for example that comes with a nice IDE: allegro-composer. You obtain what you pay for.
Correct. It would be nice if they were appropriately presented to beginners.
like allegro for example that comes with a nice IDE: allegro-composer.
Do you... use Allegro? Do you find it good? Have you used LispWorks?
In the past couple/few years, Franz introduced a single-stepper.[1] They released a video alongside the new feature, demonstrating it. Literally, by 20 minutes into the video, the narrator was still mucking about with configuration and such and hadn't gotten to the point of being able to single-step through Lisp code.
(Also, Allegro's licensing terms require a runtime license fee for every unit of software developed with Allegro that you distribute. LispWorks' do not.)
[1] (It's unconscionable to me that that could be a new-ish feature. I don't even know that I had heard of the term "single-stepper" prior to that - I always just assumed it was a natural v0.1 part of a debugger that didn't bear even mentioning. But what can you do...)
Just to get started. Many people are intimidated by Emacs because there is so much to learn. If it scares you, start off simple then let your knowledge grow organically.
I've been coding in emacs for years and still have no idea what I'm doing. Lisp makes sense, but I'm aware that there are thousands of features in emacs that I'm unaware of.
It makes life MUCH worse switching from linux to osx emacs and back though.
Basic editing does take 15 minutes. In 20 minutes you realize that Emacs out-of-the-box is embarrassingly bad relative to modern editors, and to justify using it you'll have to go deeper. A year later, you start to feel like a somewhat proficient user.
I'm an Emacs fanboy, and I'm already using 25. The fact is, if someone is just looking for a text editor and not a new hobby, I would recommend Atom. The editor that you have after using Emacs for 15 minutes is not very good. The editor you have after a year of dedicated use is amazing.
And here I thought I was up to date on gamedev-related libs in CL... Thanks for the list!
At first look the list may look very opinionated ("use XYZ and just XYZ, forget about anything else"), but I understand the CL world has a bit of a discovery problem - it's often hard to tell e.g. which library is stable, and which is stabl-ish (e.g. made good enough for basic cases and then abandoned). Promoting top-of-the-line tools seems like something the community needs right now.
When writing things like this you have to tread a line between "I am somehow an expert on Everything, trust me" and "here's 200 different libraries, and sixty pages of reviews and benchmarks, it's your choice in the end".
The latter is basically in the situation when you go to a Cliki page[0], or when someone on freenode/#lisp asks what library they can use for X, and was what I mainly wanted to avoid.
I just started making a serious effort to learn CL (finally, after having it "on the list" for over a decade) a few nights ago. I'd already been an Emacs user, but not an Emacs "power user". Still, it took me 20 minutes or so to get Emacs, SBCL and Slime all setup. Once it was all working, I just had to spend a few minutes learning a few key combinations I'd not bothered much with before (like how to move between frames, and then the Slime specific ones for compiling and loading Lisp files), and I was off to the races.
Now granted, I already knew my way around Emacs a little (emphasis on little), but I was pleasantly surprised how easy it was to get up and running with that environment. And now I have even more motivation to truly master Emacs. Personally, I'm pretty happy with the state of the Common Lisp Ecosystem, approaching it as Lisp beginner (but not a programming beginner). shrug
Emacs feels like using a terminal connected to a minicomputer which is fine; and a good idea; if you are connecting to a Lisp app in the cloud.
Something a bit more unified and graphical would be nice when working on your own PC.
Out of curiosity, how are you approaching learning it? Practical Common Lisp seems to be the most popular entry point for non-beginner programmers learning lisp.
Yeah, I decided to work my way through Practical Common Lisp. I haven't gotten very far yet, but I'm dividing my attention between that and a number of other things that I've been putting off for way too long. Like, as I sit here in front of the computer tonight before going to bed, I'm working through some of Learning R.
I started with Practical Common Lisp, but found out Lisp-koans (https://github.com/google/lisp-koans) support my flow of learning CL better, as I do some koans while commuting in the train :)
That's interesting; probably a learning-style difference, but the one time I tried a -koans (ruby-koans in this case), I found it to be a very inefficient way to learn.
To me currently the biggest learning curve in CL is that "how to use CL" e.g. list/vectors etc. and not "how do I use CL to solve X". To the former, koans are good way to get familiar with the syntax and how to use the language.
"CLIM is interesting and was the last attempt to do any kind of research on how user interfaces should be built, but is not a viable option in 2015." -hmmm, what!?
Am I the only one left who thinks that gui widgets without a context (think qt, gtk) lead to inconsistent and inferior interfaces? If anything, since it is the _last_ attempt at GUI research, then we should continue from there. Or not, if we think that the Unity/Metro are THE interfaces...
That's a really great resource. With the usual CL directories, it's completely opaque which libraries are maintained and usable and which are out of data.
For the GUI toolkits, don't know why CAPI was not listed? Yes it is LW specific but it is a worthy choice. I prototyped an entire 3D game scene using CAPI using the OpenGL 1 FFI they provided and it was very productive.
Of course CEPL then would have made it more fun, though I don't know if CEPL works with LW CAPI.
Of the things discussed in this post, the main area where I would seriously suggest a commercial Common Lisp system even for a newcomer, is if they are interested in GUIs, either on the development or runtime side. I can recommend LispWorks for those: it has a graphical IDE with graphical debugger, and a very nice cross-platform GUI library with native look-and-feel (called CAPI). I think compared to the open-source options, both of those will result in a lot less pulling out of hair. CommonQt is passable, but CAPI is far less of a hassle, especially for cross-platform deployment. The obvious downside is that LispWorks costs money and is not open-source, so is probably most attractive to people developing a commercial product. Also, in the case of using CAPI, you commit to LispWorks as your implementation.
The biggest issue I find, although I lack the experience to really validate it, is that those environments still provide an overall developer tooling experience that is way better than the open source offerings.
An evolution of the Interlisp-D/Symbolics Genera systems.
Postmodern is very good, it just slipped my mind as I haven't used it except as a reference when implementing my own ORM.
But since Postmodern is Postgres-only, and is a very stable, maintained library (and I doubt the author has plans for the future, having mostly moved to JavaScript), it doesn't really fit into either 'future work' or 'consolidation'.
As for Elephant, IIRC it's no longer maintained, and I think the model it presents -- just serialize CLOS objects, with whatever backend -- is the wrong way to go about it. Most of the time, it's better to be aware that you're using SQL, or a JSON file, or whatever your storage is.
By popular demand, I've just updated it to regular unleaded scrolling. Might change back if I find some kind of jQuery library for portable parallax scrolling.
I don't mind the visual style, but the author seems to have forgotten that some people use actual mice instead of inertial-scrolling trackpads.... using a scroll wheel goes nowhere fast on this kind of page.
