State of the Common Lisp Ecosystem
eudoxia.me
eudoxia.me
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.
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.
Skip the complicated stuff and pretend you're using Notepad.
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.
And I doubt if you have to use Emacs to write in Lisp. Let me Google it for you:
http://stackoverflow.com/questions/94792/using-vim-for-lisp-...
You don't. Nobody stops you to use vim and fire a clisp repl instead if you want. Older but much friendly to start than sbcl.
Emacs as a barrier to lisp is an interesting concept. To me was exactly the opposite.
You don't. Nobody stops you to use vim and fire
a clisp repl instead if you want.
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.
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.
But, you have choices.
like allegro for example that comes with a nice IDE: allegro-composer.
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...)
Is this any different from other IDEs? As a vim user, Eclipse certainly feels more-or-less like notepad.
You don't have to use GNU Emacs to write Lisp code.
It just happens that a popular Editor written in Lisp and extensible in Lisp is somehow the natural choice for Lisp developers.
...
It makes life MUCH worse switching from linux to osx emacs and back though.
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.
Not only that, they're older (i.e., Emacs was there first).
Apple doesn't go out of their way to really point this out. Ordinary Mac users have no idea about this. None!
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.
C-a, C-e, C-b, C-f, C-p, C-n, C-v, M-v for line/screen maneuvering.
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.
Eventually I just caved and learned Emacs.
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
$ 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
$
!clisp -l myprogram.lisp -x '(main)' RET
Big point. The raw sbcl repl really hurts unless you use a superior mode or at least rlwrap.
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.
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.
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.
I'm trying to figure out if that was a real complaint or a sarcastic comment.
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.
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.
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.
And you're right, these releases don't change much. Programmer's tools tend to be chosen based on fashion and fads, not on their merit.
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?
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.
https://itunes.apple.com/us/app/clozure-cl/id489900618?mt=12
It's also available from Clozure:
http://ccl.clozure.com/download.html
A better environment and more expensive (though there is a limited personal edition) is LispWorks.
It uses a window for each buffer.
Still a bit of a shot from the "Haskell for Mac" type environment I'm interested in developing.
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.
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.
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.
[0] See http://www.cliki.net/xml for an illustration of choice paralysis
I started using Common Lisp in 1984 when Xerox rolled out CL as an update for my 1108 Lisp Machine. 31 years seems like a long time.
The Common Lisp community is great and with Zach's contribution of Quicklisp, most of the hassles of setting up a good CL dev environment are solved.
I especially liked seeing the two machine learning packages.
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
Can we have this in a nice, less ironic format, like, say:
((:domain "Web Development"
(:subdomain "Back End"
(:entry "Clack" ...)
...)
(:subdomain "Front End"
...)
...)
(:domain ...))EDIT: yes please for the easy format. Would gladly read it in Emacs, navigating it with Paredit :).
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...
Of course CEPL then would have made it more fun, though I don't know if CEPL works with LW CAPI.
An evolution of the Interlisp-D/Symbolics Genera systems.
Elephant has been unmaintained for many years. I wouldn't recommend it.
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.
cl-ply for example: draw and manage 3d polygon meshes.
CL-STMX is awesome!