5 ms·

I am always amazed at how many libraries and tools there are for programming in Elisp. One of the things that make it so fun.

m463 8y ago
I suspect because statistically programmers are in their editor, they're just a distraction away from playing with elisp.
- celeritascelery 8y ago
  I have shaved many elisp yaks in my day.
- outworlder 8y ago
  > I suspect because statistically programmers are in their editor, they're just a distraction away from playing with elisp. I think that's one reason, but not the only one. But they all fall in the 'barrier of entry' theme. You are literally two keystrokes away from being able to replace any running elisp code in your editor (C-x C-e). You have a default scratch buffer every time you start the editor. You don't have to create packages or do anything else to start coding. You can inspect everything, even ask which function is run when you type a character, which will take you right to the source code, which allows you to copy, modify, eval, and then paste it right into your .emacs when you are done. After that, you just uploaded the file somewhere for other people to use, if you are so inclined. Historically, they would just plop the file right on their .emacs.d. Now, you can go the extra mile and make a package. Which is comparatively easy as you already have the code written and it just needs a home. One time, I created a few commands to query Jira (grab issues assigned to me and stuff like that). It took me more time reading Atlassian's spec than it took to code the whole thing. I've also reproduced the entire ending of Portal (the game) in Emacs, complete with synchronized lyrics, the ascii art and the color scheme (before color-themes was a thing). That was pretty easy to do. Compare with other editors, even some of the 'cooler' ones (like VS Code). It is not obvious what to do if you want to change something, or where it even is. The config file is not programmable. You need to figure out how to create a package first, and only then start writing code. And that's VSCode. Some don't even allow you that much flexibility, other than maybe invoking shell commands. And don't get me started on "IDEs" like Eclipse. Last time I extended it, I required two running copies of the environment and a full blown 'project' in order to add a lowly menu entry.
  - rgoulter 8y ago
    Historically, they would just plop the file right on their .emacs.d With Emacs I'm more likely to try and extend some part of the editor than I am with Vim. A significant percentage of Vim users make heavy use of plugins; and I feel that "don't do it myself" lends to fewer plugins of higher quality.
  - m463 8y ago
    > You are literally two keystrokes away from being able to replace any running elisp code in your editor (C-x C-e). lol, I am actually one keystroke away: F2 pulls up ~/.emacs.d/init.el (it's actually it's worse than that because F2 actually cycles through my most-used emacs startup files)
nextos 8y ago
It's always been a really rich environment, but it's amazing how much dynamism the whole ecosystem gained by introducing package.el and ELPA, plus to a lesser extent use-package. Without package management, keeping even relatively simple Emacs setups working was not that easy. Now, it's trivial. And thanks to that lots of parts have been modernized and the whole community is really vibrant. Emacs has now a really nice completion framework (avy) and auto-complete (company). Plus, IMHO the best git porcelain of any platform (magit), outliner (org) and mail user agent (notmuch, plus some bits of gnus).
- gyrgtyn 8y ago
  Yeah sometimes I feel like I don't want to use emacs anymore, but then I think about magit and org. After using spacemacs for a couple years, I've started rebuilding my own. There was too much stuff going on I didn't understand and when something breaks I have no idea what to do. Now that I know about general, ivy/swiper/counsel, use-package, and some of the other building blocks... It's pretty cool. You know what it reminds me of? npm ~ducks~
  - nextos 8y ago
    I do agree that building your own is the only way to progress learning Emacs and most complex pieces of software. I would also add that relying on as few packages as possible, and some that are well-known and maintained is important. My .emacs is very short, and I strive to simplify it as much as I can so that it doesn't become fragile or a liability to maintain. It's just a bit of setqs, use-package boilerplate, and 2-liner configurations for ido, company, org, magit, notmuch, pdf-tools, auctex, ess, anaconda and a few others. That way I avoid npm-like insanities.
    - WalterGR 8y ago
      Do you live as much as possible in Emacs? How do you deal psychologically with all the niceties that you give up with so little configuration? The first innovation outside of Emacs that springs to mind is find-and-replace that lets you easily switch between literal, case-insensitive, regex, current line/selection/whole file, and current file/across multiple files. Do you just have to tell yourself, “Well, other environments have such niceties, but I’m giving them up in exchange for other niceties that Emacs offers?”
dan-robertson 8y ago
I think there’s lots of things about elisp the language which make it easy to hack on too. In no particular order: 1. Dynamism+late binding+late failure means that, although it is hard to write fully “correct” code (and correct is ill-defined/impossible), it is very easy to write code that does work in the common cases without having to care about the uncommon cases. 2. Dynamism makes it possible to extend existing code with more functionality. You can get at any function and easily add your own code to run before/after/around it, or just redefine it to do what you want. 3. Macros make it much easier to do a lot with a little and mean there are far fewer language limitations than in other PLs because one can usually macro around them. E.g. emacs didn’t support lexical scope natively until recently but for a long time supported it with cl macros. 4. Dynamic scope makes global scope local, which means that having lots of globally scoped variables (for various eg options) isn’t so bad so there are lots of these and these then allow one to tweak the behaviour of functions by letting these variables. (e.g. if you have a function that determines some arguments for a program foo and then runs it, you can run that program remotely by doing (let ((foo-executable "ssh") (foo-other-args (append (list "some-host" foo-executable) foo-other-args))) ...) 5. Many internal data structures are simple arrangements of lists, symbols, and strings that are easy to inspect and easy to modify. They are so easy to modify that many come with a spec of their structure that is automatically turned into a gui to modify it. 6. Buffer-local variables are a super convenient way of attaching state to a buffer and a buffer is a super logical place to attach a lot of state to. There are some caveats, e.g. often one wants buffer groups of some kind but these are much less common in the simple case. 7. Symbols are much better than strings. They are faster, feel more natural, and are much easier to attach things to. It seems weird to imagine JavaScript having some global object mapping nearly every string to an object listing various different properties of that string but symbol plists tend to feel pretty natural and are a handy way to extend things. 8. It’s reasonably easy to not have independent things stepping on each other’s toes. Typically if you can write down a unique symbol for your thing then it won’t really conflict with other things. You can use it for global/buffer-local scope. You can use it for a property in symbol plists without stepping on other properties. 9. There are hooks for extension built in all over the place. 10. Your code gets to do things instantly. With many languages you can’t do the useful thing you wanted to do until you can get the data in/out of it which is often a lot of work. It’s even more work if you want something interactive, and even more work if you want something better than curses. Even for an “easy to get going” language like JavaScript you can’t really build on what’s come before. You typically have to start by building up most of the environment you want to work in by yourself first. In emacs it’s already there and you can use everything that’s there for free. There is no building up your environment because your environment is the one and only environment. 11. Essentially anything you can do with keys is just a regular elisp function called interactively. It is easy to make a function a command by telling it what things you care about which means that most commands correspond to functions that take extra arguments which are useful when calling non-interactively. 12. Nearly everything is native. The things that aren’t in elisp are typically only very fundamental or boring things. And all this code is on your machine, emacs knows where it is and you can read it. If you want to understand something you can jump to definition and have a look. You don’t need to wait for the package maintainer to fix things, just write the fix yourself and stick it in your .emacs. In other editors/systems the bug might be much deeper. You don’t want to have to build everything from source to be able to fix bugs yourself. In emacs you are effectively building everything interesting from source (except without really doing any work most of the time thanks to the abomination of unexec) so it easy to hack on. 13. Emacs has lots more experimental things than other editors/languages because the users write them (to scratch itches) and accept them. One can wonder why an emacs user might be more likely to accept rough edges than a user of (say) vscode. One could stereotype that the typical emacs user is more used to code that is rough or buggy, or that the typical vs code user is more used to code that doesn’t do anything useful. Or maybe it is just that emacs being rough around the edges is the price one must pay for the smug superiority of using what is (objectively) the best system for hacking for hackers by hackers. One could suggest that some of these arguments also apply to vim users accepting an editor rough around the edges and this is partly true but despite the larger number of people who use vim, there seems to be quite different work done there (typically it’s focused only on editing and much less on big complicated useful things like magit/org/calc). Then again I’m pretty sure writing vimscript is a fate worse than death so that is probably why.

m463 8y ago

I suspect because statistically programmers are in their editor, they're just a distraction away from playing with elisp.

celeritascelery 8y ago
I have shaved many elisp yaks in my day.
outworlder 8y ago
> I suspect because statistically programmers are in their editor, they're just a distraction away from playing with elisp. I think that's one reason, but not the only one. But they all fall in the 'barrier of entry' theme. You are literally two keystrokes away from being able to replace any running elisp code in your editor (C-x C-e). You have a default scratch buffer every time you start the editor. You don't have to create packages or do anything else to start coding. You can inspect everything, even ask which function is run when you type a character, which will take you right to the source code, which allows you to copy, modify, eval, and then paste it right into your .emacs when you are done. After that, you just uploaded the file somewhere for other people to use, if you are so inclined. Historically, they would just plop the file right on their .emacs.d. Now, you can go the extra mile and make a package. Which is comparatively easy as you already have the code written and it just needs a home. One time, I created a few commands to query Jira (grab issues assigned to me and stuff like that). It took me more time reading Atlassian's spec than it took to code the whole thing. I've also reproduced the entire ending of Portal (the game) in Emacs, complete with synchronized lyrics, the ascii art and the color scheme (before color-themes was a thing). That was pretty easy to do. Compare with other editors, even some of the 'cooler' ones (like VS Code). It is not obvious what to do if you want to change something, or where it even is. The config file is not programmable. You need to figure out how to create a package first, and only then start writing code. And that's VSCode. Some don't even allow you that much flexibility, other than maybe invoking shell commands. And don't get me started on "IDEs" like Eclipse. Last time I extended it, I required two running copies of the environment and a full blown 'project' in order to add a lowly menu entry.
- rgoulter 8y ago
  Historically, they would just plop the file right on their .emacs.d With Emacs I'm more likely to try and extend some part of the editor than I am with Vim. A significant percentage of Vim users make heavy use of plugins; and I feel that "don't do it myself" lends to fewer plugins of higher quality.
- m463 8y ago
  > You are literally two keystrokes away from being able to replace any running elisp code in your editor (C-x C-e). lol, I am actually one keystroke away: F2 pulls up ~/.emacs.d/init.el (it's actually it's worse than that because F2 actually cycles through my most-used emacs startup files)

nextos 8y ago

It's always been a really rich environment, but it's amazing how much dynamism the whole ecosystem gained by introducing package.el and ELPA, plus to a lesser extent use-package. Without package management, keeping even relatively simple Emacs setups working was not that easy. Now, it's trivial. And thanks to that lots of parts have been modernized and the whole community is really vibrant. Emacs has now a really nice completion framework (avy) and auto-complete (company). Plus, IMHO the best git porcelain of any platform (magit), outliner (org) and mail user agent (notmuch, plus some bits of gnus).

gyrgtyn 8y ago
Yeah sometimes I feel like I don't want to use emacs anymore, but then I think about magit and org. After using spacemacs for a couple years, I've started rebuilding my own. There was too much stuff going on I didn't understand and when something breaks I have no idea what to do. Now that I know about general, ivy/swiper/counsel, use-package, and some of the other building blocks... It's pretty cool. You know what it reminds me of? npm ~ducks~
- nextos 8y ago
  I do agree that building your own is the only way to progress learning Emacs and most complex pieces of software. I would also add that relying on as few packages as possible, and some that are well-known and maintained is important. My .emacs is very short, and I strive to simplify it as much as I can so that it doesn't become fragile or a liability to maintain. It's just a bit of setqs, use-package boilerplate, and 2-liner configurations for ido, company, org, magit, notmuch, pdf-tools, auctex, ess, anaconda and a few others. That way I avoid npm-like insanities.
  - WalterGR 8y ago
    Do you live as much as possible in Emacs? How do you deal psychologically with all the niceties that you give up with so little configuration? The first innovation outside of Emacs that springs to mind is find-and-replace that lets you easily switch between literal, case-insensitive, regex, current line/selection/whole file, and current file/across multiple files. Do you just have to tell yourself, “Well, other environments have such niceties, but I’m giving them up in exchange for other niceties that Emacs offers?”

dan-robertson 8y ago

I think there’s lots of things about elisp the language which make it easy to hack on too. In no particular order: 1. Dynamism+late binding+late failure means that, although it is hard to write fully “correct” code (and correct is ill-defined/impossible), it is very easy to write code that does work in the common cases without having to care about the uncommon cases. 2. Dynamism makes it possible to extend existing code with more functionality. You can get at any function and easily add your own code to run before/after/around it, or just redefine it to do what you want. 3. Macros make it much easier to do a lot with a little and mean there are far fewer language limitations than in other PLs because one can usually macro around them. E.g. emacs didn’t support lexical scope natively until recently but for a long time supported it with cl macros. 4. Dynamic scope makes global scope local, which means that having lots of globally scoped variables (for various eg options) isn’t so bad so there are lots of these and these then allow one to tweak the behaviour of functions by letting these variables. (e.g. if you have a function that determines some arguments for a program foo and then runs it, you can run that program remotely by doing (let ((foo-executable "ssh") (foo-other-args (append (list "some-host" foo-executable) foo-other-args))) ...) 5. Many internal data structures are simple arrangements of lists, symbols, and strings that are easy to inspect and easy to modify. They are so easy to modify that many come with a spec of their structure that is automatically turned into a gui to modify it. 6. Buffer-local variables are a super convenient way of attaching state to a buffer and a buffer is a super logical place to attach a lot of state to. There are some caveats, e.g. often one wants buffer groups of some kind but these are much less common in the simple case. 7. Symbols are much better than strings. They are faster, feel more natural, and are much easier to attach things to. It seems weird to imagine JavaScript having some global object mapping nearly every string to an object listing various different properties of that string but symbol plists tend to feel pretty natural and are a handy way to extend things. 8. It’s reasonably easy to not have independent things stepping on each other’s toes. Typically if you can write down a unique symbol for your thing then it won’t really conflict with other things. You can use it for global/buffer-local scope. You can use it for a property in symbol plists without stepping on other properties. 9. There are hooks for extension built in all over the place. 10. Your code gets to do things instantly. With many languages you can’t do the useful thing you wanted to do until you can get the data in/out of it which is often a lot of work. It’s even more work if you want something interactive, and even more work if you want something better than curses. Even for an “easy to get going” language like JavaScript you can’t really build on what’s come before. You typically have to start by building up most of the environment you want to work in by yourself first. In emacs it’s already there and you can use everything that’s there for free. There is no building up your environment because your environment is the one and only environment. 11. Essentially anything you can do with keys is just a regular elisp function called interactively. It is easy to make a function a command by telling it what things you care about which means that most commands correspond to functions that take extra arguments which are useful when calling non-interactively. 12. Nearly everything is native. The things that aren’t in elisp are typically only very fundamental or boring things. And all this code is on your machine, emacs knows where it is and you can read it. If you want to understand something you can jump to definition and have a look. You don’t need to wait for the package maintainer to fix things, just write the fix yourself and stick it in your .emacs. In other editors/systems the bug might be much deeper. You don’t want to have to build everything from source to be able to fix bugs yourself. In emacs you are effectively building everything interesting from source (except without really doing any work most of the time thanks to the abomination of unexec) so it easy to hack on. 13. Emacs has lots more experimental things than other editors/languages because the users write them (to scratch itches) and accept them. One can wonder why an emacs user might be more likely to accept rough edges than a user of (say) vscode. One could stereotype that the typical emacs user is more used to code that is rough or buggy, or that the typical vs code user is more used to code that doesn’t do anything useful. Or maybe it is just that emacs being rough around the edges is the price one must pay for the smug superiority of using what is (objectively) the best system for hacking for hackers by hackers. One could suggest that some of these arguments also apply to vim users accepting an editor rough around the edges and this is partly true but despite the larger number of people who use vim, there seems to be quite different work done there (typically it’s focused only on editing and much less on big complicated useful things like magit/org/calc). Then again I’m pretty sure writing vimscript is a fate worse than death so that is probably why.