2

I've been in this catch-22 for a while now: I don't have time to learn Common Lisp first, then elisp, but I don't want to learn elisp without understanding the basic capabilities of Lisp. People have said Paul Graham's ANSI Lisp is a thorough CL tutorial. Is there a way (tutorial(s)) to learn elisp and have a good grounding in the capabilities of Lisp in general? From just nosing around on the Internet, it seems elisp can cover nearly everything (at least from my novice buzzword understanding) that CL has to offer. Conversely, what I'm deathly afraid of is diving into elisp, getting reasonably good at it, but being totally blind to some of the really slick things CL can do.

  • It's a little unclear what you want: you are afraid of getting good at elisp without understanding what other lisps can do, but you don't want to learn other lisps? If you don't want to learn Common Lisp, why does it matter that it might have features you don't know about? – Tyler Sep 21 '15 at 18:38
  • 1
    What do you want to do? If you want to be able to customise Emacs, you need to learn elisp. If you want to write stand-alone lisp programs, elisp isn't a great choice, so I would strongly recommend another dialect. If you want to do both, then you need to learn both, and you can pick the order based on what you want to do first. – phils Sep 21 '15 at 23:54
4

TL;DR

Learn Scheme.

Long Version

I remember myself being in a similar situation some years ago. First of all, I didn't understand the relation between Emacs Lisp and ANSI Common Lisp (sometimes also referred to as simply Common Lisp, or even more ambiguously, just Lisp). I ended up learning Common Lisp and eventually writing something to help myself with Emacs. This isn't ideal. I'll try to put things in perspective.

At first there was just Lisp, the general idea of what the language can do. There used to be numerous slightly different dialects, but the one which later become the basis for the ANSI standard for Common Lisp was Mac Lisp. This language had various problems and some bad solutions for these problems. In particular, because many of its features were developed ad hoc, but also conceptually, macros were perceived evil, and especially so syntax macros. There wasn't enough uniformity in the design of most commonly used functions (which later made it into the standard), for some there were two versions, like nconc and concat, but for others there were either only destructive versions or only non-destructive ones. The concept of having two namespaces seemed superfluous. Object system, which was starting to get momentum, wasn't built into the language. Perhaps there was more: I wasn't yet around to know that.

Scheme was meant to be a refinement and improvement on top of the good parts of what came to be associated with Lisp. It didn't solve all problems, but it tidied up the language, removed some inconsistencies, offered a nice solution for syntax macros, it also introduced a concept of call-with-current-continuation (which is somewhat similar to Python's yield).

Then, ANSI standardized the remains of Mac Lisp as Common Lisp. The problem with this Lisp dialect today is that it's unlikely that it will see any major language overhaul. If one was to spend effort to make it better, one would end up with some variant of Scheme. And this is what generally happens. New dialects of Lisp, and the only one that is used for serious and somewhat popular programming today--Clojure is a descendent from Scheme.

Now, where does Emacs Lisp fit into the picture? Whatever my or your opinion on Common Lisp is, it is still a proper multi-purpose programming language, suitable for writing any program you can think of. The same is true of Scheme and its family. Emacs Lisp is a remarkably good language for something that was developed to serve one particular program. It well may be the most elaborate and advanced embedded language there is, with huge ecosystem and being actively developed and improved. It isn't however suitable for lots of programming needs. Interfacing with programs outside Emacs, performance-critical code, graphical user interface to name a few.


Scheme may not have improved on every feature of "ancient" Lisps, but it is where the future of Lisps will eventually go. If you are at a choice point, and you need to pick a language which will stay with you for many years, choose Scheme. It is reasonably similar to Emacs Lisp so that you will be able to understand Emacs Lisp code and eventually to write your own, but it will also serve you in situations when Emacs Lisp is just not enough. Also, once every year or so, there are talks about Guile Emacs (an Emacs version which replaces Emacs Lisp interpreter with Guile Scheme). Who knows, maybe someday...

| improve this answer | |
5

Learn Emacs Lisp through the official tutorial and by customizing your Emacs environment. Being hands-on is a huge advantage when learning, and learning Emacs Lisp gives you the opportunity to apply your knowledge immediately to do useful things.

The main language difference is that Common Lisp has lexical scope by default, whereas Emacs only supports lexical scope (but only uses in libraries that explicitly request it) since version 24.

To get an idea of what Emacs Lisp is missing, look at Emacs's cl library (which is an official part of Emacs, but not loaded by default unless some package that you used requires it). The cl library offers some extra library features from Common Lisp, in particular a richer set of list processing functions and setf/letf.

| improve this answer | |
  • Would it be at all possible to do ANSI Lisp in elisp? – 147pm Sep 21 '15 at 18:44
  • @147pm Not all of it, but enough of it to get a good feel for the language. – Gilles 'SO- stop being evil' Sep 21 '15 at 19:55
0

... what I'm deathly afraid of is diving into elisp, getting reasonably good at it, but being totally blind to some of the really slick things CL can do.

There is no danger of that at all if one gets "reasonably good" at any dialect of lisp. Unlike other languages that may have caused blindness, lisp has always been known for opening minds.

| improve this answer | |

Not the answer you're looking for? Browse other questions tagged or ask your own question.