Hacker News Reader

Comment by marijn | Hacker News Reader

Emacs Lisp is such a horrible language, and the Emacs ecosystem is so firmly stuck in the past (mutable state and magic hidden side effects and interactions everywhere) that writing extensions for it is much harder than it should be. It has enough history and a smart enough user base to have a lot of cool functionality, but the idea that it is somehow exceptionally wonderful just doesn't hold.

(I use Emacs for all my coding, and Common Lisp is my favorite programming language, so, if anything, my biases would be in favor of Emacs. Sadly, it doesn't really deliver -- not that other editors get their interface right. Don't get me started on vim. ST is somewhat better, but doesn't expose powerful enough tools. If I may toot my own horn, I believe my own project, http://codemirror.net , does a lot of things right on the editor API level that popular editors get tragically wrong.)

View on HN

Fellow emacs user/addict. Emacs is, to steal a phrase from the politics, the "least bad form of editor" IMO. Your criticism of elisp, dynamic scoping, and mutable-state everywhere is spot-on. To use emacs is to constantly put up with things in a state of "almost works, kind of broken". Partly the language and design, and partly just the culture of the editor, I think.

(For me personally being able to run in a terminal is a huge feature, which means I'll probably be stuck w/ emacs forever -- no one making new editors seems to care about terminal support.)

Elisp isn't really horrible. It sits on top of a local maximum in the fitness landscape. So often, little tweaks are needed, and dynamic scope lets you tweak more than a more engineering-oriented language would. It gets adapted to the task at hand in a worse-is-better, almost Darwinian way. The ability to redefine and tweak functions called by other functions, eval'd live in a buffer, is key. Without that, it would be a tenth the editor it is.

JS would not be a better language. Guile could be.

I used to think a more semantically aware setup would be better. But the costs of semantic awareness are enormous, because a single mismatch between what your editor understands, and what the underlying language can represent, breaks everything. This makes things fragile; parser error recovery is not an easy thing to get right. Some artfully written regexes can go further, in a practical sense.

It's stuck in the past because of its architecture and no doubt a lack of people to actually carry out large, wholesale changes.

Part of what Emacs a great editor and Elisp a great tool for mutating -- if one can call it that -- is exactly the same things that make it "bad." Yes, it has dynamic scoping, and yes you can change variables outside your scope -- which is exactly the level of granularity your average Emacs hacker wants. He's not looking to write rock-solid code for the mars rover; he's trying to make M-x compile a bit less crap or a bit more specific to what he's doing.

Say what you want about side effects and advising and all the other "terrible" practices that, in any sane software project, would never pass peer review -- in Emacs it enables you to hot plug, duct tape and jury rig Emacs to get it to do what you want.

The last 2-3 years has seen a massive resurgence in Emacs packages and there's a lot of buzz in the community, I feel, in trying to push things in the right direction. But it takes time. And people. And we need both.

I do not believe a tool can only be useful for either getting things done quickly or solid engineering. Even a monster like JavaScript manages to support both modes quite well.

Very true, but I don't think that's the conclusion I was reaching. The very things that make some things easy, like dynamic scoping; advising things left and right; wholesale overriding functions in your init file; aliasing or fsetting things. Each one of these things adds technical debt, but in this case, the technical debt has no real cost as it's not often a shared project and is mostly limited to snippets and bits of code that gets stuck in a file and rarely touched again.

When someone says elisp is a mess, they are holding a high bar. It's not a mess like BASIC. JavaScript is not an improvement.

Writing editor extensions is a totally different set of programming compared to writing applications that will run unattended across terabytes of data for years. A programmer is always sitting in front of a programming environment while your code runs. Therefore, it makes sense to allow things like deep access to the internals (dynamic scope, etc.), because if something goes wrong, it's only because the person currently in front of the computer told it to go wrong. And she's a programmer, so she can fix it.

I guarantee you that if Emacs used a "real" extension language, with lots of OO and state hiding, you'd be yelling obscenities into the computer the first time you wanted to tweak some extension you had. Have you ever seen an Eclipse user tweak one of his extensions? Didn't think so.

I don't know...I feel like a lot of the emacs stuff is half-broken in weird ways (e.g., iedit mode doesn't work when editing grep results with grep-ed; hl-line-mode doesn't work if you're on the last line of a shell buffer, etc.). If I, as a programmer, tried to fix every broken elisp/emacs edge case I came across, I'd never get anything else done...and still not have a bug-free emacs, ya know? :)

Agreed the ease of modification of emacs is unparalleled (and tricks like dynamic scoping can be handy at times), but I'm not convinced that it wouldn't be possible to get something aprox. as flexible and easy to modify with a more robust culture and langauge. (But not a classic "real OO" language, which I agree would be very annoying -- I'm thinking something with a strong functional flavor and static structural typing...)

Whether this is really possible or not is an open question, though.

Hi Marijn! Love your work, especially Eloquent JavaScript[1] which is my goto link for when people ask me "where should i start if I want to learn how to code". And CodeMirror is really an amazing piece of kit, of course.

So out of curiosity, how far away do you think CodeMirror is from being usable as a real local editor - and by that I mean how far away would you be from using it instead of Emacs? It seems like it would be straightforward to embed in something like node-webkit[2]. What else then remains?

[1] http://eloquentjavascript.net/ [2] https://github.com/rogerwang/node-webkit

There a whole bunch of stuff that needs to be wrapped around the editor UI component to make it a useful desktop editor. I started working on something like that at some point, but just didn't have the time to get anywhere. You might want to look at node-mirror [1] . I'm not following it very closely, but it did look promising the last time I installed it.

[1]: https://github.com/soliton4/nodeMirror

While I would not say that Elisp is the greatest programming language every created, I would hardly call it horrible, nor would I call it entrenched in the past. The Emacs designers seem to put real effort into improving the language over time, even to the degree of breaking backwards compatibility. That's pretty hard to for an editor that greatly depends on the functionality of user-written extensions. Also, consider the recent addition of lexical scoping. That's a brobdingnagian change to a programming language, editing language or not.

- There are still no structs/objects/whatever, so you're stuck using lists for everything. Real lisps grew out of that long ago.

- The compiler really isn't very effective, so doing expensive things is often tricky and takes a lot of fiddly optimizing to get halfway acceptable performance (this should get better when/if guile becomes the Emacs compiler).

- But the killer is the APIs and conventions that exists around the language. It's neat with how little code you can do some things using direct actions on buffers, and the various hooks make a lot of things sort of possible, but I've found again and again that things just don't compose, scripts trample on each other's toes, and trying to deal with dynamic scope (even with lexical scoping, lots of interfaces depend on dynamically scoped variables and concepts, such as the current buffer) when you're doing something asynchronous is a total nightmare.

> There are still no structs/objects/whatever, so you're stuck using lists for everything. Real lisps grew out of that long ago.

http://www.gnu.org/software/emacs/manual/html_node/cl/Struct...

http://www.gnu.org/software/emacs/manual/html_mono/eieio.htm...

These are macros on top of vectors, aren't they?

Yup. Not good enough?

My experience is that vector-based structs don't perform as well as 'real' structs do (the compiler isn't able to infer their type or the type of their content, has to do bounds checking for every access, etc), and occasionally make debugging painful, but yes, they are actually a lot better than just using lists throughout.

So is it correct to say that elisp isn't bad (since it has lexical scope now), but the text/gui api that are too imperative in nature ?

I remember nicferrier and others discussing how to write lazy streams for elisp in order to have a more functional text processing ~std lib.

All in all I agree with you that the extensions are weirdly integrated and fragile, maybe it's time to build a side-project emacs with better abstraction layers.

ps: What's make me so sad it that elisp editing api is really not lispy in nature. Language doesn't dictate good design...

If you think elisp is bad, you never tried Mocklisp in Gosling/UniPress emacs.

I disagree. I've written code to modify how emacs runs for me. I've never customised any other editor or IDE with the same ease of emacs - and I say this as an IDE slut - I'll use everything and anything.

That said, an emacs rewrite in Clojure is a wet-dream of mine (emacs like goodness with the ability to use modern GUI libraries, ANTLR parsers etc... and speed!)

Oh man, mine too. Although part of me thinks this is like saying, "you know, Everest would be way better if moved twenty feet west."

There is this project: https://github.com/hraberg/deuce

Although it seems to be stalled. Part of me wonders/hopes LightTable will get to the point that it is a viable replacement for emacs.

I'm a bit late to the party, but https://github.com/hraberg/deuce

Elisp is bad, but not nearly as bad as vimscript.

Yes, no contest there.

Vim is just an editor, though. Not an IDE, Javascript interpreter, operating system, and coffee maker.

That is because vimscript is such an awful language. People have written amazing plugins for hooking into compilers and what not, but only a few people on Earth are capable of taming vimscript.

Elisp isn't the problem. It's a fine language.

Edit: it's obviously far from perfect, but it has stood the test of time and it lets you get things done. It's no Scheme or CL, but for what people use it for it's fine.

For what it's worth, you can also write Vim extensions in Python. It's got access to all the same stuff as Vimscript. I would argue that Python is the better language when compared to elisp (even if one believes CL or other full-blown Lisp or Scheme variants are superior to Python).

I'm not saying that makes vim a better editor than emacs. Just pointing out that vim has other options for extending. Also, I use vim and haven't found emacs to be more productive; in my college days I tried emacs, in earnest, for a few months. I came back to vim eventually, and haven't felt compelled to give emacs another go since.

The Emacs/ELisp API, however, is far better. If we assume for a moment that ELisp and Python are, for the act of writing a editor extension, in similar good shape. Then it is still easier to write a good plugin with elisp for emacs than with python for vim, because the API that emacs offers for the integration of scripts is really, really fantastic. Vim doesn't offer anything like that.

For that matter, you can write emacs extensions in python, using Pymacs; given that it's marshalling objects to and from a subprocess over a pipe, it breaks when anything gets asynchronous, but lately when I've gone beyond "customization" to "actual code", pymacs has made it so much easier that after a few decades with emacs, I really want an open source editor with emacs' richness (and bindings) and python as a first-class extension language.

I'm seeing in-editor browsers more and more lately. I'm not sure why. Given the difficulties with arbitrary key binding, and with filesystem access -- both sine qua non of a programmer's editor -- it seems like any such tool starts out half-broken by design. Don't get me wrong; yours is quite nice, as far as they go. I just don't see how they go far enough to have been getting the consideration they have lately.

When you host a solid project like CodeMirror on a local Node.js instance, which fortunately has a heavy focus on I/O, you start to get those capabilities back. See something like Lighttable, which is essentially ClojureScript on top of Node.js, but sadly isn't open source (yet?) I think we're still a far cry from it, but maybe that'll be the future of Unix-based text editors, maybe that's what will eventually supersede Emacs (I say that as an avid user.)

That said, I wish I could pin some of my hopes to the upcoming Guilemacs.

As soon as it launches, Light Table will be open source.

"Will it be open source?

I'm a firm believer in open source software and open source technologies. I can guarantee you that Light Table will be built on top of the technologies that are freely available to us today. As such, I believe it only fair that the core of Light Table be open sourced once it is launched. At some level, this is an experiment in how open source and business can mix - it will be educational for us all." - http://www.kickstarter.com/projects/ibdknox/light-table

LT is one of the biggest stringalongs in recent memory. It is all about whipping up community goodwill in hopes of flipping a buck one day.

In the meantime, humble projects are progressing along without all the young people JS-dev hype.... CodeMirror, emacs/vim editor plugins, etc

Speaking of Light Table, did you know LT actually uses CodeMirror under the hood?

I won't get into the emacs debate since I am not sure I even know what it is about. But I think browser editors are the wave of the future, for the same reasons web software has been widely successful despite all shortcomings.

I am the founder of a browser based IDE software company, our product uses Codemirror exclusively and extensively..check my profile for the link if you want to check it out.

Emacs isn't good enough and there really aren't any radical improvements happening. The problem is the alternatives aren't better.

To put it another way, "Correlation between certain tools and smart people does not imply causality." Or exclusivity, for that matter.

Elisp has its wart, but... all told, for something created in the 1980ies, it's not that bad.

Yeah, but here we are 30 years later and we don't have something better! (And emacs, for all its faults, is still being actively developed and improved. But still...it's easy to imagine something much better. Harder to implement it, tho ;)

A lot of the value in Emacs these days is probably in the positive network externalities. Pick up pretty much any language or markup or whatever, and there will likely be a decent emacs mode.

>Emacs Lisp is such a horrible language

Beats the hell out of javascript.

Reply on news.ycombinator.com