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

111–120 of 160 posts

Re: Emacs Lisp's Future

#111

Post by astrobe_ »

dbpatterson wrote: post #80
linguafranca wrote: post #72

Why isn't Lua even a choice? It's small, portable, easily embeddable, lightning fast, supports high-level functional programming idioms, and is extremely flexible in creating and enforcing policies (via metaprogramming).

Because it is a completely different language and would require rewriting all of the thousands of packages by hand (and centuries of human labor)?

One option is to have both Lua and Elisp, so that packages can be slowly migrated. Lua is small (so it doesn't incur a huge size cost to have 2 engines), fast (one reason why they want to switch, according to the author), and has a significantly large community. It also has coroutines, which is not what people dream of when people talk about concurrency but is probably good enough for a text editor (and avoids most sync problems). Furthermore, with this "dual-engine" strategy it would be a bad idea to choose a language similar to ELisp: it would cause a lot of confusion.

But I guess that Emacs on Lua wouldn't be Emacs anymore. That's the main objection.

Re: Emacs Lisp's Future

#112

Post by e40 »

lispm wrote: post #95
mark_l_watson wrote: post #73

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 topi…

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?

Re: Emacs Lisp's Future

#113

Post by bachmeier »

adamc wrote: post #98
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/…

I agree with all of this as an emacs user, but I wonder whether this sets up emacs to be replaced by something that uses a more popular extension language, like Atom. Won't happen in the next 5 years, but 10 years down the line, being based on JavaScript might look like a great decision. I love lisp but I don't see much interest in it and have had coworkers tell me it keeps them away from emacs. Which is a bit sad...

I think emacs lisp is a great extension language. There's not much syntax, and it has the important functionality baked in. IMO anyone that says they don't use Emacs because they don't like Lisp is someone that would not use Emacs no matter what.

Re: Emacs Lisp's Future

#114

Post by tedks »

wtbob wrote: post #100
tedks wrote: post #79

Earlier quoted context omitted.

Guile can run elisp already, IIRC. There's no compatibility issue, it would just be a runtime change. And then you'd get Guile's VM, which is very nice and also polyglot(tic?). Guile is a language-agnostic VM, not a language itself, and a frontend already exists for elisp.

> There's no compatibility issue That's not really true, is it though? Scheme '(), #f and so forth...

As I said in my comment,

>Guile can run elisp already

Guile already interprets Elisp.

Elisp can run unmodified on Guile.

Guile, the virtual machine, contains a front-end for Emacs Lisp.

المكر ينفذ أصلا إيماكس اللثغة.

Guile jatorriz exekutatzen emacs Lisp.

It is true there are no compatibility issues because Guile is an implementation of Emacs Lisp.

Re: Emacs Lisp's Future

#115

Post by __david__ »

bane wrote: post #101
belorn wrote: post #91

Earlier quoted context omitted.

The only one here who is talking about the definition of "freedom" is you, and I find it lacking in both insight and meaning. Freedom has a long history of philosophical thoughts from the last two centuries. Roman Emperor Marcus Aurelius wrote over 2000 years ago that freedom is "a polity administered with regard to equal rights and equal freedom of speech", from which we can derive that equal rights is an aspect of…

> GPL provides the latter, in that it prevents the coercion > as the absence of coercion That's incorrect on all points. GPL is exists purely as a coercive license. It's up to you to decide if the coercion it's employing is a good thing or a bad thing (or somewhere in the middle), but it's one of the most highly coercive legal concepts in existence. What exactly do you think the GPL is about? It explicitly denies man…

> To cement the point, I'm going to show you what an actual, objective, maximally free license might look like:

> "Do whatever you want with this software."

So here's the perspective shift you need to understand it: that's not "maximally free". Because software is rarely a simple one layer system like:

   programmer -> user
Instead it passes through many hands:

   programmer -> derivative work programmer -> packager -> user
Your "maximally free" license is only maximal at the first exchange. But it gives anyone in the chain the "freedom" to remove the end user's ability to change the code (or incorporate it into a derivative work) as they see fit.

The GPL, on the other hand, tries to preserve the freedom all the way to the end user. There are way more users than there are middle-men, so I'd say the GPL gives more freedom to the world, even though it ties the hands of the people along the way to the end user ("forcing" them to pass the freedoms they enjoyed on to the next guy in the chain).

It really comes down to whether you believe that you (the end-user) should have the fundamental right to tinker with the source code of any piece of software you buy/acquire/run. The FSF believes in that right. Everything they do falls out from that belief.

> This is probably a good place to mention that the GPL licenses are specifically protected by copyright held and enforced by the FSF.

No, not really—it's not applicable to the situation at all. (A) The GPL isn't itself software, and (B) it's tightly controlled for practical reasons—if everyone and their dog changed little bits of the license you'd have a million incompatible licenses out there. That can only do harm to the ecosystem.

Re: Emacs Lisp's Future

#116

Post by rthomas6 »

tedks wrote: post #97

A lot of people seem to be reading this as if Emacs is choosing between switching languages to Scheme (Guile) or Common Lisp. Switching to Guile DOES NOT IMPLY switching to Scheme. There is 0 need for compatibility layer or what have you with Guile. Guile is a language-agnostic virtual machine. It has an implementation for Scheme, but also one for Emacs Lisp. Guile already runs Emacs Lisp faster than Emacs: https://l…

>The main issue the Emacs developers seem to have with Guile is that it will give developers choices as to whether to write Emacs extensions in Scheme, Elisp, or Javascript/Python/Whatever else Guile supports

I don't understand why they care? Why would the Emacs developers feel the need to debug compatibility if someone else wrote a shitty extension? The onus would be on the extension developer to fix the extension.

Re: Emacs Lisp's Future

#117

Post by wtbob »

mijoharas wrote: post #61
TeMPOraL wrote: post #45

Earlier quoted context omitted.

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

hmm... from reading this I feel like I'm in the minority but I think I'd prefer scheme to CL (I have to emphatically agree that thinking of a javascript-emacs makes me shudder). Something about the macros not being hygienic in CL bothers me. I know it's alright as long as you don't redefine anything you shouldn't be redefining but it seems less elegant, and since we're using lisps anyway I feel we should search for t…

CL is generally less elegant but more practical than Scheme. It does have a few warts, but for the most part it trades cleanliness for usefulness.

Scheme is really cool; I like it. But I use CL:-)

Re: Emacs Lisp's Future

#118

Post by wtbob »

linguafranca wrote: post #72

Why isn't Lua even a choice? It's small, portable, easily embeddable, lightning fast, supports high-level functional programming idioms, and is extremely flexible in creating and enforcing policies (via metaprogramming).

Because Lua is a strictly less useful language than elisp. Among other things:

- It doesn't have macros.

- It doesn't have integers.

- It doesn't have arrays.

- It doesn't have lists.

- It doesn't have dynamic binding.

Also, its 1-based array-like hash tables are just ecchy.

I like Lua; it's cool for what it is (and in fact I'm currently writing some hobby code in it), but it's not Lisp (and in fact my current hobby code is Lisp in Lua…).

Re: Emacs Lisp's Future

#119

Post by sklogic »

wtbob wrote: post #118
linguafranca wrote: post #72

Why isn't Lua even a choice? It's small, portable, easily embeddable, lightning fast, supports high-level functional programming idioms, and is extremely flexible in creating and enforcing policies (via metaprogramming).

Because Lua is a strictly less useful language than elisp. Among other things: - It doesn't have macros. - It doesn't have integers. - It doesn't have arrays. - It doesn't have lists. - It doesn't have dynamic binding. Also, its 1-based array-like hash tables are just ecchy. I like Lua; it's cool for what it is (and in fact I'm currently writing some hobby code in it), but it's not Lisp (and in fact my current hobby…

MetaLua has pretty decent macros.

Re: Emacs Lisp's Future

#120

Post by linguafranca »

wtbob wrote: post #118
linguafranca wrote: post #72

Why isn't Lua even a choice? It's small, portable, easily embeddable, lightning fast, supports high-level functional programming idioms, and is extremely flexible in creating and enforcing policies (via metaprogramming).

Because Lua is a strictly less useful language than elisp. Among other things: - It doesn't have macros. - It doesn't have integers. - It doesn't have arrays. - It doesn't have lists. - It doesn't have dynamic binding. Also, its 1-based array-like hash tables are just ecchy. I like Lua; it's cool for what it is (and in fact I'm currently writing some hobby code in it), but it's not Lisp (and in fact my current hobby…

> Because Lua is a strictly less useful language than elisp.

The word "useful" is too subjective to be useful here.

> - It doesn't have macros.

There's MetaLua for those who truly think they need macros. But in reality they're just a convenience.

> - It doesn't have integers.

Lua 5.3 is getting them.

> - It doesn't have arrays.

It has tables that function perfectly well as arrays.

> - It doesn't have lists.

Singly-linked-lists can easily be created using tables.

> - It doesn't have dynamic binding.

Thankfully!

> Also, its 1-based array-like hash tables are just ecchy.

This is purely an imaginary problem. Personally, I prefer 1-baed indices.

> I like Lua; it's cool for what it is (and in fact I'm currently writing some hobby code in it), but it's not Lisp (and in fact my current hobby code is Lisp in Lua…).

So, your favorite language is Lisp? Great. Except, favoritism and bias aren't really compatible with truly constructive criticism.

Post reply on HN