Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

If it isn't broken, don't try to fix it.

I am an old guy (professional Lisp developer since about 1981) and my age probably affects my opinion:

It would be a disaster to mess up the Emacs ecosystem. I don't think that Emacs/elisp runs slowly and since I have to use so many different programming languages anyway, needing to know a little elisp is no problem.

I don't care if elisp is not a modern language.

Way off topic, something that I have written before about: think forwards several hundred years. What will the software landscape look like? My bet is that there will be many ancient software systems that have been debugged to near absolute stability over the centuries. Sure new software will be written, but I bet there will be many very old and stable systems that will see little change.



Wouldn't it be nice when Emacs would not be blocked when some Lisp routine runs?

Lots of people have written excellent code for GNU Emacs, but the implementation runtime hasn't improved that much.


Wouldn't it be nice when Emacs would not be blocked when some Lisp routine runs?

Yes, it would be nice, but can you imagine the bugs that will happen while everyone works out the details of how to do it properly?


Even in the current pre-alpha/alpha stage of Guile-Emacs, I can launch a thread from Scheme, do work, return to the main thread, then call an Elisp function on my result. (Scheme and Elisp data types are unified.) No bugs or unpleasant details there.

Calling Elisp functions and accessing Emacs data types (buffers, windows) from multiple threads is another issue; if you don't want to bother with it then don't; you still get all the other benefits of being on Guile. (Calling to any Guile module agnostically as if it were an Elisp library (including, say, Guile's OpenGL module), having an FFI, getting JIT or AOT native compilation in the future, etc.)


But, over the centuries, it will get debugged to near absolute stability.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: