Live data from Hacker News

Emacs Lisp's Future

lists.gnu.org

81–90 of 160 posts

Re: Emacs Lisp's Future

#81

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 isn't an Elisp interpreter/compiler.

Re: Emacs Lisp's Future

#82
post #21
post #18

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

> without having any other deleterious effects

And I guess that's the problem isn't it? It does have deleterious effects, but within the narrow definition of "freedom" the GPL uses, those effects are unimportant/ignored. The long-term vision of the GPL does provide a kind of "freedom" along it's specific definition, but strongly denies all other kinds along the way.

It's like saying "drinking alcohol is unhealthy" 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

#83
post #37

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

On the other hand, if you write Elisp in JS, you can run Emacs in the browser.

Re: Emacs Lisp's Future

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

Re: Emacs Lisp's Future

#85
post #23

I 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, ...).

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

Re: Emacs Lisp's Future

#86
post #11

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

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

Re: Emacs Lisp's Future

#88
post #50

Earlier quoted context omitted.

Some years ago the a clisp maintainer actually made a minimal demo of Emacs hosted on clisp with just a compatibility layer for Elisp via macros/functions, which seemed to work pretty well. But it didn't progress any further because Stallman vetoed basing Emacs on Common Lisp (he considers CL to be too big a language, and to some extent just doesn't like it). In retrospect I'm not sure this was a good call: Guile as…

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.

I found some of the messages I was thinking of (this stuff is scattered across many years of debates, so there are probably others).

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

#89
post #59

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

[deleted]
Post reply on HN