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).
Emacs Lisp's Future
81–90 of 160 posts
Re: Emacs Lisp's Future
#82Earlier quoted context omitted.
Remind me again how the GPL preserves my freedom.
> 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…
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.
Re: Emacs Lisp's Future
#83Earlier quoted context omitted.
Does emacs want the kind of developers who cannot be bothered to learn Elisp? Apart from the syntax, Javascript and Lisp are not really so different.
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 t…
Re: Emacs Lisp's Future
#84An 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.Re: Emacs Lisp's Future
#85I sent a note about using an elisp-on-llvm solution. Someone had done the work already, it appears: https://github.com/boostpro/emacs-llvm-jit
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, ...).
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? :-)
Re: Emacs Lisp's Future
#86Earlier quoted context omitted.
There's no way they'd do that. There's a rift because of LLVM's licensing philosophy: https://gcc.gnu.org/ml/gcc/2014-01/msg00247.html
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 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.
Re: Emacs Lisp's Future
#87Re: Emacs Lisp's Future
#88Earlier quoted context omitted.
Some years ago the a clisp maintainer actually made a minimal demo of Emacs hosted on clisp with just a compatibility layer for Elisp via macros/functions, which seemed to work pretty well. But it didn't progress any further because Stallman vetoed basing Emacs on Common Lisp (he considers CL to be too big a language, and to some extent just doesn't like it). In retrospect I'm not sure this was a good call: Guile as…
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.
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...
Re: Emacs Lisp's Future
#89Earlier quoted context omitted.
Too often it seems RMS is why GNU can't have nice things.
RMS would never let practicality get in the way of ideology. The GNU/RMS is best because you're free! (As long as your computing needs are a text editor, compiler, and some unix system utils)
Re: Emacs Lisp's Future
#90Seriously, why not just use Lua? It's perfect for this.