Emacs Lisp has many features of Common Lisp, although it is considerably smaller (and thus easier to master).
Ehn, sorta. Elisp is smaller, but as far as I can tell, the cl library is used an awful lot, mostly because writing Elisp can be such a slog. I love Common Lisp (CL) and have used Emacs for 20 years now, and I’ve never been able to get into writing Elisp, although I’ve been trying more lately.
It’s not because it’s terrible but because the APIs are so vast. Have you ever tried to read through the Elisp manual? You’ll be there for a long time (hint: understanding buffers is the Zen of Elisp, so jump ahead).
Also, Elisp doesn’t seem to encourage breaking things down into functions as much as CL. A lot of existing code that I’ve looked at has many little expressions that would be nicely served as predicates or one-off functions, but since Elisp doesn’t have something like flet, the language doesn’t encourage such things. As a result, some functions are huge and really hard to follow. One great thing about Emacs is how easy it is to examine the code for things; it’s too bad that code is so obtuse a lot of the time.
Yup, rms famously doesn’t like Common Lisp’s complexity, but I think that the histories of both elisp & Scheme are used in practice demonstrate the wisdom of Common Lisp’s approach. As an example, elisp has no namespacing mechanism, so folks commonly prepend the package name to variables & functions, leading to variables named e.g. my-package-variable & internal variables named e.g. my-package--private-variable; one has to type those long names everywhere, even in the package defining them, or a package which heavily uses them; in Common Lisp one would have a package my-package & the variables could be referred to as variable & private-variable within the package, and as my-package:variable & my-package::private-variable externally, or as variable inside a package using my-package. Complex? Certainly: I had to write a lot of words there, and maybe the reader doesn’t quite follow. A good thing? Yes, it’s easily learnt and it pays for itself every single time one writes or uses a package.
I can only imagine how awesome emacs would be today had it switched to Common Lisp back in the early 90s.
You are correct, it does not have a language-defined namespace mechanism. That’s done with function naming conventions. It does have a package system, but that’s for feature distribution.
Ehn, sorta. Elisp is smaller, but as far as I can tell, the
cllibrary is used an awful lot, mostly because writing Elisp can be such a slog. I love Common Lisp (CL) and have used Emacs for 20 years now, and I’ve never been able to get into writing Elisp, although I’ve been trying more lately.It’s not because it’s terrible but because the APIs are so vast. Have you ever tried to read through the Elisp manual? You’ll be there for a long time (hint: understanding buffers is the Zen of Elisp, so jump ahead).
Also, Elisp doesn’t seem to encourage breaking things down into functions as much as CL. A lot of existing code that I’ve looked at has many little expressions that would be nicely served as predicates or one-off functions, but since Elisp doesn’t have something like
flet, the language doesn’t encourage such things. As a result, some functions are huge and really hard to follow. One great thing about Emacs is how easy it is to examine the code for things; it’s too bad that code is so obtuse a lot of the time.Yup, rms famously doesn’t like Common Lisp’s complexity, but I think that the histories of both elisp & Scheme are used in practice demonstrate the wisdom of Common Lisp’s approach. As an example, elisp has no namespacing mechanism, so folks commonly prepend the package name to variables & functions, leading to variables named e.g.
my-package-variable& internal variables named e.g.my-package--private-variable; one has to type those long names everywhere, even in the package defining them, or a package which heavily uses them; in Common Lisp one would have a packagemy-package& the variables could be referred to asvariable&private-variablewithin the package, and asmy-package:variable&my-package::private-variableexternally, or asvariableinside a package usingmy-package. Complex? Certainly: I had to write a lot of words there, and maybe the reader doesn’t quite follow. A good thing? Yes, it’s easily learnt and it pays for itself every single time one writes or uses a package.I can only imagine how awesome emacs would be today had it switched to Common Lisp back in the early 90s.
AFAIK[1], Emacs doesn’t have a module or packages system which also doesn’t help breaking things down into smaller pieces.
[1] I could look this up but instead I choose to comment.
You are correct, it does not have a language-defined namespace mechanism. That’s done with function naming conventions. It does have a package system, but that’s for feature distribution.
Yes, sorry about my terminology: I meant Common Lisp “packages” (i.e. modules, namespaces).
(Common Lisp junky here as well.)
There is ELPA and MELPA,
M-x package-list-packages