27 ms·

Emacs Lisp's Future

269 points by rutenspitz 12y ago

lallysingh 12y 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 https://github.com/boostpro/emacs-llvm-jit
- __david__ 12y 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 https://gcc.gnu.org/ml/gcc/2014-01/msg00247.html
  - mwfunk 12y 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.
    - mappu 12y ago
      Standard response: rms has probably done more for free software than anyone else in the world. We should be glad at least someone has such uncompromising idealism. Even if it's annoying and inconvenient from time to time.
    - derengel 12y ago
      I don't see how he is demonizing anyone by calling them adversaries, the word "adversary" doesn't imply any evil at all, you really are just talking from your personal ego.
    - __david__ 12y ago
      > 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. Right there is the crux of the matter. RMS is only focused on the ideal. To him, "accomplishing something" is only relevant when the accomplishment is free software that can't be locked away in proprietary codebases. Viewed through that lens, his actions and beliefs have been remarkably consistent for the past 30 years. He really grates on people who don't share his idealism, and he's looked up to by people who do. He can be quite polarizing, to say the least.
    - dragonwriter 12y ago
      > 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.
    - belorn 12y ago
      What you are calling for is Argument to moderation[1]. Its a common fallacy, which asserts that the truth can be found as a compromise between two opposite positions. Working towards a goal without compromise with those who actively make that goal harder is not wrong. When I have seen RMS labelled people as the "Others", it been when someone has done actions that is direct detriment to free software. If your goal is to build something, and someone else comes with a hammer and start tearing it down, I will give you some permission to be annoyed. [1]: https://en.wikipedia.org/wiki/Argument_to_moderation https://en.wikipedia.org/wiki/Argument_to_moderation
  - Blackthorn 12y ago
    This is particularly funny because BSD code can be freely used in GPL'd products, but not the other way around.
    - __david__ 12y ago
      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 guarantee. GPL does.
      - JetSpiegel 12y ago
        > 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.
        __david__ 12y ago
        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.
    - belorn 12y ago
      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.
  - bane 12y ago
    Remind me again how the GPL preserves my freedom.
    - teddyh 12y ago
      > 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.
      - bane 12y ago
        > 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.
- lispm 12y 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, ...).
  - lallysingh 12y 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 12y 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 12y 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 12y ago
    The quote is about Emacs.
  - craigching 12y ago
    Guile does support FFI and concurrency.
- sdegutis 12y ago
  Thanks for writing libffi! It's given us so many cool possibilities.
informatimago 12y ago
I've got the impression that there is more Common Lisp code and programmers around than guile.
- Blackthorn 12y 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 12y 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.
    - rodgerd 12y ago
      > and you'd have to finally get rid of Guile's "official GNU extension language" status. We can dream.
yason 12y 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 12y 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 12y 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.
CharlesMerriam2 12y 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.
- fleitz 12y ago
  I believe this kind of thinking is what led to the massive success that is emacs in the first place.
eschaton 12y 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?
- rjsw 12y 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.
- lispm 12y 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 12y 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 12y 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.
  - TeMPOraL 12y 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.
    - josteink 12y ago
      > 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. While I agree with most of your statement, having Emacs switch/transition/support another, more modern form of Lisp like CL surely wouldn't count as selling your soul. On the contrary you would stay true to your ideals (a Lisp-runtime with an editor) except now the Lisp runtime just got a lot better. I like Emacs as much as the next guy, and I have dabbled some in Elisp. I can make due. But I sure as hell wouldn't mind getting some of that neat stuff the CL-guys are getting.
HerrMonnezza 12y ago
Tom Tromey started an automated rewrite of Emacs in Common Lisp in 2012, see the announcement at: http://tromey.com/blog/?p=709 http://tromey.com/blog/?p=709 I couldn't find any progress report after http://tromey.com/blog/?p=751 http://tromey.com/blog/?p=751 so I guess the project has been abandoned early.
- eschulte 12y ago
  I think this is the most realistic approach mentioned here, and tromey is actually familiar with the Emacs internals.
  - taylanub 12y 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.)
swah 12y ago
Dream: "Common Lisp/Guile, and a Chromium based rendering engine".
- josteink 12y 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 12y 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.
  - swah 12y ago
    Yep, I agree. Modernization efforts (a modern emacs) should be attempted on products under a new name.
  - agumonkey 12y 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_watson 12y 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 :-)
  - thejdude 12y 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 12y 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 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.
sdegutis 12y ago
Seriously, why not just use Lua? It's perfect for this.
- tree_of_item 12y ago
  Perfect for what? Interacting with Lisp? Lua isn't even remotely an option.
- TeMPOraL 12y 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.
- krylon 12y 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.)
linguafranca 12y 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 12y 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)?
  - thejdude 12y 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.
  - linguafranca 12y 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-are-distinct-languages-with-different-semantics-how-can-lua-be-used-as-a-runtime-for-vimscript https://github.com/neovim/neovim/wiki/FAQ#lua-and-vimscript-...
  - astrobe_ 12y 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.
mark_l_watson 12y 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.
- lispm 12y 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 12y 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?
    - webnrrd2k 12y ago
      But, over the centuries, it will get debugged to near absolute stability.
    - taylanub 12y ago
      Even in the current pre-alpha/alpha stage of Guile-Emacs, I can launch a thread from Scheme, do work, return to the main thread, then call an Elisp function on my result. (Scheme and Elisp data types are unified.) No bugs or unpleasant details there. Calling Elisp functions and accessing Emacs data types (buffers, windows) from multiple threads is another issue; if you don't want to bother with it then don't; you still get all the other benefits of being on Guile. (Calling to any Guile module agnostically as if it were an Elisp library (including, say, Guile's OpenGL module), having an FFI, getting JIT or AOT native compilation in the future, etc.)
brudgers 12y 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 12y ago
can someone more knowledgeable than me explain how is elisp closer to CL than to Scheme?
- lispm 12y 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 12y 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 12y 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).
tedks 12y 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/msg00665.html 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 12y 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 12y 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.
  - tedks 12y 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 12y 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 12y 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 12y 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.
- TeMPOraL 12y 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 12y 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 12y ago
  http://lists.gnu.org/archive/html/emacs-devel/2008-02/msg02140.html http://lists.gnu.org/archive/html/emacs-devel/2008-02/msg021...
TeMPOraL 12y 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.
- lispm 12y 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.

269 points by rutenspitz 12y 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 https://github.com/boostpro/emacs-llvm-jit

__david__ 12y 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 https://gcc.gnu.org/ml/gcc/2014-01/msg00247.html
- mwfunk 12y 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.
  - mappu 12y ago
    Standard response: rms has probably done more for free software than anyone else in the world. We should be glad at least someone has such uncompromising idealism. Even if it's annoying and inconvenient from time to time.
  - derengel 12y ago
    I don't see how he is demonizing anyone by calling them adversaries, the word "adversary" doesn't imply any evil at all, you really are just talking from your personal ego.
  - __david__ 12y ago
    > 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. Right there is the crux of the matter. RMS is only focused on the ideal. To him, "accomplishing something" is only relevant when the accomplishment is free software that can't be locked away in proprietary codebases. Viewed through that lens, his actions and beliefs have been remarkably consistent for the past 30 years. He really grates on people who don't share his idealism, and he's looked up to by people who do. He can be quite polarizing, to say the least.
  - dragonwriter 12y ago
    > 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.
  - belorn 12y ago
    What you are calling for is Argument to moderation[1]. Its a common fallacy, which asserts that the truth can be found as a compromise between two opposite positions. Working towards a goal without compromise with those who actively make that goal harder is not wrong. When I have seen RMS labelled people as the "Others", it been when someone has done actions that is direct detriment to free software. If your goal is to build something, and someone else comes with a hammer and start tearing it down, I will give you some permission to be annoyed. [1]: https://en.wikipedia.org/wiki/Argument_to_moderation https://en.wikipedia.org/wiki/Argument_to_moderation
- Blackthorn 12y ago
  This is particularly funny because BSD code can be freely used in GPL'd products, but not the other way around.
  - __david__ 12y ago
    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 guarantee. GPL does.
    - JetSpiegel 12y ago
      > 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.
      - __david__ 12y ago
        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.
  - belorn 12y ago
    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.
- bane 12y ago
  Remind me again how the GPL preserves my freedom.
  - teddyh 12y ago
    > 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.
    - bane 12y ago
      > 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.
lispm 12y 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, ...).
- lallysingh 12y 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 12y 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 12y 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 12y ago
  The quote is about Emacs.
- craigching 12y ago
  Guile does support FFI and concurrency.
sdegutis 12y ago
Thanks for writing libffi! It's given us so many cool possibilities.

informatimago 12y ago

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

Blackthorn 12y 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 12y 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.
  - rodgerd 12y ago
    > and you'd have to finally get rid of Guile's "official GNU extension language" status. We can dream.

yason 12y 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 12y 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 12y 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.

CharlesMerriam2 12y 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.

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

eschaton 12y 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?

rjsw 12y 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.
lispm 12y 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 12y 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 12y 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.
- TeMPOraL 12y 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.
  - josteink 12y ago
    > 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. While I agree with most of your statement, having Emacs switch/transition/support another, more modern form of Lisp like CL surely wouldn't count as selling your soul. On the contrary you would stay true to your ideals (a Lisp-runtime with an editor) except now the Lisp runtime just got a lot better. I like Emacs as much as the next guy, and I have dabbled some in Elisp. I can make due. But I sure as hell wouldn't mind getting some of that neat stuff the CL-guys are getting.

HerrMonnezza 12y ago

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

eschulte 12y ago
I think this is the most realistic approach mentioned here, and tromey is actually familiar with the Emacs internals.
- taylanub 12y 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.)

swah 12y ago

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

josteink 12y 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 12y 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.
- swah 12y ago
  Yep, I agree. Modernization efforts (a modern emacs) should be attempted on products under a new name.
- agumonkey 12y 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_watson 12y 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 :-)
- thejdude 12y 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 12y 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 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.

sdegutis 12y ago

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

tree_of_item 12y ago
Perfect for what? Interacting with Lisp? Lua isn't even remotely an option.
TeMPOraL 12y 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.
krylon 12y 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.)

linguafranca 12y 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 12y 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)?
- thejdude 12y 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.
- linguafranca 12y 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-are-distinct-languages-with-different-semantics-how-can-lua-be-used-as-a-runtime-for-vimscript https://github.com/neovim/neovim/wiki/FAQ#lua-and-vimscript-...
- astrobe_ 12y 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.

mark_l_watson 12y 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.

lispm 12y 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 12y 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?
  - webnrrd2k 12y ago
    But, over the centuries, it will get debugged to near absolute stability.
  - taylanub 12y ago
    Even in the current pre-alpha/alpha stage of Guile-Emacs, I can launch a thread from Scheme, do work, return to the main thread, then call an Elisp function on my result. (Scheme and Elisp data types are unified.) No bugs or unpleasant details there. Calling Elisp functions and accessing Emacs data types (buffers, windows) from multiple threads is another issue; if you don't want to bother with it then don't; you still get all the other benefits of being on Guile. (Calling to any Guile module agnostically as if it were an Elisp library (including, say, Guile's OpenGL module), having an FFI, getting JIT or AOT native compilation in the future, etc.)

brudgers 12y 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 12y ago

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

lispm 12y 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 12y 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 12y 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).

tedks 12y 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/msg00665.html 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 12y 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 12y 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.
- tedks 12y 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 12y 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 12y 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 12y 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.

TeMPOraL 12y 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 12y 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 12y ago
http://lists.gnu.org/archive/html/emacs-devel/2008-02/msg02140.html http://lists.gnu.org/archive/html/emacs-devel/2008-02/msg021...

TeMPOraL 12y 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.

lispm 12y 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.