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

91–100 of 160 posts

Re: Emacs Lisp's Future

#91

Post by belorn »

bane wrote: post #82
teddyh wrote: post #21

Earlier quoted context omitted.

> Remind me again how the GPL preserves my freedom. Very well. The governments and states of the world has agreed that any written or creative works shall have owners , called “copyright holders”, who can decide who, if any, other persons shall have the right to make further copies and/or make modifications of those works. This legal arrangement is made with a few specific business models in mind, but those business…

> without having any other deleterious effects And I guess that's the problem isn't it? It does have deleterious effects, but within the narrow definition of "freedom" the GPL uses, those effects are unimportant/ignored. The long-term vision of the GPL does provide a kind of "freedom" along it's specific definition, but strongly denies all other kinds along the way. It's like saying "drinking alcohol is unhealthy" an…

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 freedom. As teddyh wrote above, copyright do not give equal rights to whomever has the work, but GPL changes this and preserves the rights which without copyright we would all equally share.

John Stuart Mill published in 1859 a book called "On Liberty", in which he recognized the difference between liberty as the freedom to act and liberty as the absence of coercion. This concept of positive liberty and negative liberty can be distilled into two different concepts of "freedom". One can have the freedom of speech (a positive liberty), and the freedom of not getting enslaved (a negative liberty).

GPL provides the latter, in that it prevents the coercion which copyright law provides.

Re: Emacs Lisp's Future

#92

Post by lispm »

Blackthorn wrote: post #9
informatimago wrote: post #4

I've got the impression that there is more Common Lisp code and programmers around than guile.

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.

CL has more maintained implementations than Guile has programmers.

Re: Emacs Lisp's Future

#93

Post by dragonwriter »

belorn wrote: post #91
bane wrote: post #82

Earlier quoted context omitted.

> without having any other deleterious effects And I guess that's the problem isn't it? It does have deleterious effects, but within the narrow definition of "freedom" the GPL uses, those effects are unimportant/ignored. The long-term vision of the GPL does provide a kind of "freedom" along it's specific definition, but strongly denies all other kinds along the way. It's like saying "drinking alcohol is unhealthy" an…

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 which copyright law provides.

GPL is an instance of the coercion which copyright law provides, not a prevention of it: you can use the thing to which I have been granted exclusive rights under copyright, so long as you act as I have directed based on my perception of what serves my interests.

And, compared to other free software licenses, the GPL -- especially the GPLv3 -- is a fairly heavy handed instance of that coercion.

Re: Emacs Lisp's Future

#94

Post by lispm »

riffraff wrote: post #87

can someone more knowledgeable than me explain how is elisp closer to CL than to Scheme?

Both Emacs Lisp and Common Lisp are coming from MIT's Maclisp dialect. There were Emacs variants written in Maclisp or its dialects before GNU Emacs existed. Emacs Lisp was a very simplified Maclisp. Common Lisp modernized Maclisp (especially lexical binding), preserved a lot of Maclisp features and standardized stuff like an Object System (CLOS), error-handling (Conditions), enhanced argument lists (especially keyword arguments).

RMS especially did not like the addition of an object system, lexical binding as the default and keyword arguments. Those three things are quite central in Common Lisp. Emacs Lisp has no object-system in its core, lexical binding has only recently added and it has no keyword arguments.

Scheme is quite different from both. But Guile is a very special Scheme dialect with lots of enhancements, which makes it as large as a Common Lisp implementation. I would expect that code sharing between Scheme implementations is more difficult than between Common Lisp implementations.

Re: Emacs Lisp's Future

#95

Post by lispm »

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.

Re: Emacs Lisp's Future

#96

Post by pjmlp »

drostie wrote: post #83
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…

On the other hand, if you write Elisp in JS, you can run Emacs in the browser.

As if the browsers already didn't have enough bloat.

Re: Emacs Lisp's Future

#97

Post by tedks »

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://lists.gnu.org/archive/html/emacs-devel/2010-04/msg00...

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.

Re: Emacs Lisp's Future

#98

Post by adamc »

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

Re: Emacs Lisp's Future

#99

Post by chriswarbo »

riffraff wrote: post #87

can someone more knowledgeable than me explain how is elisp closer to CL than to Scheme?

ELisp, Scheme and Common Lisp are all LISPs, so they all use a common terminology, s-expressions for syntax, allow higher-order functions and macros, etc. but their programming paradigms tend to be different.

Common Lisp tends to follow a procedural style (if/switch statements, for/while-loops, lots of side-effects, etc.). CL also has the Common Lisp Object System (CLOS) which is a very powerful OO implementation.

On the other hand, Scheme tends to follow a more functional style (recursion, map/reduce, continuations, minimising side-effects, etc.).

ELisp tends to be quite procedural, which is why it's closer to CL than Scheme. Also ELisp uses dynamic scope whilst Scheme uses lexical scope. Lexical scope has only been (officially) supported in ELisp since Emacs 24 (the latest major version).

Re: Emacs Lisp's Future

#100

Post by wtbob »

tedks wrote: post #79
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/…

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

Post reply on HN