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.
Even in the current pre-alpha/alpha stage of Guile-Emacs, I can launch a thread from Scheme, do work, return to the main thread, then call an Elisp function on my result. (Scheme and Elisp data types are unified.) No bugs or unpleasant details there.
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.)
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/process based concurrency. Guile, Clojure, Common Lisp or whatever language are going to basically restart Emacs from scratch, no matter how well they're coated with compatibility macros.
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.
As a programming language aficionado, I get really excited by the idea of Guile-Emacs. Yet I couldn't agree more with what you just said. Breaking Emacs Lisp would be a disaster, evolving it slowly to add support for the desired features seems a much more reasonable choice. Not only on the side of package maintainers but also on emacs developer's: at least any effort is worthwhile, since it will be a little step of improvement on actual Emacs rather than starting or continuing a project which has more chance to be abandoned at some point than to merge into the main Emacs branch.
If I was them, I'd gradually introduce the minimum set of breaking changes to ELisp that converge it on Common Lisp. Even if those changes were unhelpful or removed features. Then eventually, when it maps 1:1 onto a subset of CL, just swap the implementation for a supported CL.
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 a general VM with custom infrastructure to support both Scheme and Elisp is not really a more clean, minimalistic infrastructure anyway. The semantics of Elisp/Scheme are too different to be able to just stick in a Scheme implementation with a smallish compatibility layer, like you could with Elisp hosted on CL.
>Guile as a general VM with custom infrastructure to support both Scheme and Elisp is not really a more clean, minimalistic infrastructure anyway
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.
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.
If he made the opposite call, and adopted CLisp, you'd be complaining about him anyway, in a thread about some unexpected compatibility problem or whatever.
Uh, no. Common Lisp is sensible. It's multi-implementation and several of the implementations are JVM levels of fast, while others are highly portable. There's a community, standards, and libraries. It's not where the froth of lisp experimentation is happening, but it's effective and a known quantity.
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:
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.
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.
> 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).
Right. Javascript used to be slow, but instead of bemoaning how slow it was and thinking maybe they should change languages, people made Javascript fast. If it can be done with Javascript, why not Elisp?
Because Javascript has huge players like Google, Microsoft and Mozilla behind it that throw insane ressources at it to compete for performance, whereas EMacs is fast enough for most of its users and has no big companies interested in its performance.
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...
I think emacs lisp is a great extension language. There's not much syntax, and it has the important functionality baked in. IMO anyone that says they don't use Emacs because they don't like Lisp is someone that would not use Emacs no matter what.
Guile-Emacs is not a rework, it's a rebase. It already runs all Elisp, sans bugs and (currently severe) performance regressions. It will be a nearly-drop-in replacement, a new version of GNU Emacs, even less different from it than XEmacs. In general, it will only add to Emacs, and change the underlying implementation of Elisp.
Agreed. This is busy work. If emacs were a pay for commercial product then this wouldn't be considered because emacs is still proving itself economically viable.
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.
I started a project to port Emacs (the C parts) manually to Clojure, with the Emacs Lisp automatically transpiled into Clojure in 2012, most of the work was done in early 2013: https://github.com/hraberg/deuce
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.
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 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.
> 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.
If emacs supported new languages other than elisp, a lot of new blood will join the community. Once we get the new hackers, they will try and find ways to modify the old codebase. Emacs is a wonderful editor, but to a newcomer it can be a lot daunting.
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.
You don't need to read the manual, or even any tutorials, IMO, as long as you know that function application in Lisp looks like (f arg1 ...), know how to program, know that Lisp has macros, almost everything else follows.
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.
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 turning it into a Frankenstein monster.
> 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.
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.
> 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.
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.
But if you run Emacs 24.4 in your browser, you could eww - the brand new browser written purely in elisp - to finally get some sane browsing experience.
(of course you can do that without running Emacs in the browser, just run it normally)
Can you write a plugin for Kate with Kate's own built-in development language and have it running immediately without having to go through a separate edit-compile-debug cycle using a different development toolset?
Shouldn't it also use webkit or something for rendering?
So.. change the rendering, change the language... shouldn't we just write more editors from zero?
So is BT Templeton, the person who has been hacking away at Guile-Emacs GSoC after GSoC. :-)
(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.
The decision to go either Common Lisp or Scheme was made based on RMS very personal reasons and conflicts with close-source Lisp machine companies during the first half of the 80s.
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.
My (potentially misunderstood) interpretation of why ELisp exists is due to the fact that Scheme was unsuitable because it's lexically scoped (which was potentially less efficient). The dynamic scope of ELisp is advantageous for things like temporary mode mapping changes, buffer local variables, etc (See: https://www.gnu.org/software/emacs/emacs-paper.html#SEC17).
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?
> 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.
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.
hmm... from reading this I feel like I'm in the minority but I think I'd prefer scheme to CL (I have to emphatically agree that thinking of a javascript-emacs makes me shudder).
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.
> I feel like I'm in the minority but I think I'd prefer scheme to CL
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.
I've been programming with ELisp, CL and Scheme for a long time. Somehow Guile feels like an odd choice. Why not Chicken scheme, or Racket, or Bigloo; which are the top scheme environments you can choose from?
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:
Guile was designed as an extension language, which CL was not. So, that's one reason. Guile also has a something like 90% working implementation of an elisp compiler to guile bytecode, a JavaScript implementation and (I think, though may be wrong) a working Lua compiler. None of the other mentioned scheme implementations were designed for embedding, even if they are fine implementations themselves (which they are).
If we consider "designed for embedding" as a driving point we can always take ECL (embeddable/extensible common lisp) as a base and get both very nice ffi and threading while still being 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.
People seem to think that moving to Guile means moving to Scheme. It does not. It means that Elisp will run on Guile's VM, which will bring many practical advantages. Emacs will not be switching to Scheme. Elisp will still be used and the Elisp language can continue to be developed.
Can you explain more what FFI support would give? I understand that Emacs is a C+Lisp system. Is it about calling other languages from Elisp easier? Or possible at all?
This problem begs to think larger. Instead of starting with "we are missing these two critical features that the rest of the world has expected as standard since the dinosaurs perished", it might be interesting to ask "what sort of emacs language features would make it the best in the world!"
It is far easier to get a minimum product out when the eventual goal is the stars.
As I began really using Emacs about a year ago, I got the idea that the Emacs code base could actually be a foundation for a computer science curriculum - The Emacs code base touches on scripting, functional programming, application programming, systems programming in C, real-time problems, usability, cross-platform development, etc. etc.
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.
The fact that he even uses the term "adversaries" in this post is disheartening. It's really disappointing that someone who could potentially be such a force for good in the world gets derailed by what is basically tribalism.
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.
> 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.
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.
Standard response: rms has probably done more for free software than anyone else in the world. We should be glad at least someone has such uncompromising idealism. Even if it's annoying and inconvenient from time to time.
> 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.
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.
I don't see how he is demonizing anyone by calling them adversaries, the word "adversary" doesn't imply any evil at all, you really are just talking from your personal ego.
What you are calling for is Argument to moderation[1]. Its a common fallacy, which asserts that the truth can be found as a compromise between two opposite positions. Working towards a goal without compromise with those who actively make that goal harder is not wrong.
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.
Well, it can if you use the GPL on the sum product. :-)
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.
> 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.
Nope, that's open source. Free software means that and other freedoms.
Yep, I'm simplifying since I'm talking about BSD vs GPL and not the philosophical differences of "Open Source" vs "Free Software". What I said was correct in that context.
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 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 must enable those who want to add restriction to the BSD product, then they can't use GPL licensed code.
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.
Regarding freedom GPL is superior to BSD. Look what happened to OSX. It was taken from BSD but the former BSD developers have no control over OSX at all. They even have to pay for their own work when they purchase some OSX or iOS thing.
> 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 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.
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.
> 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.
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 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.
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.
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 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.
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.
> 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.
> 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 -> user
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.
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.
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 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.
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.
> 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.
> 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.
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).
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?
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.
Now you have two problems. Instead of a Lisp runtime in C, the runtime is moved experimentally to LLVM. This solves not the problem to modernize the Lisp runtime (concurrency, better compiler, ...).
It's certainly more complex, but I think could offer substantially more bang for the volunteer 'buck', as it were.
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? :-)
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.
You may be in the minority in terms of the total number of users, but most of the Emacs developers will have the same mindset. Terminal-friendliness is a part of Emacs tradition. The developers would surely keep the ability to run Emacs in a terminal.
With adequate separation of concerns the backend could either be V as full Dom or as a terminal friendly minimal DOM (no css fonts attributes, pixel positioning, box shading etc).
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.
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.
Why not start with Hemlock or CLIMacs atop a CLIM implementation, or take the (MIT-licensed) ZWEI codebase and bring that forward? Is there really all that much in GNU emacs that is really widely used?
Starting with ZWEI, written in Lisp Machine Lisp in the late 70s, is a very cool way forward. Move back to the 70s and start from there. Good idea. Maybe not.
> Why not start with Hemlock or CLIMacs atop a CLIM implementation,
ZWEI (and ZMAIL) isn't Common Lisp, Kent Pitman worked on creating a set of diffs to it to make it compile in CL but I don't think they are freely available.
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).
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?
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.
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.
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).
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.
>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.
Sure the problem defaults to the package maintainer, but historically popular and/or useful packages have seen their way into the main GNU distribution. Just leaving the possibility open has some long-term consequences for the project.
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.
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.)
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 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 code is Lisp in Lua…).
> 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-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.
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.
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.
One option is to have both Lua and Elisp, so that packages can be slowly migrated. Lua is small (so it doesn't incur a huge size cost to have 2 engines), fast (one reason why they want to switch, according to the author), and has a significantly large community. It also has coroutines, which is not what people dream of when people talk about concurrency but is probably good enough for a text editor (and avoids most sync problems). Furthermore, with this "dual-engine" strategy it would be a bad idea to choose a language similar to ELisp: it would cause a lot of confusion.
But I guess that Emacs on Lua wouldn't be Emacs anymore. That's the main objection.
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.