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

151–160 of 160 posts

Re: Emacs Lisp's Future

#151

Post by babarock »

rthomas6 wrote: post #116
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.

Quoting the linked email:

  So if we go for Guile-Emacs, we'll be stuck with Guile, i.e. we'd
  have (old and new) packages that use Elisp, new packages that use
  Scheme, maybe yet other new packages that use, say, Javascript (or some
  other language support by Guile).  That would make the work of Emacs
  (and GNU ELPA) maintenance harder.

Re: Emacs Lisp's Future

#152

Post by bane »

__david__ wrote: post #132
bane wrote: post #122

Earlier quoted context omitted.

I don't materially disagree with most of what your saying. You seem to be providing an appropriately nuanced view of how the GPL works and the goals. And I agree completely with this statement > 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 fi…

The only freedom the GPL takes away is the freedom to deny freedom to others. Just as I live in a free country, yet I don't have the freedom to steal my neighbor's TV with no consequences. In that sense, yes, the GPL denies freedom. I guess I don't see the point of that argument though. > But I'm using it as a trivial tool to demonstrate that the GPL does not ensure the greatest possible freedom. It merely ensures th…

> The only freedom the GPL takes away is the freedom to deny freedom to others.

Example, I would like to take GPL software and then put it into the public domain.

No freedoms have been abridged, I have not prevented people from making changes to the software or tinkering with it, nor have I denied anybody the freedom to take it and put it back under some kind of license (after some derivation). In fact I would enable numerous freedoms, like the freedom for somebody to take the PD code and make changes (uninfringed), and then sell that changed code without releasing the source.

The GPL prevents me from having this freedom and others from enjoying the results of my exercise of this freedom.

You argue that a person who does that is unethically taking advantage of somebody else's labor, but the freedom of the originator to do the same isn't abridged either, so the originators of the labor could benefit from their own labor.

Or they can mix code from incompatible licenses, a freedom prevented under the GPL (most specifically 3). Under my license arbitrary distinctions like preventing the freedom to "link" to code are eliminated. I've advanced freedom again.

The trade-off is that I've removed the guarantee of perpetuating the transmission and disclosure of the source code. That's the only thing I've changed. But I haven't prevented the same thing from happening either. Under my plan somebody could make changes and also disseminate those changes via releasing the source if they wished to. Changes to the source might still thus perpetuate. But no freedom has been denied. Unlike with the GPL.

The GPL also seriously erodes the freedom to earn reward for labor and virtually abolishes the freedom to earn reward due to property ownership. It's a tradeoff that sides with increasing the efficiency of labor (by allowing for reuse). But there's a large body of work on recognized, but unexercisable freedoms because the person lacks the means to exercise it.

> Just as I live in a free country, yet I don't have the freedom to steal my neighbor's TV with no consequences. In that sense, yes, the GPL denies freedom. I guess I don't see the point of that argument though.

Then why argue it? I'm shedding karma here, because people can't accept this inarguable point of fact. More problematic than the freedom the GPL erodes is the religious tones it takes on. People talk about "freedom" without understanding it and downvote sensible discussions of the issues with the GPL without debate. Locke keeps being brought up by somebody else, but Locke's philosophy on property and the GPL are squarely at odds and irreconcilable.

> > The notional maximal license also believes in this. But it does not guarantee it. Then I would argue it doesn't really believe it. No true Scotsman, etc.

There's an enormous body of work on freedom as a guarantee vs. freedoms needing to be exercised. The notional maximal license enables all freedoms, but requires them to be exercised to be enjoyed. The GPL enables and guarantees a single freedom, but at the expense of all others.

Re: Emacs Lisp's Future

#153

Post by bane »

belorn wrote: post #133
bane wrote: post #101

Earlier quoted context omitted.

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

The only way to have maximum freedom as you define it, is by having no liberty. To give someone else liberty, someone must be coerced into giving it. This is simply a logical fact. In order for the maximum freedom you are talking about, the only thing said must be "do whatever you want". Kill who ever, steal what ever, enslave whom ever. If someone speak, someone else must be allowed to prevent them from speaking. Bu…

I think if you want to parallel Locke with the philosophy of the GPL, you need to reread your Locke.

You keep talking about freedom like it's a settled topic, but the debate on what is freedom and how to maximize is robust and vigorous, and Locke has not been the leader in liberal thought for a very long time and RMS is not taken very seriously in those circles either.

Re: Emacs Lisp's Future

#154

Post by __david__ »

bane wrote: post #152
__david__ wrote: post #132

Earlier quoted context omitted.

The only freedom the GPL takes away is the freedom to deny freedom to others. Just as I live in a free country, yet I don't have the freedom to steal my neighbor's TV with no consequences. In that sense, yes, the GPL denies freedom. I guess I don't see the point of that argument though. > But I'm using it as a trivial tool to demonstrate that the GPL does not ensure the greatest possible freedom. It merely ensures th…

> The only freedom the GPL takes away is the freedom to deny freedom to others. Example, I would like to take GPL software and then put it into the public domain. No freedoms have been abridged, I have not prevented people from making changes to the software or tinkering with it, nor have I denied anybody the freedom to take it and put it back under some kind of license (after some derivation). In fact I would enable…

> The GPL also seriously erodes the freedom to earn reward for labor and virtually abolishes the freedom to earn reward due to property ownership. It's a tradeoff that sides with increasing the efficiency of labor (by allowing for reuse). But there's a large body of work on recognized, but unexercisable freedoms because the person lacks the means to exercise it.

Translation: startups can't make their millions by selling a bunch of IP they've cobbled together from GPLed sources. Color me uncaring.

In the end, if you go back to my silly ascii art graph—your argument can be summed up that the individual '->'s lack freedom when the code is GPLed. I agree. But my point is with the GPL, the overall chain has more freedom because there are many more transactions the more arrows there are in the graph and the farther to the right you go (it's really more of a tree, but I collapsed it by node type for brevity).

Looking at the big picture, the GPL grants (almost paradoxically) infinitely more freedom to the world at large by the very fact that it restricts some developer freedoms. The GPL doesn't cater to developers, it was made for the end users.

Re: Emacs Lisp's Future

#155

Post by Steltek »

babarock wrote: post #151
rthomas6 wrote: post #116

Earlier quoted context omitted.

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

Quoting the linked email: So if we go for Guile-Emacs, we'll be stuck with Guile, i.e. we'd have (old and new) packages that use Elisp, new packages that use Scheme, maybe yet other new packages that use, say, Javascript (or some other language support by Guile). That would make the work of Emacs (and GNU ELPA) maintenance harder.

So don't accept packages into the Emacs core that don't meet their standards? It's okay to have project standards but limiting how other people use your tool seems terribly misguided for a GNU project.

Re: Emacs Lisp's Future

#156

Post by bane »

__david__ wrote: post #154
bane wrote: post #152

Earlier quoted context omitted.

> The only freedom the GPL takes away is the freedom to deny freedom to others. Example, I would like to take GPL software and then put it into the public domain. No freedoms have been abridged, I have not prevented people from making changes to the software or tinkering with it, nor have I denied anybody the freedom to take it and put it back under some kind of license (after some derivation). In fact I would enable…

> The GPL also seriously erodes the freedom to earn reward for labor and virtually abolishes the freedom to earn reward due to property ownership. It's a tradeoff that sides with increasing the efficiency of labor (by allowing for reuse). But there's a large body of work on recognized, but unexercisable freedoms because the person lacks the means to exercise it. Translation: startups can't make their millions by sell…

I'm leaving your last comment above as the conclusion of the discussion. I appreciate the lively sharing of views and enjoyed it (despite the rampant downvoting by others).

Re: Emacs Lisp's Future

#157

Post by belorn »

bane wrote: post #150
belorn wrote: post #137

Earlier quoted context omitted.

Please try define a freedom which do not need coercion of someone in order to enforce it. I defy that any such thing could exist. If you want freedom of speech, you have to prevent those who would seek out to squelch it. Freedom of the press is only possible by preventing those who would otherwise burn down the printing press. Freedom of person prevents assassins and rapists from doing their ill deeds, and has to be…

Well that's disingenuous. You specifically brought up that the GPL is a non-coercive agent for freedom. Now that we've demonstrated that it is coercive, you moved your fence posts. You're really tied up in the the history of liberty and freedom, and act like it the matter is all tied up and resolved. But very little could be further from the truth! Even more important, you keep attempting to draw parallels to enlight…

When its been demostrated that your arguments has dismissed in 17th century, you start to lash out agressively.

If you had proof of "the truth", you would have written it. Like a ideologically driven and uncritical thinker, You Know The Truth! You are the modern thought of today. Not that you have to mention what that modern thought is, since obviously, you already possess it.

I could sit here and explain to you how none of the above post says GPL is a non-coercive agent. Liberty can never be non-coercive, and despite claims of otherwhise in this discussion, none has provided an example of a liberty that can be enforced non-coercivly. Liberty has to employ coercion, or liberty is just empty word with no meaning.

Re: Emacs Lisp's Future

#158

Post by mark_l_watson »

mjn wrote: post #88
mark_l_watson wrote: post #76

Earlier quoted context omitted.

Are you sure that Richard Stallman does not like Common Lisp? Several years ago he asked me about the possibility of my releasing my out of print Common Lisp book (published by Springer-Verlag) under the GNU documentation license. I would have liked to do that but I couldn't find my manuscript word processing files.

I found some of the messages I was thinking of (this stuff is scattered across many years of debates, so there are probably others). Clisp maintainer on how loading Elisp into clisp was a weekend's work (2002, but talking about work from "a couple of years ago"): https://lists.gnu.org/archive/html/emacs-devel/2002-08/msg00... Stallman arguing "Common Lisp is extremely complicated and ugly" and "would bloat Emacs terr…

+1 thanks for those links. You are probably correct about Richard's view of Common Lisp.

Re: Emacs Lisp's Future

#159

Post by alloyed »

linguafranca wrote: post #120
wtbob wrote: post #118

Earlier quoted context omitted.

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

Feel free to tell me if I'm reading this wrong, but we're talking about Lua as a platform for re-implementing elisp, not as a replacement (completely ditching elisp is a non-starter for obvious reasons). And not having dynamic binding, no native support for the full numeric tower, not having a native list type, etc. would be serious road blocks for running elisp on the Lua VM that aren't there in Guile's case.

Re: Emacs Lisp's Future

#160

Post by rurban »

deng wrote: post #110
rurban wrote: post #74

Earlier quoted context omitted.

That's why I believe their FFI plans are doomed. We implemented FFI's for emacs over the last decades, but RMS always strongly opposed it, because you could call windows DLL's then. gtk-emacs e.g.

RMS is fine with an FFI as long as you cannot use it to inject non-free code. This is usually done by requiring an exported symbol saying that the code is GPL compatible. GCC does it this way: https://gcc.gnu.org/onlinedocs/gccint/Plugin-API.html

But you cannot call that a FFI then. A FFI is the abbrevation for "Foreign Function Interface", not "Friendly Function Interface". FFI's are not sugar coated.
Post reply on HN