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

61–70 of 160 posts

Re: Emacs Lisp's Future

#61

Post by mijoharas »

TeMPOraL wrote: post #45
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…

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

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.

Re: Emacs Lisp's Future

#62

Post by fleitz »

CharlesMerriam2 wrote: post #12

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.

I believe this kind of thinking is what led to the massive success that is emacs in the first place.

Re: Emacs Lisp's Future

#63

Post by JulianMorrison »

marcosdumay wrote: post #60
JulianMorrison wrote: post #54

Earlier quoted context omitted.

Too often it seems RMS is why GNU can't have nice things.

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. It gets tiresome even to watch.

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.

Re: Emacs Lisp's Future

#64

Post by DennisP »

adrianN wrote: post #40
DennisP wrote: post #38

Earlier quoted context omitted.

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.

Hmm. I wonder whether a Javascript vm could be used for Elisp. Of course Javascript is lexically scoped but there's a way to hack around that: http://stackoverflow.com/questions/10060857/is-it-possible-t...

Of course there'd be no point if emacs were fast enough, but there seems to be a significant number of people who feel it's not.

Re: Emacs Lisp's Future

#65

Post by craigching »

slacka wrote: post #5
atgreen wrote: post #3

"Lack of some features, most notably FFI and concurrency." Cool -- my '90s hacks are in demand! I added threading support to Guile and wrote libffi back in the 90s.

It seems your libffi has been used in Guile since 1.9.8, so does that mean Guile does support FFI and concurrency?

Guile does support FFI and concurrency.

Re: Emacs Lisp's Future

#66

Post by craigching »

mijoharas wrote: post #61
TeMPOraL wrote: post #45

Earlier quoted context omitted.

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

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

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

Re: Emacs Lisp's Future

#67

Post by sidhu1f »

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…

There are some sound technical reasons for choosing scheme: http://wingolog.org/archives/2011/08/30/the-gnu-extension-la...

Re: Emacs Lisp's Future

#68

Post by hraberg »

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.

Re: Emacs Lisp's Future

#69

Post by eschulte »

HerrMonnezza wrote: post #43

Tom Tromey started an automated rewrite of Emacs in Common Lisp in 2012, see the announcement at: http://tromey.com/blog/?p=709 I couldn't find any progress report after http://tromey.com/blog/?p=751 so I guess the project has been abandoned early.

I think this is the most realistic approach mentioned here, and tromey is actually familiar with the Emacs internals.
Post reply on HN