Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Emacs Lisp's Future

lists.gnu.org

Post reply on HN
Print view View original

21–30 of 160 posts

Re: Emacs Lisp's Future

#21

Post by teddyh »

bane wrote: post #18
__david__ wrote: post #7

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

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

Re: Emacs Lisp's Future

#22

Post by rodgerd »

muuh-gnu wrote: post #10
Blackthorn wrote: post #9

Earlier quoted context omitted.

Literally dozens more. 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…

> and you'd have to finally get rid of Guile's "official GNU extension language" status.

We can dream.

Re: Emacs Lisp's Future

#23

Post by lispm »

lallysingh wrote: post #2

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

Re: Emacs Lisp's Future

#24

Post by lispm »

eschaton wrote: post #19

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,

Why?

Re: Emacs Lisp's Future

#25

Post by JetSpiegel »

__david__ wrote: post #17
Blackthorn wrote: post #15

Earlier quoted context omitted.

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

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

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

Re: Emacs Lisp's Future

#26

Post by easytiger »

yason wrote: post #8

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

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.

Re: Emacs Lisp's Future

#27

Post by __david__ »

JetSpiegel wrote: post #25
__david__ wrote: post #17

Earlier quoted context omitted.

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

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

Re: Emacs Lisp's Future

#28

Post by tenfingers »

muuh-gnu wrote: post #10
Blackthorn wrote: post #9

Earlier quoted context omitted.

Literally dozens more. 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…

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:

http://www.cliki.net/cl-emacs

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.

Re: Emacs Lisp's Future

#29

Post by apgwoz »

tenfingers wrote: post #28
muuh-gnu wrote: post #10

Earlier quoted context omitted.

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…

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" ed…

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

Re: Emacs Lisp's Future

#30

Post by terminalcommand »

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.

Post reply on HN