Emacs Lisp's Future • Hacker News Board

Re: Emacs Lisp's Future

#131

Post by dragonwriter » Wed, Sep 17, 2014, 7:06 PM UTC

belorn wrote: post #130

dragonwriter wrote: post #93

Earlier quoted context omitted.

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

In order to enforce any liberty, coercion is the only way available to do so. Its an paradoxical aspect of liberty which exist when ever one try to enable liberty. A typical example is how the police is allowed to use physical violence, fines and imprisonment in order to enable liberty from violence, theft and enslavement. When someone is given freedom of speach, it means restricting those who would want to stop your…

> In order to enforce any liberty, coercion is the only way available to do so.

Sure, "enforce" implies "coercion".

That doesn't imply that coercion is the only way to acheive liberty.

Re: Emacs Lisp's Future

#132

Post by __david__ » Wed, Sep 17, 2014, 7:15 PM UTC

bane wrote: post #122

__david__ wrote: post #115

Earlier quoted context omitted.

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

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 the greatest possible expression of one particular kind of freedom, and it does so at the expense of others.

Yes, I suppose I'm not really counting negative freedoms as freedom (since negative freedoms tend to take away freedom from others, or cause others harm). So from my perspective, the GPL takes away a bunch of negative freedoms as the cost of bestowing positive freedoms. That seems more maximally free (in the positive sense) to me than something that mixes a bunch of negative freedoms in, where the negative freedoms are allowed to cancel the positive ones.

> > It really comes down to whether you believe that you (the end-user) should have the fundamental right to tinker with...

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

Re: Emacs Lisp's Future

#133

Post by belorn » Wed, Sep 17, 2014, 7:18 PM UTC

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…

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.

But this is simply a confusion that defines freedom as "no rules". Freedom has a much broader definition, which is why I brought up how philosophers during the ages has defined it. To quote John Locke: "Thus, freedom is not as Sir Robert Filmer defines it: ‘A liberty for everyone to do what he likes, to live as he pleases, and not to be tied by any laws.’ Freedom is constrained by laws in both the state of nature and political society."

The argument you are making was discarded in the 17th century by the Father of Classical Liberalism. Calling those who disagree with you as ideologically driven and uncritical thinkers really do show who is right here, doesn't it?

Re: Emacs Lisp's Future

#134

Post by krylon » Wed, Sep 17, 2014, 7:18 PM UTC

thejdude wrote: post #103

josteink wrote: post #52

Earlier quoted context omitted.

Maybe I'm in the minority, but I for one really appreciate how Emacs can run in a terminal, over SSH, with almost no feature-degradation at all. Besides Emacs being a very nice programming (and programmable editor), this is one the key features which keeps me from even considering other more "modern" options.

I haven't used Emacs in a while, so I'm very rusty, but why would you run a remote Emacs in SSH, and not use your local Emacs to access remote stuff via TRAMP? In my Emacs days, I've never really used the terminal version. Multiple frames, yay!

On my remote systems, about the first thing I do after a reboot is call "emacs --daemon" via SSH and then use emacsclient to edit files. For one thing, TRAMP has higher latency, and it also keeps state across disconnects and reboots of my desktop system. I regulary have lots of configuration files open, tail-mode buffers to watch log files, an eshell session, man pages, web pages (using w3m), and it is just too much of a hassle to open these all over again all the time.

Also, if you have to access the remote machine through a low-bandwidth line, the terminal version at least feels more efficient than using TRAMP from my workstation. For most purposes, the GUI does not offer that much of an advantage.

Re: Emacs Lisp's Future

#135

Post by tjr » Wed, Sep 17, 2014, 7:28 PM UTC

systems wrote: post #126

who is Stefan Monnier? and why should we care about what he thinks? is he the main emacs maintainer? in other words, how seriously should we consider this email?

http://lists.gnu.org/archive/html/emacs-devel/2008-02/msg021...

Re: Emacs Lisp's Future

#136

Post by krylon » Wed, Sep 17, 2014, 7:33 PM UTC

sdegutis wrote: post #70

Seriously, why not just use Lua? It's perfect for this.

I one were to start from scratch, writing an emacs-like text editor by building it on top of a small programming language you can use for customizing and extending the editor, Lua would a great choice. Lua has only a tiny standard library, but in writing the core of the editor, you probably have to supply the equivalent functionality yourself, anyway.

But I do not see how you could bolt Lua on to GNU Emacs. You would have to start from scratch, and that would be a lot of work. And even then, there is the fact, that GNU Emacs is already well-established, has a very loyal user base and is - by and large - good enough, even great for most purposes, so even if you wrote LMacs or whatever one would call it, you would probably end up with, like, a dozen users or so. (IIRC the Zile project, a small emacs-like editor, has tried this, but I do not know how far they got with this.)

Re: Emacs Lisp's Future

#137

Post by belorn » Wed, Sep 17, 2014, 7:37 PM UTC

dragonwriter wrote: post #131

belorn wrote: post #130

Earlier quoted context omitted.

In order to enforce any liberty, coercion is the only way available to do so. Its an paradoxical aspect of liberty which exist when ever one try to enable liberty. A typical example is how the police is allowed to use physical violence, fines and imprisonment in order to enable liberty from violence, theft and enslavement. When someone is given freedom of speach, it means restricting those who would want to stop your…

> In order to enforce any liberty, coercion is the only way available to do so. Sure, "enforce" implies "coercion". That doesn't imply that coercion is the only way to acheive liberty.

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 prevented with coercion that employ violence, theft (fines), imprisonment, or social pressure. The later is simply violence that is psychological rather than of physical.

If you read up on the history of liberty, the definition of freedom, you will find that all this has been thought about a long time ago. The paradoxical nature of using coercion (laws) in order to have liberty is not a new insight.

Re: Emacs Lisp's Future

#138

Post by lispm » Wed, Sep 17, 2014, 8:05 PM UTC

TeMPOraL wrote: post #128

I've been bringing the following thought up inside various threads but I think it needs to be said in separate one, since I see many people here and elsewhere missing this about Emacs. Emacs is not a scriptable editor . You don't "script it" or "write plugins for it" in a classical sense of those terms. You reprogram, extend and augment a piece of running code on the fly. Seems similar, but feels different. Emacs is…

> It's basically backwards of how a typical editor/IDE is implemented.

The main difference is that the implementation language is a dynamic language, which is also mostly the implementation language.

That's similar to how some other IDEs work like Smalltalk or Clozure CL on the Mac. But those are not focused on implementing an extensible editor. Those are IDEs with editing features.

Re: Emacs Lisp's Future

#139

Post by webnrrd2k » Wed, Sep 17, 2014, 8:10 PM UTC

e40 wrote: post #112

lispm wrote: post #95

Earlier quoted context omitted.

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?

But, over the centuries, it will get debugged to near absolute stability.

Re: Emacs Lisp's Future

#140

Post by tedks » Wed, Sep 17, 2014, 9:11 PM UTC

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.

I think it's largely a cultural objection, and one I feel is pretty valid. I would hate to see Emacs turned into a javascript playground.