3 ms·

Let me be frank: ELisp is a terrible programming language. I have a number of Emacs packages (in ELisp) and Sublime Text packages (in Python), and the developme

Let me be frank: ELisp is a terrible programming language. I have a number of Emacs packages (in ELisp) and Sublime Text packages (in Python), and the development effort difference between the two is not even funny. That said, Emacs relies rather heavily on unique features such as dynamic binding, advice, and autoloads. These are more or less impossible to replicate in modern languages, so I don't think there's a reasonable path to rewriting major parts of Emacs in, say, Javascript. But we should look at what Lua did for Neovim. There has been an explosion of development effort now that Neovim finally added a reasonable programming interface. A similar thing could happen in Emacs.

marklgr 4y ago
> But we should look at what Lua did for Neovim. There has been an explosion of development effort now that Neovim finally added a reasonable programming interface. It is very much debatable whether Lua is the "reasonable programming interface" causing the activity in Neovim. Vimscript has many flaws, one of them being that it doesn't look like other programming languages, but it does its specialized job pretty well. It is slow, but efforts are made in that area. Lua is well designed but it certainly has its shortcomings too, and many argue (me included) that programming in Lua is not that pleasant. The Lua bindings have been available in Vim for quite some time, but they never were popular, for some reasons. Anyway, it is not directly related to your point, but I think that example is not that compelling.
- giraffe_lady 4y ago
  Lua is a really good lure. You add it to a project and a bunch of people go "oh neat, I've heard a lot of good things about lua, I'll do this idea I've had in lua." And then the realities of working in lua accrete over months, but then they're in too deep. What are they gonna do, learn elisp? Admit defeat and switch back to VS code?
  - klibertp 4y ago
    > What are they gonna do Personally, I'm using Haxe with its Lua backend. While wrapping Lua APIs is a pain, and some dynamic patterns are hard to represent directly, Haxe provides a lot of the things that Lua lacks: a gradual static type system, more familiar JS-based syntax, syntactic sugar for lambdas, sane handling of `this` in methods, control over inlining, immutable variables, generics, null safety, powerful hygienic macros, somewhat usable standard library, extension functions (Kotlin/Scala3 like), partial function application, hash and array comprehensions, functional operators on collections, limited operator overloading via abstracts, built-in LSP server, and a lot more. I do this in the context of scripting my window manager, and plan to try this with Nginx/OpenRESTY. I feel like pairing LuaJIT runtime with Haxe compilation creates incredibly powerful combination. Lua provides coroutines, tail call elimination including corecursive functions, lightweight and fast JITed VM, a package manager (luarocks), bindings to important C libraries, FFI, reflection (everything is a table anyway), and more. The integration between Haxe and Lua is not yet seamless, and Lua compiler backend is one of the least developed, but even in this state I'm very happy with the combination of compile-time and run-time features I get.
    - giraffe_lady 4y ago
      Ha interesting, I didn't really expect a serious answer but very cool. I looked into haxe a while back when I was gearing up for a significantly complex project targeting lua 5.1. I ended not using it mostly because of unfamiliarity and it felt like it would add a fair bit of complexity. Didn't want to pick up a whole new ecosystem for that project. I ended up using fennel, which solves most of my practical problems with lua without really making anything harder. Doesn't help with the package ecosystem or build process but I ended up just taking that compromise. Don't regret it, still use fennel anywhere I'm forced to use lua, including hammerspoon and mud client scripting. I think if I was going to work heavily in lua long-term I'd go back and invest in haxe for it.
klibertp 4y ago
> ELisp is a terrible programming language. Why do you think so? My main gripe is the lack of namespaces and proper modules, but there are many languages in Top 10 on TIOBE that share this problem. The only other problem is a clunky, decades old standard library. Lack of consensus around async processing is less important, but also irritating. Other than that, Elisp improved tremendously in the last 5 years, and it keeps improving with every release. The stdlib is getting some long overdue cleanups and sensible convenience modules are added regularly. The language features of other languages are being readily incorporated in the form of macros. The live environment along with "self documenting" code makes for a rapid dev feedback, and tools like built-in Edebug and 3rd party packages like Paredit and EROS make editing Elisp code more pleasant than most other languages. Obviously, Elisp has many problems, it's not ideal, but it's nowhere near "terrible" in my opinion. At least not anymore.
- JHonaker 4y ago
  I agree with you! It's not really that bad. The two biggest problems for me are the lack of namespaces/modules like you said, and the default dynamic scope (with the ability to enable lexical scoping). They're both basically just ergonomic issues at this point, with prefixing names and always setting lexical scoping being cultural norms.
  - gosukiwi 4y ago
    I don't know Emacs Lisp but didn't RMS just said in his talk that they changed the default to lexical scoping?
    - klibertp 4y ago
      Really? (Didn't have the time to listen to the talk.) I'd like to know if it was somehow measured, ie. how much of the Elisp code is still not adjusted to use lexical scoping and how much of such code would break by switching to lexical scoping. You can still opt-in to dynamic scoping by using defvar (and it's been a standard practice since forever), so the only scenario where old code would break would be where a called function accesses local variables from the calling function, like you would do in TCL with upvalue. I suspect that's a pretty small percentage of all the Elisp code in the wild; plus, this would be caught by the byte compiler, without the need to run the offending code. In any case: the change of the default is welcome, though not very important, as we've all already got used to putting `lexical-binding: t` at the top of every Elisp file :)

marklgr 4y ago

> But we should look at what Lua did for Neovim. There has been an explosion of development effort now that Neovim finally added a reasonable programming interface. It is very much debatable whether Lua is the "reasonable programming interface" causing the activity in Neovim. Vimscript has many flaws, one of them being that it doesn't look like other programming languages, but it does its specialized job pretty well. It is slow, but efforts are made in that area. Lua is well designed but it certainly has its shortcomings too, and many argue (me included) that programming in Lua is not that pleasant. The Lua bindings have been available in Vim for quite some time, but they never were popular, for some reasons. Anyway, it is not directly related to your point, but I think that example is not that compelling.

giraffe_lady 4y ago
Lua is a really good lure. You add it to a project and a bunch of people go "oh neat, I've heard a lot of good things about lua, I'll do this idea I've had in lua." And then the realities of working in lua accrete over months, but then they're in too deep. What are they gonna do, learn elisp? Admit defeat and switch back to VS code?
- klibertp 4y ago
  > What are they gonna do Personally, I'm using Haxe with its Lua backend. While wrapping Lua APIs is a pain, and some dynamic patterns are hard to represent directly, Haxe provides a lot of the things that Lua lacks: a gradual static type system, more familiar JS-based syntax, syntactic sugar for lambdas, sane handling of `this` in methods, control over inlining, immutable variables, generics, null safety, powerful hygienic macros, somewhat usable standard library, extension functions (Kotlin/Scala3 like), partial function application, hash and array comprehensions, functional operators on collections, limited operator overloading via abstracts, built-in LSP server, and a lot more. I do this in the context of scripting my window manager, and plan to try this with Nginx/OpenRESTY. I feel like pairing LuaJIT runtime with Haxe compilation creates incredibly powerful combination. Lua provides coroutines, tail call elimination including corecursive functions, lightweight and fast JITed VM, a package manager (luarocks), bindings to important C libraries, FFI, reflection (everything is a table anyway), and more. The integration between Haxe and Lua is not yet seamless, and Lua compiler backend is one of the least developed, but even in this state I'm very happy with the combination of compile-time and run-time features I get.
  - giraffe_lady 4y ago
    Ha interesting, I didn't really expect a serious answer but very cool. I looked into haxe a while back when I was gearing up for a significantly complex project targeting lua 5.1. I ended not using it mostly because of unfamiliarity and it felt like it would add a fair bit of complexity. Didn't want to pick up a whole new ecosystem for that project. I ended up using fennel, which solves most of my practical problems with lua without really making anything harder. Doesn't help with the package ecosystem or build process but I ended up just taking that compromise. Don't regret it, still use fennel anywhere I'm forced to use lua, including hammerspoon and mud client scripting. I think if I was going to work heavily in lua long-term I'd go back and invest in haxe for it.

klibertp 4y ago

> ELisp is a terrible programming language. Why do you think so? My main gripe is the lack of namespaces and proper modules, but there are many languages in Top 10 on TIOBE that share this problem. The only other problem is a clunky, decades old standard library. Lack of consensus around async processing is less important, but also irritating. Other than that, Elisp improved tremendously in the last 5 years, and it keeps improving with every release. The stdlib is getting some long overdue cleanups and sensible convenience modules are added regularly. The language features of other languages are being readily incorporated in the form of macros. The live environment along with "self documenting" code makes for a rapid dev feedback, and tools like built-in Edebug and 3rd party packages like Paredit and EROS make editing Elisp code more pleasant than most other languages. Obviously, Elisp has many problems, it's not ideal, but it's nowhere near "terrible" in my opinion. At least not anymore.

JHonaker 4y ago
I agree with you! It's not really that bad. The two biggest problems for me are the lack of namespaces/modules like you said, and the default dynamic scope (with the ability to enable lexical scoping). They're both basically just ergonomic issues at this point, with prefixing names and always setting lexical scoping being cultural norms.
- gosukiwi 4y ago
  I don't know Emacs Lisp but didn't RMS just said in his talk that they changed the default to lexical scoping?
  - klibertp 4y ago
    Really? (Didn't have the time to listen to the talk.) I'd like to know if it was somehow measured, ie. how much of the Elisp code is still not adjusted to use lexical scoping and how much of such code would break by switching to lexical scoping. You can still opt-in to dynamic scoping by using defvar (and it's been a standard practice since forever), so the only scenario where old code would break would be where a called function accesses local variables from the calling function, like you would do in TCL with upvalue. I suspect that's a pretty small percentage of all the Elisp code in the wild; plus, this would be caught by the byte compiler, without the need to run the offending code. In any case: the change of the default is welcome, though not very important, as we've all already got used to putting `lexical-binding: t` at the top of every Elisp file :)