←back to thread

Emacs Lisp Elements

(protesilaos.com)
339 points robenkleene | 4 comments | | HN request time: 0.818s | source
Show context
tikhonj ◴[] No.43667636[source]
I've had a great time using Emacs Lisp over the past 15 years: it's one of the easiest ways to quickly whip up personalized tools for my own use, and, at the same time, my code has been surprisingly resilient and stable over this time.

And this is despite the fact that Emacs Lisp routinely flouts every single software engineering "best practice". The language is dynamically scoped by default! It simply doesn't have namespaces! Static types? Hah! (And I, an inveterate Haskeller, don't even miss them.) You can—and people routinely do—hook directly into all sorts of implementation details from other parts of the codebase.

And yet it just works. And it works remarkably well.

My theory: what matters isn't "best practices", it's have a coherent conceptual design and code that reflects that design. Emacs is designed around a small but expressive set of core concepts that it uses in a consistent manner. Text with properties, buffers, modes, commands, customization variables... Almost everything more complex in Emacs is structured out of these (+ a handful more), and, once you've internalized them, it's surprisingly easy to both learn new higher-level tools and to write your own.

The design of both the user interface and the code directly reflect these concepts which gives us a naturally close connection between the UI and the code (it's almost trivial to jump from an interaction to the code that powers it), makes both UI and code units effortlessly composable and generally makes it easier to understand what's going on and how we can change it.

replies(4): >>43667712 #>>43668618 #>>43671691 #>>43673457 #
nothrabannosir ◴[] No.43667712[source]
> My theory: what matters isn't "best practices", it's have a coherent conceptual design and code that reflects that design.

Just because something has a >0 level of success doesn't mean there are no negatives. "Best practices don't matter because Emacs Lisp doesn't follow them and it just works" isn't a valid argument: it could very well be that Emacs (Lisp) would shine fifteen-fold brighter if it did also follow those practices. It just happens that having those elements you mentioned as positives are enough to keep the train going in spite of the shortcomings.

I use Emacs and program in Emacs Lisp to scratch my itches, and I agree that there are elements that make it work and hey, I'm still here, but I will bet good money that a parallel universe with Emacs Lisp', Now With Namespaces would work even better.

"Working" isn't binary.

replies(3): >>43667940 #>>43668109 #>>43673619 #
1. teddyh ◴[] No.43668109[source]
> Emacs Lisp', Now With Namespaces

Do you mean lexical binding, available as an option since 24.1?

replies(1): >>43670377 #
2. nothrabannosir ◴[] No.43670377[source]
I mean namespaces, like Common Lisp namespaces.
replies(1): >>43671096 #
3. tmtvl ◴[] No.43671096[source]
It does have those:

  *** Welcome to IELM ***  Type (describe-mode) or press C-h m for help.
  ELISP> +
  *** Eval error ***  Symbol’s value as variable is void: +
  ELISP> #'+
  +
But I get it, you mean namespaces like Common Lisp packages so people don't need to call stuff `org-babel-load-languages', but they can just call it `load-languages' and put it in the `org-babel' package.
replies(1): >>43675421 #
4. nothrabannosir ◴[] No.43675421{3}[source]
Yes I meant packages :)