5 ms·

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 sa

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.

nothrabannosir 2y ago
> 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.
- tikhonj 2y ago
  That's certainly true! But based on my holistic experience using Emacs—more than a binary "it works"—I'm convinced that the conceptual design carries most of the weight. Would namespaces, lexical scoping, etc be better? Almost definitely. But it would be a marginal improvement, a difference in degree not kind. Other "best practices" like more aggressive information hiding would go against Emacs's design and make it worse as a whole. Most "best practices" are neither necessary nor sufficient and, in most cases, not even particularly effective, even when they offer strict improvements over the status quo.
  - TeMPOraL 2y ago
    > Would namespaces, lexical scoping, etc be better? Almost definitely. But it would be a marginal improvement, a difference in degree not kind. That's the thing - it probably would not be. IMO, the key things that allow Emacs to succeed and last, while being somewhat unique in how it "routinely flouts every single software engineering "best practice"", are not merely conceptual, but cultural or even philosophical. The most fundamental of those, IMO, is that Emacs is ultimately owned by users, who are treated as intelligent partners in the relationship. Everything is designed with extensibility in mind. There's no hard boundary between "core developers", "third-party extension developers" and "end-users" - everyone can be any of them, including all three, at any time. Maximizing extensibility and interoperability, not demanding "users" to coordinate with "developers" and ask for permission, not chasing user growth (it's all Free Software), expecting that everyone is a responsible adult, encouraging users to make Emacs "their own" - all that leads to an approach that goes the opposite to standard software development practice, because the standard practice is built around entirely opposite assumptions.
    - Capricorn2481 2y ago
      I don't see what any of that has to do with namespaces. You can have all of that and not clobber your functions together. It's just a way to delineate groups of functions, not a organizational mandate. Same with lexical scoping? Not really following you.
golly_ned 2y ago
I’ve consistently failed to make writing elisp net positive for me for basically anything. I use it as a configuration language, and even then, for functions longer than a few lines, it’s still a lot of coding for very little benefit. I just can’t find things to improve in such a way that it’ll actually be worth writing elisp code for, especially compared to other tools (like a quick Python script or even a bash one-liner), or things within Emacs. What are the things you’ve written in elisp that have helped you?
- Rediscover 2y ago
  > What are the things you’ve written in elisp that have helped you? Usually tools to alleviate working with dumbass web-based (supposedly needing the corporate-approved browser) stuff for $DAY-JOB. Oh, and an extension to allow emacs-w3m to handle lynx-style multibookmarks.
  - prestonlibby 2y ago
    > > What are the things you’ve written in elisp that have helped you? > > Usually tools to alleviate working with dumbass web-based (supposedly needing the corporate-approved browser) stuff for $DAY-JOB. > > Oh, and an extension to allow emacs-w3m to handle lynx-style multibookmarks. This sparks my interest as I am in the early days of both customizing Emacs and attempting to displace some of my browsing with it as well. Could you elaborate further on this multibookmarks concept and perhaps an example of one of those alleviations for working with web-based workflows?
    - Rediscover 2y ago
      Lynx is a web browser, bookmarking a page is done by hitting "adX" as in (a)dd (d)ocument to file (X). Or (a)dd (l)ink to (X). Nice and quick. The X is usually a lower case ASCII letter corresponding to a file. You can enable this mode (and the specific bookmark files) in lynx's config file. The Emacs extension uses the same keystrokes and, optionally, the same files. Alleviations are (I'm intentionally vague here) for getting rid of finding a link, clicking through, repeat, repeat, repeat, repeat, just to get to where I need to be (like adding an update to a ticket). I usually only automate processes that are intended for use by mouse/pointer-driving users with an ability to comprehend what (and where) icons are - I have a self-imposed problem withe former and a physically/mentally imposed hard time with the latter.
pkkm 2y ago
> My theory: what matters isn't "best practices", it's have a coherent conceptual design and code that reflects that design. I think so too; that said, the language could definitely be better. It suffers from a lot of primitive obsession. Instead of structs, you often find either vectors or lists with predefined element positions; instead of map, ordered map, and multimap types, it's just various kinds of lists everywhere. They're not even used consistently: for the same thing, one package may use an alist and another a plist.
- tikhonj 2y ago
  Yeah, I could also see some improvements like that. But, compared to other codebases I've worked with that had the same problem (cough nixpkgs cough), it's amazing how much better the Emacs programming experience has been.
  - funcDropShadow 2y ago
    Yes, nixpkgs is definitely missing the self-documenting part, or even the documenting part for most of it.
funcDropShadow 2y ago
Don't forget the self-documenting aspect. The manual is included, the api documentation is included, you can ask emacs which command is executed when you click somewhere or when you press a button. I recently tried to do the same thing in Intellij, pita. Not only, can you find documentation, you can jump to the source code, inspect variable values at runtime, and debug or profile everything. All of that from inside the environment.
- tikhonj 2y ago
  Absolutely! Seems like the conceptual design helped with that too, reducing the activation energy needed for clear, interactive documentation. The code and the UI are both designed against the same set of consistent concepts, which naturally brings them together and, in turn, makes it so much easier to tie them from one to another. Simplest example: every interaction in the UI is a "command" and commands are reflected in elisp, so having a way to jump from an interaction to the corresponding code and documentation just makes sense. The documentation can be organized along the same conceptual lines as the code and the UI. Emacs really is an amazing design study.

nothrabannosir 2y ago

> 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.

tikhonj 2y ago
That's certainly true! But based on my holistic experience using Emacs—more than a binary "it works"—I'm convinced that the conceptual design carries most of the weight. Would namespaces, lexical scoping, etc be better? Almost definitely. But it would be a marginal improvement, a difference in degree not kind. Other "best practices" like more aggressive information hiding would go against Emacs's design and make it worse as a whole. Most "best practices" are neither necessary nor sufficient and, in most cases, not even particularly effective, even when they offer strict improvements over the status quo.
- TeMPOraL 2y ago
  > Would namespaces, lexical scoping, etc be better? Almost definitely. But it would be a marginal improvement, a difference in degree not kind. That's the thing - it probably would not be. IMO, the key things that allow Emacs to succeed and last, while being somewhat unique in how it "routinely flouts every single software engineering "best practice"", are not merely conceptual, but cultural or even philosophical. The most fundamental of those, IMO, is that Emacs is ultimately owned by users, who are treated as intelligent partners in the relationship. Everything is designed with extensibility in mind. There's no hard boundary between "core developers", "third-party extension developers" and "end-users" - everyone can be any of them, including all three, at any time. Maximizing extensibility and interoperability, not demanding "users" to coordinate with "developers" and ask for permission, not chasing user growth (it's all Free Software), expecting that everyone is a responsible adult, encouraging users to make Emacs "their own" - all that leads to an approach that goes the opposite to standard software development practice, because the standard practice is built around entirely opposite assumptions.
  - Capricorn2481 2y ago
    I don't see what any of that has to do with namespaces. You can have all of that and not clobber your functions together. It's just a way to delineate groups of functions, not a organizational mandate. Same with lexical scoping? Not really following you.

golly_ned 2y ago

I’ve consistently failed to make writing elisp net positive for me for basically anything. I use it as a configuration language, and even then, for functions longer than a few lines, it’s still a lot of coding for very little benefit. I just can’t find things to improve in such a way that it’ll actually be worth writing elisp code for, especially compared to other tools (like a quick Python script or even a bash one-liner), or things within Emacs. What are the things you’ve written in elisp that have helped you?

Rediscover 2y ago
> What are the things you’ve written in elisp that have helped you? Usually tools to alleviate working with dumbass web-based (supposedly needing the corporate-approved browser) stuff for $DAY-JOB. Oh, and an extension to allow emacs-w3m to handle lynx-style multibookmarks.
- prestonlibby 2y ago
  > > What are the things you’ve written in elisp that have helped you? > > Usually tools to alleviate working with dumbass web-based (supposedly needing the corporate-approved browser) stuff for $DAY-JOB. > > Oh, and an extension to allow emacs-w3m to handle lynx-style multibookmarks. This sparks my interest as I am in the early days of both customizing Emacs and attempting to displace some of my browsing with it as well. Could you elaborate further on this multibookmarks concept and perhaps an example of one of those alleviations for working with web-based workflows?
  - Rediscover 2y ago
    Lynx is a web browser, bookmarking a page is done by hitting "adX" as in (a)dd (d)ocument to file (X). Or (a)dd (l)ink to (X). Nice and quick. The X is usually a lower case ASCII letter corresponding to a file. You can enable this mode (and the specific bookmark files) in lynx's config file. The Emacs extension uses the same keystrokes and, optionally, the same files. Alleviations are (I'm intentionally vague here) for getting rid of finding a link, clicking through, repeat, repeat, repeat, repeat, just to get to where I need to be (like adding an update to a ticket). I usually only automate processes that are intended for use by mouse/pointer-driving users with an ability to comprehend what (and where) icons are - I have a self-imposed problem withe former and a physically/mentally imposed hard time with the latter.

pkkm 2y ago

> My theory: what matters isn't "best practices", it's have a coherent conceptual design and code that reflects that design. I think so too; that said, the language could definitely be better. It suffers from a lot of primitive obsession. Instead of structs, you often find either vectors or lists with predefined element positions; instead of map, ordered map, and multimap types, it's just various kinds of lists everywhere. They're not even used consistently: for the same thing, one package may use an alist and another a plist.

tikhonj 2y ago
Yeah, I could also see some improvements like that. But, compared to other codebases I've worked with that had the same problem (cough nixpkgs cough), it's amazing how much better the Emacs programming experience has been.
- funcDropShadow 2y ago
  Yes, nixpkgs is definitely missing the self-documenting part, or even the documenting part for most of it.

funcDropShadow 2y ago

Don't forget the self-documenting aspect. The manual is included, the api documentation is included, you can ask emacs which command is executed when you click somewhere or when you press a button. I recently tried to do the same thing in Intellij, pita. Not only, can you find documentation, you can jump to the source code, inspect variable values at runtime, and debug or profile everything. All of that from inside the environment.

tikhonj 2y ago
Absolutely! Seems like the conceptual design helped with that too, reducing the activation energy needed for clear, interactive documentation. The code and the UI are both designed against the same set of consistent concepts, which naturally brings them together and, in turn, makes it so much easier to tie them from one to another. Simplest example: every interaction in the UI is a "command" and commands are reflected in elisp, so having a way to jump from an interaction to the corresponding code and documentation just makes sense. The documentation can be organized along the same conceptual lines as the code and the UI. Emacs really is an amazing design study.