Hacker News Reader

Comment by brotheryuca | Hacker News Reader

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.

View on HN

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

Reply on news.ycombinator.com