3 ms·

I use Common Lisp professionally for work, and I love using Emacs and SLIME for editing Lisp. But over the past decade or so, I’ve also learned to maneuver arou

I use Common Lisp professionally for work, and I love using Emacs and SLIME for editing Lisp. But over the past decade or so, I’ve also learned to maneuver around Emacs, and give it the attention it needs to become somewhat proficient at it. In the case of others, I’ve observed much less patience. Patience maybe isn’t even the right word; perhaps it’s just an unwillingness to invest in something that doesn’t really communicate an obvious return. Many of my coworkers, especially those who want to edit a little bit of Lisp but don’t want to make it their life story, really wish there was a better editor. Many of them Python programmers, or even technical folks with a non-programming background, really aren’t sold on this whole Emacs thing to edit a weird language. Out of the box, you have to look up the plethora of cheat sheets and commands and figure out why GUI Emacs doesn’t see your PATH and why changing the font doesn’t stick and .... They do appreciate the likes of Atom, PyCharm, Jupyter notebooks, etc. with big beautiful GUIs with big beautiful menus and slick websites and “out of the box” support for what they need to do. Pop-up suggestions, dedicated terminal windows, etc. “Obviously” Emacs can do these things, if not better and with more breadth, but it’s all hidden behind The Model of Emacs Thinking (TM). I really look forward to efforts like Lem improving. I hope they try to do at least one thing really well—editing and interacting with Lisp—and not 100 things poorly (e.g., trying to replace Python editors out of the gate). A great Lisp editor will be such a boon for the language, maybe as important to its rebirth a decade ago as Quicklisp was to it. Lisp is such a wonderful tool, and I want folks to see the great industrial uses it has. Selfishly, I also want to see more contributions to my own Lisp projects on GitHub. To the extent Lem can facilitate that, I’m entirely on board. (If you’re looking for some cool things to hack on in Lisp, try quilc [0], qvm [1], or maybe even Lem itself!) [0] https://github.com/rigetti/quilc https://github.com/rigetti/quilc [1] https://github.com/rigetti/qvm https://github.com/rigetti/qvm

robertcarter 8y ago
care to share your emacs config/setup ?
zimablue 8y ago
I definitely fit into that second paragraph, and I appreciate you being careful to distinguish patience from being convinced of cost-benefit. I came to the conclusion after some pottering that it would be tough to make emacs nearly as good a python IDE as pycharm, not like a weekend's work it looked like a project in itself. It would again be a project in itself to make it as useful as jupyter for data-things. Someone has worked on embedding jupyter in emacs but it's a bit janky and you're then locked out from any extensions which will be written in javascript and expecting a DOM. An investment in emacs seems to require a 10+ year time horizon, which means betting that it's going to grow and not decline, the numbers seem against that. I think what I really want is atom/light-table to get a lot better but the second died at birth and vscode is going to kill the first whilst having an uglier inner model that is less friendly to extensibility. I really wish Mr Granger had stuck with Light Table instead of running down a blind alley of VC money. There's a great quote that the threat to emacs is the browser, since it's a completely scriptable environment, I guess jupyter/light-table/atom embody that. I still use spacemacs for running shells and editing files kind of ad-hoc.
- WalterGR 8y ago
  vscode is going to kill the first whilst having an uglier inner model that is less friendly to extensibility. I haven’t used VS Code much, but it’s extensions seem pretty rich. What things can an extension do in Atom that it can’t do in VS Code?
- taeric 8y ago
  Comparing to jupyter seems odd. Org-mode can already do most anything I have seen jupyter do. Out of the box, pretty sure it can do more, since it supports tangling of source blocks for execution. Note that I can't really claim you are wrong. People do seem to be converging on these tools rather heavily. I just can't see how it is capabilities that is driving it. Looks more like standard marketing.
- dangirsh 8y ago
  Emacs + Jupyter integration got significantly better with the recent emacs-jupyter package [1], which, while young, is about as un-janky as any Elisp I've seen. I use this daily now for Julia/Python development. The acs-jupter Org client augments Org's code cells with dynamic completion and inspection provided by the (potentially remote) kernel. The sessions can be managed per-subtree, enabling me to maintain various contexts within one Org file. [1]: https://github.com/dzop/emacs-jupyter https://github.com/dzop/emacs-jupyter
thom 8y ago
I think programmers are very good at fighting through frustration and pain, because so much of the job is just bad existing software, or libraries we don't control, or legacy code we don't have time to refactor etc. And so when something feels off in Emacs, your natural reaction is the same as when something is off in Word, on on your smartphone, or whatever. You just swallow your pride and live with it. It's hard to truly internalise that this isn't necessary in Emacs, that you can actually achieve a level of productivity and proficiency with elisp that the moment something annoys you, you can and should just fix it once and for all. That discipline is hard in any codebase, but it's especially hard with your editor that you don't really think of as just a pile of code that you are personally charged with maintaining. To an extent much of Unix is like this. In the early days it's exhausting and can be overwhelming - so much stuff seems suboptimal to your workflow and almost infinite customisability feels like a bit of a Fuck You when you just want to get stuff done. But then you realise you've had Linux installed for more than 20 years and there's stuff you could have fixed in your teens and never thought of again. At some point you should really just commit.
pjmlp 8y ago
> They do appreciate the likes of Atom, PyCharm, Jupyter notebooks, etc. with big beautiful GUIs with big beautiful menus and slick websites and “out of the box” support for what they need to do. Pop-up suggestions, Basically just like the surviving commercial Common Lisp IDEs have been doing the last 30 years.
narag 8y ago
Patience maybe isn’t even the right word; perhaps it’s just an unwillingness to invest in something that doesn’t really communicate an obvious return. I'd say it's more like the relation with a person. If you have no choice (your boss) you do whatever is needed, mostly. If you have choice but still you're very interested (for some reason) you put up with some quirks. Otherwise, you'll rather be with someone kinder.
register 8y ago
I am curious to know which domain you are using CL professionally. Can you tell us a little bit more? Also are you using an Open Source CL or a commercial one? P.S: mmmh... I guess you are working for Righetti right?
- reikonomusha 8y ago
  Quantum computation, specifically on compilers and simulators.

robertcarter 8y ago

care to share your emacs config/setup ?

zimablue 8y ago

I definitely fit into that second paragraph, and I appreciate you being careful to distinguish patience from being convinced of cost-benefit. I came to the conclusion after some pottering that it would be tough to make emacs nearly as good a python IDE as pycharm, not like a weekend's work it looked like a project in itself. It would again be a project in itself to make it as useful as jupyter for data-things. Someone has worked on embedding jupyter in emacs but it's a bit janky and you're then locked out from any extensions which will be written in javascript and expecting a DOM. An investment in emacs seems to require a 10+ year time horizon, which means betting that it's going to grow and not decline, the numbers seem against that. I think what I really want is atom/light-table to get a lot better but the second died at birth and vscode is going to kill the first whilst having an uglier inner model that is less friendly to extensibility. I really wish Mr Granger had stuck with Light Table instead of running down a blind alley of VC money. There's a great quote that the threat to emacs is the browser, since it's a completely scriptable environment, I guess jupyter/light-table/atom embody that. I still use spacemacs for running shells and editing files kind of ad-hoc.

WalterGR 8y ago
vscode is going to kill the first whilst having an uglier inner model that is less friendly to extensibility. I haven’t used VS Code much, but it’s extensions seem pretty rich. What things can an extension do in Atom that it can’t do in VS Code?
taeric 8y ago
Comparing to jupyter seems odd. Org-mode can already do most anything I have seen jupyter do. Out of the box, pretty sure it can do more, since it supports tangling of source blocks for execution. Note that I can't really claim you are wrong. People do seem to be converging on these tools rather heavily. I just can't see how it is capabilities that is driving it. Looks more like standard marketing.
dangirsh 8y ago
Emacs + Jupyter integration got significantly better with the recent emacs-jupyter package [1], which, while young, is about as un-janky as any Elisp I've seen. I use this daily now for Julia/Python development. The acs-jupter Org client augments Org's code cells with dynamic completion and inspection provided by the (potentially remote) kernel. The sessions can be managed per-subtree, enabling me to maintain various contexts within one Org file. [1]: https://github.com/dzop/emacs-jupyter https://github.com/dzop/emacs-jupyter

thom 8y ago

I think programmers are very good at fighting through frustration and pain, because so much of the job is just bad existing software, or libraries we don't control, or legacy code we don't have time to refactor etc. And so when something feels off in Emacs, your natural reaction is the same as when something is off in Word, on on your smartphone, or whatever. You just swallow your pride and live with it. It's hard to truly internalise that this isn't necessary in Emacs, that you can actually achieve a level of productivity and proficiency with elisp that the moment something annoys you, you can and should just fix it once and for all. That discipline is hard in any codebase, but it's especially hard with your editor that you don't really think of as just a pile of code that you are personally charged with maintaining. To an extent much of Unix is like this. In the early days it's exhausting and can be overwhelming - so much stuff seems suboptimal to your workflow and almost infinite customisability feels like a bit of a Fuck You when you just want to get stuff done. But then you realise you've had Linux installed for more than 20 years and there's stuff you could have fixed in your teens and never thought of again. At some point you should really just commit.

pjmlp 8y ago

> They do appreciate the likes of Atom, PyCharm, Jupyter notebooks, etc. with big beautiful GUIs with big beautiful menus and slick websites and “out of the box” support for what they need to do. Pop-up suggestions, Basically just like the surviving commercial Common Lisp IDEs have been doing the last 30 years.

narag 8y ago

Patience maybe isn’t even the right word; perhaps it’s just an unwillingness to invest in something that doesn’t really communicate an obvious return. I'd say it's more like the relation with a person. If you have no choice (your boss) you do whatever is needed, mostly. If you have choice but still you're very interested (for some reason) you put up with some quirks. Otherwise, you'll rather be with someone kinder.

I am curious to know which domain you are using CL professionally. Can you tell us a little bit more? Also are you using an Open Source CL or a commercial one? P.S: mmmh... I guess you are working for Righetti right?

reikonomusha 8y ago
Quantum computation, specifically on compilers and simulators.