Emacs Lisp's Future
lists.gnu.org
lists.gnu.org
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 topic, something that I have written before about: think forwards several hundred years. What will the software landscape look like? My bet is that there will be many ancient software systems that have been debugged to near absolute stability over the centuries. Sure new software will be written, but I bet there will be many very old and stable systems that will see little change.
Lots of people have written excellent code for GNU Emacs, but the implementation runtime hasn't improved that much.
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?
Calling Elisp functions and accessing Emacs data types (buffers, windows) from multiple threads is another issue; if you don't want to bother with it then don't; you still get all the other benefits of being on Guile. (Calling to any Guile module agnostically as if it were an Elisp library (including, say, Guile's OpenGL module), having an FFI, getting JIT or AOT native compilation in the future, etc.)
It's better to create slight incompatibilities gradually (so that packages can catch up in some humane timeframe). I could imagine the ELisp runtime being intertwined with the Emacs C code badly enough that making radical changes to it would seem "impossible", just like in the CPython codebase it is considered impossible to ditch GIL and modernise the code. But those kind of comments are often excuses because people are lazy and it's nicer to write new code.
Considering how intricately it is integrated into a lot of people's lives this is silly.
It's fine sitting on a an academic pedestal but some of us have to live in the real world.
Also I'm not sure how the maintainer failed to address your suggestion as it seems the most logical... which makes me worry this is an academic exercise.
Besides the point... almost nothing will be achieved by making elsip faster. I sometimes write macros to work on GBs of files and yes, it isn't fast... but if i cared about speed i'd be shelling out to cli tools to do the work anyway.
Makes. No. Sense.
Fork it if you must and leave the rest of us alone.
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)
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.
It gets tiresome even to watch.
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.
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 terribly" (2010): https://lists.gnu.org/archive/html/emacs-devel/2010-04/msg00...
Guile is already a general VM meant to support many different languages, not only Scheme. I think it's a very clean solution to use Guile's efficient VM, and I don't think minimalistic is a useful criterion.
Of course there'd be no point if emacs were fast enough, but there seems to be a significant number of people who feel it's not.
That's not really true, is it though? Scheme '(), #f and so forth...
>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.
> It's not a 100% drop-in replacement, that's true…(eq foo t) should always work. (eq foo nil) will only work if that `nil' came from Elisp code; if it's a Scheme #f or '() in disguise, then you need to make that (not foo) or (null foo) (both works in both cases); anything but (eq foo nil).
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...
It can boot Emacs on the JVM and take simple commands, but not much more. It's my intention to eventually revisit this project, but not sure when.
Cool -- my '90s hacks are in demand! I added threading support to Guile and wrote libffi back in the 90s.
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 a live Lisp image with text-editing features bolted on top. It's basically backwards of how a typical editor/IDE is implemented.
Therefore, it matters what language is used as a base. People mentioned Lua or JavaScript, but they are nowhere near useful enough for the task.
Therefore, it feels to me - and I believe to many other Emacs users as well - it matters that there should be one base language. Emacs as an Elisp system with text editing capabilities feels like a whole. Everything fits together nicely and interacts with each other. It is elegant. Aside for inviting maintenance upkeep and general chaos, making Emacs "run" multiple languages at the core is sort of like shattering its soul into many pieces. I don't want to have an editor with multiple-personality disorder.
Imagine you're writing an executable in three different programming languages mixed together at the same time. That class is written in Common Lisp, but it's child classes are written in C++. And exception handling everywhere is written in Python.
The sheer mental effort to make all of these work in a conceptual harmony inside a single program would be enormous. And it would still feel weird.
That is what multiple-extension-language Emacs would feel.
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.
For example, I have completed the emacs tutorial, I've even read the infos info tutorial and several info pages regarding emacs and still don't know much about ELisp. I downloaded the official emacs manual, which is more than 1000 pdf pages and plan to read it in the next 10 years.
I love the editor, I want to continue to program in Emacs but Kate seems to be much simpler, elegant and quite functional.
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 turning it into a Frankenstein monster.
While I agree with most of your statement, having Emacs switch/transition/support another, more modern form of Lisp like CL surely wouldn't count as selling your soul.
On the contrary you would stay true to your ideals (a Lisp-runtime with an editor) except now the Lisp runtime just got a lot better.
I like Emacs as much as the next guy, and I have dabbled some in Elisp. I can make due. But I sure as hell wouldn't mind getting some of that neat stuff the CL-guys are getting.
I... I'm not sure, but I'm leaning towards agreeing. I can tell you that I don't get those "we're lobotomizing it" vibes when I think about switching Elisp for CL. Maybe because those two look alike and have similar philosophy. But even a thought of switching to Scheme, which is still a Lisp, sends chills down my spine.
I know, this is completely irrational. But maybe this is a part of Emacs's appeal. You get attached to it, down to its very core.
(of course you can do that without running Emacs in the browser, just run it normally)
It took me a few hours to learn enough Elisp to customize .emacs, add custom macros, and start using defadvice to wrap existing commands with extra behaviour, like preserving the selection for text replacement in a selected block. I even went as far as writing a macro that could use defadvice to generically preserve the selection for any other command on the second day of using emacs.
A bigger hurdle was learning the Lisp jargon, so that I could find the correct function to call when searching for it, whether in emacs itself, or online. But once I knew about the point, that the selection is called the region and is the text between mark and point, that files are called buffers, that open is called find, etc., it was pretty smooth sailing.
It's fairly trivial to find the source for an arbitrary elisp function - just C-h f <function-name>, and follow the source link. Plugins like helm (dynamically filtered list searches) make it very easy to find relevant functions too.
Elisp has a couple of features that make it work well as an application extension language: dynamic variable scope and function advice are two that are fairly unique to Lisp (technically, Javascript has dynamic scope via the eval function, but it's not usually a good idea to use it). These things make it easy to tweak behaviour from the outside.
However, contra other people's opinions, Elisp is not fast. It is slow, very very slow, compared to efficient languages. My startup time is just about tolerable on a modern machine, but not tolerable enough to stop me starting emacs --daemon every time I reboot. Scrolling through large files with line numbers enabled is slow, and the UI has a few milliseconds of lag for almost every non-trivial action. Dynamic searches need very noticeable debounce delays for list refreshes or otherwise things get unresponsive.
I couldn't find any progress report after http://tromey.com/blog/?p=751 so I guess the project has been abandoned early.
(They seem very skilled, don't be fooled by the fact that it's GSoC; no idea what the skill level of people who take part in that usually tends to be.)
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.
GNU has had two common Lisp implementations under their umbrella at least since mid 90s (CLISP (of Viaweb fame) and GCL (of Maxima fame)), but due to RMS' hate of Symbolics and Common Lisp, all of the effort was invested into making Guile run properly (which took them 25 years and still nobody is using it) and the two Lisps were basically orphaned.
The latest effort of guile-ifying Emacs is more pushed by the Guile guys, in order to attach themselves to an already existing killer app (emacs) and to basically force more and more people to use Scheme, because nobody is doing it voluntarily.
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.
Of course the proper way would be to go Common Lisp. Elisp is and has always been a subset of Common Lisp, and they've had a Common Lisp compatibility layer for decades, and a lot of packages use it. The problem is simply highly political. You'd have to confront RMS, and you'd have to finally get rid of Guile's "official GNU extension language" status.
We can dream.
AFAIK, Guile is not used much beyond a few random projects. Maybe I just don't know Guile, really. Maybe it has a decent implementation afterall.
However, I would have gone CL. There are several "emacs-like" editors implemented in CL:
I would argue that implementing ELisp support in Climacs is actually easier, so we can run all the elisp stuff we already have, and slowly move on.
Scheme of course provides `fluid-let` and Common Lisp also allows for dynamic binding
> all of the effort was invested into making Guile run properly (which took them 25 years and still nobody is using it)
I think the first release of Guile was in 1995... Did I misinterpret your point?
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 like proposing to sell its very soul. A Guile-powered Emacs would feel... weird (the it-walks-and-talks-but-when-you-look-into-the-eyes-there's-noone-home p-zombie kind of weird) (and don't get me started on ideas like "let's script Emacs in Javascript", like Emacs was a scriptable editor like the others...).
Strangely, I get less of this feeling with Common Lisp, maybe since Elisp is closer to CL than it is to Scheme.
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 the most elegant implementation.
Full disclosure, I don't know too much about Common Lisp so if anyone wants to point out some ways in which it is more elegant than scheme it'd be much appreciated.
Yeah, I don't get it either. Either is fine with me, though I prefer Scheme to elisp or common lisp. Scheme feels cleaner to me but I don't think I really care except that you need a good implementation of either.
Scheme is really cool; I like it. But I use CL:-)
Guile-Emacs runs Elisp, not Scheme, and Elisp will remain the main Emacs language for a long time. Using Scheme will become a possibility and you can bet on some people starting it immediately, but nobody is forced.
Guilifying Emacs is not "pushed by the Guile guys," it's always been RMS's desire.
The "Emacs guys" is a rather large group of people, which is essentially a superset of "Guile guys." Some of them would love Scheme, others wish it was CL instead, others want to take Elisp on its own path to evolution. Guile offers an evolved Elisp, and Scheme as an addition. And of course One Day someone might sit down and implement CL for Guile too, you never know.
GCC, GDB, GNU Make, and some other tools can be extended in Guile. The Nix-derived package manager Guix which forms the core of the upcoming official GNU distribution is also written in Guile. It's becoming quite "relevant" on its own terms. But sure, Emacs would be a huge boost. They're both GNU software so it's a logical come-together if you ask me.
It is far easier to get a minimum product out when the eventual goal is the stars.
An alliance with Racket would be an interesting option from the standpoint of language communities.
- The community's core is [ relatively ] vibrant.
- The community has more than a passing interest in
developing development tools.
- The community is exceptionally stable because
its members are often linked to academia.
- It copes with endless September really well.
- Its vision of open resources overlaps GNU
somewhat.
- Programming language problems are right up
the Racket community's alley.Two parties can disagree on 99% of their beliefs, yet still find ways to come together on the 1% that they happen to agree on. These parties can work together to each others' mutual benefit, and the world is better for it. But nooooooooo, not RMS. He has to demonize anyone who is not 100% in lockstep with him on everything, to everyone's detriment, and throw his "adversaries" into a trash bin labelled "Others".
It's a self-fulfilling prophecy. It's easy to drive people apart in the name of some ideal. It takes actual leadership to drive otherwise separate people together to actually accomplish something. I have wished for so many years that RMS would care enough to provide the latter instead of the usual former.
Right there is the crux of the matter. RMS is only focused on the ideal. To him, "accomplishing something" is only relevant when the accomplishment is free software that can't be locked away in proprietary codebases.
Viewed through that lens, his actions and beliefs have been remarkably consistent for the past 30 years.
He really grates on people who don't share his idealism, and he's looked up to by people who do. He can be quite polarizing, to say the least.
The thing is that RMS doesn't want to accomplish something in the generic sense, he wants to accomplish something in the specific sense (and that something is "reduce, and ideally eliminate, the production and distribution of non-free software").
People get frustrated that RMS's actions are incompatible with the specific things they want to acheive, which are often superficially similar goals to RMS's, but different -- very commonly, something like "promote the continued development and distribution of free software", either in general or some particular piece of free software.
This isn't really so much ideology getting in the way of shared goals -- its not that RMS lets his ideals for means get in the way of achieving shared goals -- its a fundamental conflict of goals preventing cooperation.
When I have seen RMS labelled people as the "Others", it been when someone has done actions that is direct detriment to free software. If your goal is to build something, and someone else comes with a hammer and start tearing it down, I will give you some permission to be annoyed.
Still, I'm not really sure that it's very ironic, since his main beef is companies taking open source code and delivering closed source proprietary binaries to their end users. The whole GNU philosophy is about being guaranteeing that end users (or agents acting on behalf of end users) can always have source code with their binaries. BSD doesn't give you that guarantee. GPL does.
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 would abuse the license in order to add restriction is.
Thus, BSD products can use GPL code, but they can't enable those who want to add restriction to the BSD product.
If they don't care about enabling proprietary model for the product, then they can just continue license their code as BSD and combine that with the GPL licensed code. Distributors will have to abide to both licenses, but that is not a problem so long they do not try start a proprietary model or tries enable other to do it.
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 models originate from the age of printing presses, and this legal arrangement is not conducive to free collaboration and improvements of the works in question, as is the expected norm in, for example, science. Some people who are, for this reason, opposed to this arrangement, noted that this arrangement is, incidentally but necessarily, giving the authors quite a lot of power, and so they constructed the GPL. The GPL is a specific use to which authors can, if they wish, put these powers they have been granted. The GPL is meant to enable the above-mentioned collaborations and improvements without having any other deleterious effects, like making the authors feel like they are being (or could be) exploited. It is quite ingenious, since if you deny the right of authors to apply the GPL, you deny the rights given them by the legal arrangement of copyright.
The specific way in which the GPL preserves your freedom depends on the work in question and your role in the situation. As a recipient of a work to which the author(s) have given you a license to use the freedoms granted by the GPL, you are permitted to do many things which would otherwise have been forbidden by copyright law. An an author, the GPL does not make you any more free (since copyright law already gives you absolute power), but the GPL is a tool which you can use to ensure that all users of your works are permitted to collaborate on and improve the work further, which might give you the incentive to produce and release more works.
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" and citing cases of drunk driving and alcoholism as examples of this. And then narrowly defining "healthy" narrowly to include only lifestyles where no alcohol is consumed. Then completely ignoring and even actively working against all the ways in which alcohol can be healthy (and even healthier than no alcohol at all) because it doesn't fit into the narrow definition of "healthy".
So when somebody says "remind me how the GNU Public Health Handbook keeps me healthy", when it's brought up that moderate alcohol consumption can increase various health factors and longevity...in other words that alcohol consumption can be "compatible" with health...it's the same kind of scenario here.
The GPL's fixation with its specific ideological pure and completely arbitrary definition of "freedom" does not represent all kinds of freedom and that it purports to represent some kind of maximal freedom state is highly disingenuous at best and outright lying at worst. There are certain exercises of freedom that provide for better outcomes within certain criteria than anything the GPL offers and without certain deleterious effects that come from the GPL. But the GPL philosophy either acts like those shouldn't exist or are evil. And I find that highly spurious.
There is no such thing as consequence-free freedom. There's always a trade-off of some kind. The GPL is a fiction that comes from a fantasy that this isn't the case and just like any philosophy that relies on ideological purity conveniently ignores the cases where the ideology has negative consequences.
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.
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.
When someone is given freedom of speach, it means restricting those who would want to stop your speach. When someone is talking about freedom from slavery, it means the restrictions of those who want to enslave others. Liberty as a concept thus do not address those who want to act onto others, but those who would be acted onto.
GPL prevent distributors from using copyright law to coerce a third party. Those distributors who want to use copyright for coercion is prevented, and the police will enforce it.
Sure, "enforce" implies "coercion".
That doesn't imply that coercion is the only way to acheive liberty.
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.
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 enlightenment thought on freedom, when the modern thought on the matter has come a long way since then and to anybody who seriously studies all of the eras of liberal thinking, the GPL is not a particularly interesting or conforming philosophy.
It parallels totalitarian philosophies far more easily than any democratic of liberal thinking on the matter. A country based around the kind of self-perpetuation at all costs kind of philosophy the GPL is built around would be a dystopia.
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.
> 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.
> "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
programmer -> derivative work programmer -> packager -> user
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.
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 fit.
That is entirely correct.
What I disagree with (a little bit) is this
> The GPL, on the other hand, tries to preserve the freedom all the way to the end user.
The GPL tries to preserve a particular kind of freedom through the chain -- and that kind of freedom is rather narrow, even if it does try to guarantee self-perpetuity. But it completely tramples all others -- especially v3, which does so with prejudice. This is consistently what my point is in this thread.
I'm not sure I understand where any disagreement on this definition lies. You even agree that the GPL is not maximal and only guarantees a subset of the freedoms a notional maximal license grants "it gives anyone in the chain the 'freedom' to...<do whatever>".
But you'll see by all the downvotes here that a discussion of the merits and drawbacks of the GPL is virtually impossible -- because "freedom".
> 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. The notional maximal license believes all freedoms are equally valid and does not enforce one particular freedom at the expense of others.
And to be clear, I'm not advocating for the notional maximal license. It has obvious shortcomings and also protects many kinds of objectively negative freedoms (the right to profit from other people's labor without their consent, etc.). 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.
I'm also not saying the GPL is bad, it is what it is. It's resulted in a lot of good in the world and some bad. But again, it is what it is, it's not a tool for ensuring the most possible freedom.
> No, not really—it's not applicable to the situation at all. (A) The GPL isn't itself software...
Actually it is. The GPL can be used on non-software items. Not GPLing the license itself does nothing to prevent the proliferation of licenses. There are already hundreds of incompatible licenses. Not GPLing the GPL I think is shortsighted. If the original vanilla GPL licenses are the best, people will use them regardless of the derivatives and alternatives, if they aren't then they'll use something else, even if it's an incompatible derivative.
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.
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.
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.
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?
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.
Much of the problem is already working and actively being developed and hardened against a variety of applications. The runtime system and JIT in particular. Also some existing work in functional languages using LLVM, including lisp.
But RMS has already shot me down on the licensing issue. I'm suggesting dotGNU next. If you can't directly leverage a big project, why not feed off its good ideas in a clone? :-)
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.
In my Emacs days, I've never really used the terminal version. Multiple frames, yay!
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.
> Why not start with Hemlock or CLIMacs atop a CLIM implementation,
Why?
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).
Then I spent about 5-10 years using that platform as my IDE.
Guess what... Last year I migrated to IntelliJ IDEA and won't EVER migrate back. It's kind of sad... but IDEA is insanely awesome by comparison.
On a more serious note, could you elaborate a bit on how IDEA is "insanely awesome" compared to Emacs? What do you find more useful/enjoyable in the IntelliJ IDE?
is he the main emacs maintainer? in other words, how seriously should we consider this email?
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.
(require 'cl-lib)
(cl-defun foo (&key a b c) (list a b c))
(foo :c 3 :b 4 :a 1)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).
;; 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
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.
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.
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.
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.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.)
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.
[1]: https://github.com/neovim/neovim/wiki/FAQ#lua-and-vimscript-...
But I guess that Emacs on Lua wouldn't be Emacs anymore. That's the main objection.
- 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…).
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.