Hacker News Reader

Comment by goldfeld | Hacker News Reader

I see the argument that Emacs Lisp is what we have and works fine floated around by many Emacs veterans, but I wonder if they realize the unrealized potential (opportunity cost) of keeping Guile Scheme out (as Stefan seems to prefer, whereas RMS is in favor of Scheme), and that Emacs going forward can probably yet produce more wealth of extensions than in the past 30 years? I completely agree that keeping full compatibility with all existing extensions is the absolute priority for the new Guile engine, but I myself have kept away from coding anything in Emacs Lisp other than a simple lambda binding because of Elisp's warts and very forgettable ways to do common things (e.g. manipulate strings in general.)

View on HN

Wow, time sure does fly. I was discussing Guile and Emacs 5 years ago on StackOverFlow. The 10 year old article that I referenced is no longer there.

http://stackoverflow.com/questions/1663627/guile-and-emacs

That's 15 years of talking. My personal feeling is that sometimes it's just better to abandon projects that stagnate. There's an open source Go version of Sublime, for example. It would probably be easier to maintain.

https://github.com/limetext/lime

That, or contribute to Neovim https://github.com/neovim/neovim

Neovim is a fantastic project, even if you're not interested in vim. They are a model example of how a FOSS kickstarter should be run.

Sad to see you were downvoted. It's definitely a legitimate point of view that at least deserves to be brought up.

I love emacs and it pains me to agree with this, at least in part.

It has reached an odd place, there is enough legacy code (or so it's believed) that it can't be abandoned, there are clear innovations that will never go in to elisp (jit compilation, threads, Ffi, etc) and guile isn't being accepted while it is clearly the best way forward that has been suggested. It's like emacs is done.

Considering something else only makes sense...

Are you living in the real world? The complexities are around keeping a stable platform that some of us have been using for 10-15 years with few complaints.

As with any corporate product, you can't go changing shit when you have a large paying userbase.

XEmacs? I remember when it was the more modern emacs and I was younger and had to have all the new things. After a while I noticed that gnu emacs had picked up everything that xemacs had and was better maintained so I switched back to gnu. Maybe another fork like that could drive emacs forward. The more adventurous emacs users could use and drive the fork forward while other can stay comfortable with regular gnu emacs for a while longer.

> My personal feeling is that sometimes it's just better to abandon projects that stagnate. There's an open source Go version of Sublime, for example. It would probably be easier to maintain.

That's throwing the baby out with the bathwater. The only thing which makes Emacs-on-Guile difficult is backwards compatibility. If you find Sublime a viable option, then compatibility isn't an issue for you; in which case there's nothing preventing you from using Emacs-on-Guile right now.

I find http://hyperpolyglot.org/lisp to be extremely useful for cases when I know what I want to do but don't remember how to do it in Elisp.

Brilliant, thank you very much!

Awesome resource.

A word of warning for Elisp hackers: the Emacs Lisp part of that resource was written by someone with a CL background. I'm seeing various examples that are not conventional Elisp. For instance, ' is used instead of #' for function quoting in various places (prevents compilation of the function) and use of eval on a form instead of apply on a list (dangerous and also prevents compilation of the form). In addition, many of these features use the cl package at runtime, which will cause the compiler to throw a warning, because it's not allowed in Emacs proper.

That said, there's a lot of information here that's very useful for the starting Elisp programmer.

>For instance, ' is used instead of #' for function quoting in various places (prevents compilation of the function) and use of eval on a form instead of apply on a list

I don't see how these are evidence of the author having "CL background". CL is pretty much identical to Emacs lisp with regards to both of these things.

Truth be told, I know nothing of CL. I do know quite a bit about Elisp, and since it's not an Elisp-ism, and the CL and Elisp columns share so much identical code (a lot from cl.el), I assumed it was a CL-ism. My bad.

the #' in CL and Elisp are not the same. Elisp is a lisp-1 vs CL 'lisp-2'. The only similarity is that #'foo expands too (function foo). In CL (function foo) looks up foo in the function namespace (and iiuc can be omitted where functions are expected) in elisp the function form is like quote except for when byte-compiling. It allows the function to be byte-compiled.

I don't think anybody is proposing to move away from emacs lisp as the usual scripting language. Rather, you'd initially move to Guile's implementation of emacs lisp, and potentially later allow use of other languages supported by Guile.

This is exactly right. The proposal is to change elisp implementations. elisp the language won't be going anywhere anytime soon.

For me that boat sailed a long time ago, around 2005.

Since 1996, Emacs was a kind of IDE replacement when I was in UNIX environments and could not use my beloved MS-DOS/Windows IDEs, but nowadays UNIX systems also enjoy quite powerful IDEs.

Reply on news.ycombinator.com