Emacs Lisp's Future • Hacker News Board

Re: Emacs Lisp's Future

#101

Post by bane » Wed, Sep 17, 2014, 4:05 PM UTC

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

> 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 many exercises of freedom while using a coercive license to enforce community contribution and attribution.

I'm specifically not saying that other legal agreements provide more freedom or even different freedoms, only that the GPL doesn't provide the maximal sort of freedom it ideologically espouses. It's so obvious that the purpose of the GPLv3 was specifically to remove freedoms that people had been enjoying when using the GPLv2.

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

Now go through the thought experiment and start enumerating the ways in which any of the GPL licenses erode an objectively maximally free license. Each one of those things that you can't do under the GPL is a specific freedom that is removed.

This is probably a good place to mention that the GPL licenses are specifically protected by copyright held and enforced by the FSF. You aren't even free to copy the license itself!

I'm specifically not saying this is a bad thing or a good thing. But I am saying that this is a reality that is not ideologically recognized by the FSF and ideologically aligned people. The GPL licenses are very clever hacks on the legal system. But they are not the standards of freedom people should probably be following.

This isn't something that's hard to understand, but downvotes above show that this is something that's hard to digest by ideologically driven HN members.

If the GPL has had one success over all others, it has been turning copyright law and legal licensing schemes into a religion promulgated by uncritically thinking followers.

Re: Emacs Lisp's Future

#102

Post by Jtsummers » Wed, Sep 17, 2014, 4:06 PM UTC

riffraff wrote: post #87

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

Another thing not mentioned by the other two responders. Scheme is a lisp-1 (single namespace), elisp and CL are both lisp-ns (multiple namespaces). This means that you can have a variable in CL or elisp that shares a name with a function or macro, but the same is not true in scheme.

  ;; valid elisp and cl, same result in each
  (defun foo (bar) (+ 1 bar))
  (defvar foo 4)
  (foo foo) ;; makes perfect sense in CL and elisp,
            ;; but none in scheme

  ;; syntactically valid scheme, won't work on the last line
  ;; which translates to (4 4) and so makes no semantic
  ;; sense.
  (define foo (bar) (+ 1 bar))
  (define foo 4)
  (foo foo) ;; will break in scheme because foo is now 4
            ;; and 4 can't be applied as a function

Barring issues with lexical versus dynamic scope and a few other things, a fair amount of elisp code and CL code will run in the other language (if you don't account for the differences it may still run, but the output will be different between the two languages). You can even (require 'cl) in elisp and have a decent amount of CL functionality added into your emacs instance.

Simple things like function and variable definitions have to be changed to get even basic code (like the above) to half-way work in scheme from elisp.

Re: Emacs Lisp's Future

#103

Post by thejdude » Wed, Sep 17, 2014, 4:26 PM UTC

josteink wrote: post #52

swah wrote: post #48

Dream: "Common Lisp/Guile, and a Chromium based rendering engine".

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!

Re: Emacs Lisp's Future

#104

Post by Blackthorn » Wed, Sep 17, 2014, 4:28 PM UTC

belorn wrote: post #34

Blackthorn wrote: post #15

Earlier quoted context omitted.

This is particularly funny because BSD code can be freely used in GPL'd products, but not the other way around.

If people could ensure that no one would restrict how others uses the program, having GPL'ed software released under BSD would not be an issue. A bsd project could simply add to the license that people should not use patents, legal threats, or hardware tricks in order to restrict people, and I would see that as equivalent as making the whole work under the GPL. The BSD license itself is not a problem, but people who…

BSD products cannot use GPL code without changing the entire license of the product. That means there is no way that BSD products can use GPL code.

Re: Emacs Lisp's Future

#105

Post by thejdude » Wed, Sep 17, 2014, 4:32 PM UTC

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)?

OTOH, Emacs isn't that accessible to many users, and its idiosynchrasies can be very offputting. I also quit Emacs after a while because I wasn't totally happy with it.

I think that's why there are so many attempts to built new extensible editors in other languages, like Eclipse, or that Ruby thing there once was (probably still is), or the Chromium/JS monster that was on HN recently.

I haven't yet found an editor I'm really happy with, so if I ever have time, I'll probably write my own as well. I'll lose the Emacs packages I don't use or even know about, but if you haven't bought into an existing ecosystem, that doesn't really matter. I'm unhappy enough with the existing systems that I don't mind throwing them away for something different.

Re: Emacs Lisp's Future

#106

Post by pnathan » Wed, Sep 17, 2014, 4:35 PM UTC

If we (emacs users) can have an emacs that has a "modern" backend & language but is bug-compatible with the extant elisp code, I think that would be grand.

Particularly nice would be thread support.

I'm pragmatically indifferent as to whether the backend is scheme or common lisp (I'd personally prefer Common Lisp, but whatevs).

Re: Emacs Lisp's Future

#107

Post by linguafranca » Wed, Sep 17, 2014, 4:37 PM UTC

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)?

Good point. But it's not unheard of to write a transpiler from Language X to Lua. See the VimL compiler in NeoVim[1].

[1]: https://github.com/neovim/neovim/wiki/FAQ#lua-and-vimscript-...

Re: Emacs Lisp's Future

#108

Post by deng » Wed, Sep 17, 2014, 4:39 PM UTC

JulianMorrison wrote: post #54

mjn wrote: post #50

Earlier quoted context omitted.

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…

Too often it seems RMS is why GNU can't have nice things.

You are aware though that without RMS we wouldn't have Emacs?

Re: Emacs Lisp's Future

#109

Post by derengel » Wed, Sep 17, 2014, 4:39 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!

Some people run their dev environments on remote linux machines (VPSs), it makes them OS agnostic, you just need a ssh client, while tramp is awesome, imo not using it gives you a faster and more streamline workflow.

Re: Emacs Lisp's Future

#110

Post by deng » Wed, Sep 17, 2014, 4:43 PM UTC

rurban wrote: post #74

fleitz wrote: post #59

Earlier quoted context omitted.

RMS would never let practicality get in the way of ideology. The GNU/RMS is best because you're free! (As long as your computing needs are a text editor, compiler, and some unix system utils)

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