Emacs Lisp's Future

https://lists.gnu.org/archive/html/emacs-devel/2014-09/msg00434.html

by rutenspitz • 12 years ago

269 156 12 years ago

lists.gnu.org

lallysingh2• 12 years ago

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

__david__7• 12 years ago

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

mwfunk• 12 years ago

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 world is better for it. But nooooooooo, not RMS. He has to demonize anyone who is not 100% in lockstep with him on everything, to everyone's detriment, and throw his "adversaries" into a trash bin labelled "Others".

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. I have wished for so many years that RMS would care enough to provide the latter instead of the usual former.

Blackthorn3• 12 years ago

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

bane8• 12 years ago

Remind me again how the GPL preserves my freedom.

lispm6• 12 years ago

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

lallysingh2• 12 years ago

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

atgreen• 12 years ago

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

slacka• 12 years ago

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

lloda• 12 years ago

The quote is about Emacs.

craigching2• 12 years ago

Guile does support FFI and concurrency.

sdegutis2• 12 years ago

Thanks for writing libffi! It's given us so many cool possibilities.

informatimago• 12 years ago

I've got the impression that there is more Common Lisp code and programmers around than guile.

Blackthorn3• 12 years ago

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.

muuh-gnu• 12 years ago

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 run properly (which took them 25 years and still nobody is using it) and the two Lisps were basically orphaned.

The latest effort of guile-ifying Emacs is more pushed by the Guile guys, in order to attach themselves to an already existing killer app (emacs) and to basically force more and more people to use Scheme, because nobody is doing it voluntarily.

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.

Of course the proper way would be to go Common Lisp. Elisp is and has always been a subset of Common Lisp, and they've had a Common Lisp compatibility layer for decades, and a lot of packages use it. The problem is simply highly political. You'd have to confront RMS, and you'd have to finally get rid of Guile's "official GNU extension language" status.

lispm6• 12 years ago

CL has more maintained implementations than Guile has programmers.

yason• 12 years ago

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/process based concurrency. Guile, Clojure, Common Lisp or whatever language are going to basically restart Emacs from scratch, no matter how well they're coated with compatibility macros.

It's better to create slight incompatibilities gradually (so that packages can catch up in some humane timeframe). I could imagine the ELisp runtime being intertwined with the Emacs C code badly enough that making radical changes to it would seem "impossible", just like in the CPython codebase it is considered impossible to ditch GIL and modernise the code. But those kind of comments are often excuses because people are lazy and it's nicer to write new code.

easytiger• 12 years ago

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.

p4bl0• 12 years ago

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.

JulianMorrison3• 12 years ago

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.

mjn2• 12 years ago

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 a general VM with custom infrastructure to support both Scheme and Elisp is not really a more clean, minimalistic infrastructure anyway. The semantics of Elisp/Scheme are too different to be able to just stick in a Scheme implementation with a smallish compatibility layer, like you could with Elisp hosted on CL.

DennisP2• 12 years ago

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?

adrianN• 12 years ago

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.

tedks5• 12 years ago

Guile can run elisp already, IIRC. There's no compatibility issue, it would just be a runtime change. And then you'd get Guile's VM, which is very nice and also polyglot(tic?). Guile is a language-agnostic VM, not a language itself, and a frontend already exists for elisp.

wtbob4• 12 years ago

There's no compatibility issue

That's not really true, is it though? Scheme '(), #f and so forth...

adamc• 12 years ago

I agree with all of this as an emacs user, but I wonder whether this sets up emacs to be replaced by something that uses a more popular extension language, like Atom. Won't happen in the next 5 years, but 10 years down the line, being based on JavaScript might look like a great decision.

I love lisp but I don't see much interest in it and have had coworkers tell me it keeps them away from emacs. Which is a bit sad...

bachmeier• 12 years ago

I think emacs lisp is a great extension language. There's not much syntax, and it has the important functionality baked in. IMO anyone that says they don't use Emacs because they don't like Lisp is someone that would not use Emacs no matter what.

taylanub5• 12 years ago

Guile-Emacs is not a rework, it's a rebase. It already runs all Elisp, sans bugs and (currently severe) performance regressions. It will be a nearly-drop-in replacement, a new version of GNU Emacs, even less different from it than XEmacs. In general, it will only add to Emacs, and change the underlying implementation of Elisp.

CharlesMerriam2• 12 years ago

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.

fleitz2• 12 years ago

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

eschaton• 12 years ago

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?

rjsw2• 12 years ago

ZWEI (and ZMAIL) isn't Common Lisp, Kent Pitman worked on creating a set of diffs to it to make it compile in CL but I don't think they are freely available.

lispm6• 12 years ago

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?

terminalcommand• 12 years ago

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.

rwmj• 12 years ago

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.

TeMPOraL7• 12 years ago

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 turning it into a Frankenstein monster.

vfclists• 12 years ago

Can you write a plugin for Kate with Kate's own built-in development language and have it running immediately without having to go through a separate edit-compile-debug cycle using a different development toolset?

swah4• 12 years ago

Shouldn't it also use webkit or something for rendering? So.. change the rendering, change the language... shouldn't we just write more editors from zero?

barrkel• 12 years ago

You don't need to read the manual, or even any tutorials, IMO, as long as you know that function application in Lisp looks like (f arg1 ...), know how to program, know that Lisp has macros, almost everything else follows.

It took me a few hours to learn enough Elisp to customize .emacs, add custom macros, and start using defadvice to wrap existing commands with extra behaviour, like preserving the selection for text replacement in a selected block. I even went as far as writing a macro that could use defadvice to generically preserve the selection for any other command on the second day of using emacs.

A bigger hurdle was learning the Lisp jargon, so that I could find the correct function to call when searching for it, whether in emacs itself, or online. But once I knew about the point, that the selection is called the region and is the text between mark and point, that files are called buffers, that open is called find, etc., it was pretty smooth sailing.

It's fairly trivial to find the source for an arbitrary elisp function - just C-h f <function-name>, and follow the source link. Plugins like helm (dynamically filtered list searches) make it very easy to find relevant functions too.

Elisp has a couple of features that make it work well as an application extension language: dynamic variable scope and function advice are two that are fairly unique to Lisp (technically, Javascript has dynamic scope via the eval function, but it's not usually a good idea to use it). These things make it easy to tweak behaviour from the outside.

However, contra other people's opinions, Elisp is not fast. It is slow, very very slow, compared to efficient languages. My startup time is just about tolerable on a modern machine, but not tolerable enough to stop me starting emacs --daemon every time I reboot. Scrolling through large files with line numbers enabled is slow, and the UI has a few milliseconds of lag for almost every non-trivial action. Dynamic searches need very noticeable debounce delays for list refreshes or otherwise things get unresponsive.

HerrMonnezza• 12 years ago

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.

eschulte• 12 years ago

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

taylanub5• 12 years ago

So is BT Templeton, the person who has been hacking away at Guile-Emacs GSoC after GSoC. :-)

(They seem very skilled, don't be fooled by the fact that it's GSoC; no idea what the skill level of people who take part in that usually tends to be.)

swah4• 12 years ago

Dream: "Common Lisp/Guile, and a Chromium based rendering engine".

josteink2• 12 years ago

Maybe I'm in the minority, but I for one really appreciate how Emacs can run in a terminal, over SSH, with almost no feature-degradation at all.

Besides Emacs being a very nice programming (and programmable editor), this is one the key features which keeps me from even considering other more "modern" options.

kendalk• 12 years ago

You may be in the minority in terms of the total number of users, but most of the Emacs developers will have the same mindset. Terminal-friendliness is a part of Emacs tradition. The developers would surely keep the ability to run Emacs in a terminal.

swah4• 12 years ago

Yep, I agree. Modernization efforts (a modern emacs) should be attempted on products under a new name.

agumonkey• 12 years ago

With adequate separation of concerns the backend could either be V as full Dom or as a terminal friendly minimal DOM (no css fonts attributes, pixel positioning, box shading etc).

mark_l_watson4• 12 years ago

Exactly right! I spend tons of time running Emacs over ssh. This is a major value add of Emacs. The -nw option is our friend :-)

thejdude2• 12 years ago

I haven't used Emacs in a while, so I'm very rusty, but why would you run a remote Emacs in SSH, and not use your local Emacs to access remote stuff via TRAMP?

In my Emacs days, I've never really used the terminal version. Multiple frames, yay!

hraberg• 12 years ago

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.

sdegutis2• 12 years ago

Seriously, why not just use Lua? It's perfect for this.

tree_of_item• 12 years ago

Perfect for what? Interacting with Lisp? Lua isn't even remotely an option.

TeMPOraL7• 12 years ago

For building a text editor on-top of a running Lua instance, the way Emacs is a living Lisp image with a text editor bolted on top? I don't see it.

krylon2• 12 years ago

I one were to start from scratch, writing an emacs-like text editor by building it on top of a small programming language you can use for customizing and extending the editor, Lua would a great choice. Lua has only a tiny standard library, but in writing the core of the editor, you probably have to supply the equivalent functionality yourself, anyway.

But I do not see how you could bolt Lua on to GNU Emacs. You would have to start from scratch, and that would be a lot of work. And even then, there is the fact, that GNU Emacs is already well-established, has a very loyal user base and is - by and large - good enough, even great for most purposes, so even if you wrote LMacs or whatever one would call it, you would probably end up with, like, a dozen users or so. (IIRC the Zile project, a small emacs-like editor, has tried this, but I do not know how far they got with this.)

linguafranca3• 12 years ago

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

dbpatterson• 12 years ago

Because it is a completely different language and would require rewriting all of the thousands of packages by hand (and centuries of human labor)?

thejdude2• 12 years ago

OTOH, Emacs isn't that accessible to many users, and its idiosynchrasies can be very offputting. I also quit Emacs after a while because I wasn't totally happy with it.

I think that's why there are so many attempts to built new extensible editors in other languages, like Eclipse, or that Ruby thing there once was (probably still is), or the Chromium/JS monster that was on HN recently.

I haven't yet found an editor I'm really happy with, so if I ever have time, I'll probably write my own as well. I'll lose the Emacs packages I don't use or even know about, but if you haven't bought into an existing ecosystem, that doesn't really matter. I'm unhappy enough with the existing systems that I don't mind throwing them away for something different.

linguafranca3• 12 years ago

Good point. But it's not unheard of to write a transpiler from Language X to Lua. See the VimL compiler in NeoVim[1].

[1] https://github.com/neovim/neovim/wiki/FAQ#lua-and-vimscript-...

astrobe_• 12 years ago

One option is to have both Lua and Elisp, so that packages can be slowly migrated. Lua is small (so it doesn't incur a huge size cost to have 2 engines), fast (one reason why they want to switch, according to the author), and has a significantly large community. It also has coroutines, which is not what people dream of when people talk about concurrency but is probably good enough for a text editor (and avoids most sync problems). Furthermore, with this "dual-engine" strategy it would be a bad idea to choose a language similar to ELisp: it would cause a lot of confusion.

But I guess that Emacs on Lua wouldn't be Emacs anymore. That's the main objection.

davexunit3• 12 years ago

Because Lua isn't an Elisp interpreter/compiler.

wtbob4• 12 years ago

Because Lua is a strictly less useful language than elisp. Among other things:

- It doesn't have macros.

- It doesn't have integers.

- It doesn't have arrays.

- It doesn't have lists.

- It doesn't have dynamic binding.

Also, its 1-based array-like hash tables are just ecchy.

I like Lua; it's cool for what it is (and in fact I'm currently writing some hobby code in it), but it's not Lisp (and in fact my current hobby code is Lisp in Lua…).

sklogic• 12 years ago

MetaLua has pretty decent macros.

linguafranca3• 12 years ago

Because Lua is a strictly less useful language than elisp.

The word "useful" is too subjective to be useful here.

- It doesn't have macros.

There's MetaLua for those who truly think they need macros. But in reality they're just a convenience.

- It doesn't have integers.

Lua 5.3 is getting them.

- It doesn't have arrays.

It has tables that function perfectly well as arrays.

- It doesn't have lists.

Singly-linked-lists can easily be created using tables.

- It doesn't have dynamic binding.

Thankfully!

Also, its 1-based array-like hash tables are just ecchy.

This is purely an imaginary problem. Personally, I prefer 1-baed indices.

I like Lua; it's cool for what it is (and in fact I'm currently writing some hobby code in it), but it's not Lisp (and in fact my current hobby code is Lisp in Lua…).

So, your favorite language is Lisp? Great. Except, favoritism and bias aren't really compatible with truly constructive criticism.

mark_l_watson4• 12 years ago

If it isn't broken, don't try to fix it.

I am an old guy (professional Lisp developer since about 1981) and my age probably affects my opinion:

It would be a disaster to mess up the Emacs ecosystem. I don't think that Emacs/elisp runs slowly and since I have to use so many different programming languages anyway, needing to know a little elisp is no problem.

I don't care if elisp is not a modern language.

Way off topic, something that I have written before about: think forwards several hundred years. What will the software landscape look like? My bet is that there will be many ancient software systems that have been debugged to near absolute stability over the centuries. Sure new software will be written, but I bet there will be many very old and stable systems that will see little change.

lispm6• 12 years ago

Wouldn't it be nice when Emacs would not be blocked when some Lisp routine runs?

Lots of people have written excellent code for GNU Emacs, but the implementation runtime hasn't improved that much.

e40• 12 years ago

Wouldn't it be nice when Emacs would not be blocked when some Lisp routine runs?

Yes, it would be nice, but can you imagine the bugs that will happen while everyone works out the details of how to do it properly?

brudgers• 12 years ago

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.

riffraff• 12 years ago

can someone more knowledgeable than me explain how is elisp closer to CL than to Scheme?

lispm6• 12 years ago

Both Emacs Lisp and Common Lisp are coming from MIT's Maclisp dialect. There were Emacs variants written in Maclisp or its dialects before GNU Emacs existed. Emacs Lisp was a very simplified Maclisp. Common Lisp modernized Maclisp (especially lexical binding), preserved a lot of Maclisp features and standardized stuff like an Object System (CLOS), error-handling (Conditions), enhanced argument lists (especially keyword arguments).

RMS especially did not like the addition of an object system, lexical binding as the default and keyword arguments. Those three things are quite central in Common Lisp. Emacs Lisp has no object-system in its core, lexical binding has only recently added and it has no keyword arguments.

Scheme is quite different from both. But Guile is a very special Scheme dialect with lots of enhancements, which makes it as large as a Common Lisp implementation. I would expect that code sharing between Scheme implementations is more difficult than between Common Lisp implementations.

quotemstr• 12 years ago

Keyword argument support is in the Emacs core these days, along with the rest of the CL library.

    (require 'cl-lib)
    (cl-defun foo (&key a b c) (list a b c))
    (foo :c 3 :b 4 :a 1)

chriswarbo• 12 years ago

ELisp, Scheme and Common Lisp are all LISPs, so they all use a common terminology, s-expressions for syntax, allow higher-order functions and macros, etc. but their programming paradigms tend to be different.

Common Lisp tends to follow a procedural style (if/switch statements, for/while-loops, lots of side-effects, etc.). CL also has the Common Lisp Object System (CLOS) which is a very powerful OO implementation.

On the other hand, Scheme tends to follow a more functional style (recursion, map/reduce, continuations, minimising side-effects, etc.).

ELisp tends to be quite procedural, which is why it's closer to CL than Scheme. Also ELisp uses dynamic scope whilst Scheme uses lexical scope. Lexical scope has only been (officially) supported in ELisp since Emacs 24 (the latest major version).

Jtsummers• 12 years ago

Another thing not mentioned by the other two responders. Scheme is a lisp-1 (single namespace), elisp and CL are both lisp-ns (multiple namespaces). This means that you can have a variable in CL or elisp that shares a name with a function or macro, but the same is not true in scheme.

  ;; valid elisp and cl, same result in each
  (defun foo (bar) (+ 1 bar))
  (defvar foo 4)
  (foo foo) ;; makes perfect sense in CL and elisp,
            ;; but none in scheme

  ;; syntactically valid scheme, won't work on the last line
  ;; which translates to (4 4) and so makes no semantic
  ;; sense.
  (define foo (bar) (+ 1 bar))
  (define foo 4)
  (foo foo) ;; will break in scheme because foo is now 4
            ;; and 4 can't be applied as a function

Barring issues with lexical versus dynamic scope and a few other things, a fair amount of elisp code and CL code will run in the other language (if you don't account for the differences it may still run, but the output will be different between the two languages). You can even (require 'cl) in elisp and have a decent amount of CL functionality added into your emacs instance.

Simple things like function and variable definitions have to be changed to get even basic code (like the above) to half-way work in scheme from elisp.

tedks5• 12 years ago

A lot of people seem to be reading this as if Emacs is choosing between switching languages to Scheme (Guile) or Common Lisp.

Switching to Guile DOES NOT IMPLY switching to Scheme. There is 0 need for compatibility layer or what have you with Guile.

Guile is a language-agnostic virtual machine. It has an implementation for Scheme, but also one for Emacs Lisp. Guile already runs Emacs Lisp faster than Emacs: https://lists.gnu.org/archive/html/emacs-devel/2010-04/msg00...

The main issue the Emacs developers seem to have with Guile is that it will give developers choices as to whether to write Emacs extensions in Scheme, Elisp, or Javascript/Python/Whatever else Guile supports.

rthomas6• 12 years ago

The main issue the Emacs developers seem to have with Guile is that it will give developers choices as to whether to write Emacs extensions in Scheme, Elisp, or Javascript/Python/Whatever else Guile supports

I don't understand why they care? Why would the Emacs developers feel the need to debug compatibility if someone else wrote a shitty extension? The onus would be on the extension developer to fix the extension.

flatline• 12 years ago

Sure the problem defaults to the package maintainer, but historically popular and/or useful packages have seen their way into the main GNU distribution. Just leaving the possibility open has some long-term consequences for the project.

tedks5• 12 years ago

I think it's largely a cultural objection, and one I feel is pretty valid. I would hate to see Emacs turned into a javascript playground.

babarock• 12 years ago

Quoting the linked email:

  So if we go for Guile-Emacs, we'll be stuck with Guile, i.e. we'd
  have (old and new) packages that use Elisp, new packages that use
  Scheme, maybe yet other new packages that use, say, Javascript (or some
  other language support by Guile).  That would make the work of Emacs
  (and GNU ELPA) maintenance harder.

pnathan• 12 years ago

If we (emacs users) can have an emacs that has a "modern" backend & language but is bug-compatible with the extant elisp code, I think that would be grand.

Particularly nice would be thread support.

I'm pragmatically indifferent as to whether the backend is scheme or common lisp (I'd personally prefer Common Lisp, but whatevs).

burtonator• 12 years ago

I spent about 2 years of my life in my 20s hacking on elisp constantly. I was infatuated with it.

Then I spent about 5-10 years using that platform as my IDE.

Guess what... Last year I migrated to IntelliJ IDEA and won't EVER migrate back. It's kind of sad... but IDEA is insanely awesome by comparison.

TeMPOraL7• 12 years ago

Blasphemy!

On a more serious note, could you elaborate a bit on how IDEA is "insanely awesome" compared to Emacs? What do you find more useful/enjoyable in the IntelliJ IDE?

systems• 12 years ago

who is Stefan Monnier? and why should we care about what he thinks?

is he the main emacs maintainer? in other words, how seriously should we consider this email?

tjr• 12 years ago

http://lists.gnu.org/archive/html/emacs-devel/2008-02/msg021...

TeMPOraL7• 12 years ago

I've been bringing the following thought up inside various threads but I think it needs to be said in separate one, since I see many people here and elsewhere missing this about Emacs.

Emacs is not a scriptable editor. You don't "script it" or "write plugins for it" in a classical sense of those terms. You reprogram, extend and augment a piece of running code on the fly. Seems similar, but feels different. Emacs is a live Lisp image with text-editing features bolted on top. It's basically backwards of how a typical editor/IDE is implemented.

Therefore, it matters what language is used as a base. People mentioned Lua or JavaScript, but they are nowhere near useful enough for the task.

Therefore, it feels to me - and I believe to many other Emacs users as well - it matters that there should be one base language. Emacs as an Elisp system with text editing capabilities feels like a whole. Everything fits together nicely and interacts with each other. It is elegant. Aside for inviting maintenance upkeep and general chaos, making Emacs "run" multiple languages at the core is sort of like shattering its soul into many pieces. I don't want to have an editor with multiple-personality disorder.

Imagine you're writing an executable in three different programming languages mixed together at the same time. That class is written in Common Lisp, but it's child classes are written in C++. And exception handling everywhere is written in Python.

The sheer mental effort to make all of these work in a conceptual harmony inside a single program would be enormous. And it would still feel weird.

That is what multiple-extension-language Emacs would feel.

lispm6• 12 years ago

It's basically backwards of how a typical editor/IDE is implemented.

The main difference is that the implementation language is a dynamic language, which is also mostly the implementation language.

That's similar to how some other IDEs work like Smalltalk or Clozure CL on the Mac. But those are not focused on implementing an extensible editor. Those are IDEs with editing features.

Emacs Lisp's Future

Related Stories