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

31–40 of 160 posts

Re: Emacs Lisp's Future

#31

Post by [deleted] »

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…

[deleted]

Re: Emacs Lisp's Future

#32

Post by apgwoz »

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…

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?

Re: Emacs Lisp's Future

#33

Post by p4bl0 »

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

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.

Re: Emacs Lisp's Future

#34

Post by belorn »

Blackthorn wrote: post #15
__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

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

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.

Re: Emacs Lisp's Future

#35

Post by progman »

Blackthorn wrote: post #15
__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

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

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.

Re: Emacs Lisp's Future

#36

Post by JulianMorrison »

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

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.

Re: Emacs Lisp's Future

#37

Post by rwmj »

terminalcommand wrote: post #30

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

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.

Re: Emacs Lisp's Future

#38

Post by DennisP »

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

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?

Re: Emacs Lisp's Future

#39

Post by rjsw »

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…

Does RMS really hate Common Lisp, he put a fair amount of effort into adding support for it to the MIT/LMI Lisp Machine sources ?

Re: Emacs Lisp's Future

#40

Post by adrianN »

DennisP wrote: post #38
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/…

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.
Post reply on HN