Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Emacs Lisp's Future

lists.gnu.org

Post reply on HN
Print view View original

41–50 of 160 posts

Re: Emacs Lisp's Future

#41

Post by levosmetalo »

apgwoz wrote: post #29
tenfingers wrote: post #28

Earlier quoted context omitted.

I've been programming with ELisp, CL and Scheme for a long time. Somehow Guile feels like an odd choice. Why not Chicken scheme, or Racket, or Bigloo; which are the top scheme environments you can choose from? AFAIK, Guile is not used much beyond a few random projects. Maybe I just don't know Guile, really. Maybe it has a decent implementation afterall. However, I would have gone CL. There are several "emacs-like" ed…

Guile was designed as an extension language, which CL was not. So, that's one reason. Guile also has a something like 90% working implementation of an elisp compiler to guile bytecode, a JavaScript implementation and (I think, though may be wrong) a working Lua compiler. None of the other mentioned scheme implementations were designed for embedding, even if they are fine implementations themselves (which they are).

If we consider "designed for embedding" as a driving point we can always take ECL (embeddable/extensible common lisp) as a base and get both very nice ffi and threading while still being CL.

Re: Emacs Lisp's Future

#42

Post by TeMPOraL »

rwmj wrote: post #37
terminalcommand wrote: post #30

If emacs supported new languages other than elisp, a lot of new blood will join the community. Once we get the new hackers, they will try and find ways to modify the old codebase. Emacs is a wonderful editor, but to a newcomer it can be a lot daunting. For example, I have completed the emacs tutorial, I've even read the infos info tutorial and several info pages regarding emacs and still don't know much about ELisp.…

Does emacs want the kind of developers who cannot be bothered to learn Elisp? Apart from the syntax, Javascript and Lisp are not really so different.

They differ in semantics and elegance, and for that reason alone I wouldn't want Emacs to end up scripted in JavaScript.

Sure it would bring new blood. It will also drive away old one; people, for whom Emacs is a Lisp runtime with a text editor bolted on top of it. Switching Emacs from Elisp to something else feels like selling its soul. Adding parallel support for JavaScript and bunch of other languages feels like turning it into a Frankenstein monster.

Re: Emacs Lisp's Future

#44

Post by vfclists »

terminalcommand wrote: post #30

If emacs supported new languages other than elisp, a lot of new blood will join the community. Once we get the new hackers, they will try and find ways to modify the old codebase. Emacs is a wonderful editor, but to a newcomer it can be a lot daunting. For example, I have completed the emacs tutorial, I've even read the infos info tutorial and several info pages regarding emacs and still don't know much about ELisp.…

Can you write a plugin for Kate with Kate's own built-in development language and have it running immediately without having to go through a separate edit-compile-debug cycle using a different development toolset?

Re: Emacs Lisp's Future

#45

Post by TeMPOraL »

muuh-gnu wrote: post #10
Blackthorn wrote: post #9

Earlier quoted context omitted.

Literally dozens more. Look, neither Common Lisp nor any Scheme implementation are exactly topping the charts in popularity these days. This should be about the technical merits of the choice, because I'm pretty sure Emacs Lisp both has more code and more programmers (both represented in the forms of small scripts we've shoved into scratch and evaluated) than both.

The decision to go either Common Lisp or Scheme was made based on RMS very personal reasons and conflicts with close-source Lisp machine companies during the first half of the 80s. GNU has had two common Lisp implementations under their umbrella at least since mid 90s (CLISP (of Viaweb fame) and GCL (of Maxima fame)), but due to RMS' hate of Symbolics and Common Lisp, all of the effort was invested into making Guile…

> The Emacs guys, as you see from the post, are not _really_ excited about the idea of switching to another _language_. They want FFI, multithreading, etc, but they do not necessarily want Scheme. Actually they dont want Scheme at all, adopting Scheme would be just a price to get FFI, etc.

A price some of us don't feel like paying. It might be irrational, but when thinking about switching Emacs to Guile, I feel it's like proposing to sell its very soul. A Guile-powered Emacs would feel... weird (the it-walks-and-talks-but-when-you-look-into-the-eyes-there's-noone-home p-zombie kind of weird) (and don't get me started on ideas like "let's script Emacs in Javascript", like Emacs was a scriptable editor like the others...).

Strangely, I get less of this feeling with Common Lisp, maybe since Elisp is closer to CL than it is to Scheme.

Re: Emacs Lisp's Future

#46

Post by josteink »

TeMPOraL wrote: post #42
rwmj wrote: post #37

Earlier quoted context omitted.

Does emacs want the kind of developers who cannot be bothered to learn Elisp? Apart from the syntax, Javascript and Lisp are not really so different.

They differ in semantics and elegance, and for that reason alone I wouldn't want Emacs to end up scripted in JavaScript. Sure it would bring new blood. It will also drive away old one; people, for whom Emacs is a Lisp runtime with a text editor bolted on top of it. Switching Emacs from Elisp to something else feels like selling its soul. Adding parallel support for JavaScript and bunch of other languages feels like t…

> Sure it would bring new blood. It will also drive away old one; people, for whom Emacs is a Lisp runtime with a text editor bolted on top of it. Switching Emacs from Elisp to something else feels like selling its soul.

While I agree with most of your statement, having Emacs switch/transition/support another, more modern form of Lisp like CL surely wouldn't count as selling your soul.

On the contrary you would stay true to your ideals (a Lisp-runtime with an editor) except now the Lisp runtime just got a lot better.

I like Emacs as much as the next guy, and I have dabbled some in Elisp. I can make due. But I sure as hell wouldn't mind getting some of that neat stuff the CL-guys are getting.

Re: Emacs Lisp's Future

#47

Post by TeMPOraL »

josteink wrote: post #46
TeMPOraL wrote: post #42

Earlier quoted context omitted.

They differ in semantics and elegance, and for that reason alone I wouldn't want Emacs to end up scripted in JavaScript. Sure it would bring new blood. It will also drive away old one; people, for whom Emacs is a Lisp runtime with a text editor bolted on top of it. Switching Emacs from Elisp to something else feels like selling its soul. Adding parallel support for JavaScript and bunch of other languages feels like t…

> Sure it would bring new blood. It will also drive away old one; people, for whom Emacs is a Lisp runtime with a text editor bolted on top of it. Switching Emacs from Elisp to something else feels like selling its soul. While I agree with most of your statement, having Emacs switch/transition/support another, more modern form of Lisp like CL surely wouldn't count as selling your soul. On the contrary you would stay…

> While I agree with most of your statement, having Emacs switch/transition/support another, more modern form of Lisp like CL surely wouldn't count as selling your soul.

I... I'm not sure, but I'm leaning towards agreeing. I can tell you that I don't get those "we're lobotomizing it" vibes when I think about switching Elisp for CL. Maybe because those two look alike and have similar philosophy. But even a thought of switching to Scheme, which is still a Lisp, sends chills down my spine.

I know, this is completely irrational. But maybe this is a part of Emacs's appeal. You get attached to it, down to its very core.

Re: Emacs Lisp's Future

#49

Post by swah »

terminalcommand wrote: post #30

If emacs supported new languages other than elisp, a lot of new blood will join the community. Once we get the new hackers, they will try and find ways to modify the old codebase. Emacs is a wonderful editor, but to a newcomer it can be a lot daunting. For example, I have completed the emacs tutorial, I've even read the infos info tutorial and several info pages regarding emacs and still don't know much about ELisp.…

Shouldn't it also use webkit or something for rendering? So.. change the rendering, change the language... shouldn't we just write more editors from zero?

Re: Emacs Lisp's Future

#50

Post by mjn »

JulianMorrison wrote: post #36
yason wrote: post #8

Given all the reworks of software projects that have a) been started b) then delayed c) then delayed more, "because this time we'll make it perfect" and d) then failed to gather traction because of incompatibilities, it's my humble guess that the only way would be to continue ELisp as it is and slowly rework the compiler/interpreter and the runtime into a more modern codebase, and add missing features such as thread/…

If I was them, I'd gradually introduce the minimum set of breaking changes to ELisp that converge it on Common Lisp. Even if those changes were unhelpful or removed features. Then eventually, when it maps 1:1 onto a subset of CL, just swap the implementation for a supported CL.

Some years ago the a clisp maintainer actually made a minimal demo of Emacs hosted on clisp with just a compatibility layer for Elisp via macros/functions, which seemed to work pretty well. But it didn't progress any further because Stallman vetoed basing Emacs on Common Lisp (he considers CL to be too big a language, and to some extent just doesn't like it). In retrospect I'm not sure this was a good call: Guile as a general VM with custom infrastructure to support both Scheme and Elisp is not really a more clean, minimalistic infrastructure anyway. The semantics of Elisp/Scheme are too different to be able to just stick in a Scheme implementation with a smallish compatibility layer, like you could with Elisp hosted on CL.
Post reply on HN