3 ms·
- 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 ve
by marijn 13y ago
- 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.
- deng 13y ago> 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/Structures.html http://www.gnu.org/software/emacs/manual/html_node/cl/Struct... http://www.gnu.org/software/emacs/manual/html_mono/eieio.html http://www.gnu.org/software/emacs/manual/html_mono/eieio.htm...
- marijn 13y agoThese are macros on top of vectors, aren't they?
- deng 13y agoYup. Not good enough?
- marijn 13y agoMy 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.
- deleted 13y ago[deleted]
- agumonkey 13y agoSo 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...