I don't even care what RMS' argument was, I think he's pretty out of touch most of the time. But putting Javascript in Emacs is just a stupid idea that would completely ruin it eventually. Let Emacs be Emacs and Vscode be Vscode.
I don't even care what RMS' argument was, I think he's pretty out of touch most of the time. But putting Javascript in Emacs is just a stupid idea that would completely ruin it eventually. Let Emacs be Emacs and Vscode be Vscode.
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.
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.
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?
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.
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.
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.
They're both basically just ergonomic issues at this point, with prefixing names and always setting lexical scoping being cultural norms.
Yes! Prefixing names as a way of emulating namespaces generally works well enough. We could get modules support the same way JS used to have them, ie. as hashes of closures. Or we could use something like the `nameless` package, which rewrites the code to add a prefix to definitions automatically. Yet nobody seems to be doing either: it's just too much of a pain with too small a gain. The situation would be different if we got first-class module support in the language, but if we're going to only emulate it anyway, then namespacing with prefixes is just the easiest way to do it that is still "good enough". Still, Racket-like modules would be great to have, can't deny that :-)
Javascript tends to ruin everything eventually.
Now this is endemic in the JS world, especially because it is more ubiquitous than the previous beginner language, PHP.
They don't want to have another, so they change the world around them so that Javascript can be used for anything.
Lisp is much, much harder to learn than JS is. Aside from that JS is a very transferrable skill, but Lisp is not.
https://github.com/Wilfred/tree-sitter-elisp/blob/main/gramm... (approx. 200 lines)
and here is the grammar of JavaScript:
https://github.com/tree-sitter/tree-sitter-javascript/blob/m... (approx. 1200 lines)
JavaScript evolved into a language of similar complexity as Perl 5 (the corresponding tree sitter syntax table counts almost 2000 lines, currently).
> I speak from my experience in college (~3-4 years ago) where, every year, 60% of the class dropped out of an AI class taught in common lisp because they couldn't understand it: https://catalog.harding.edu/preview_course_nopop.php?catoid=...
JS is much easier to become bad at quickly, which is not a bad thing.
Lisp is an ever-expanding paradigm, but you can learn it at a steady pace like JS.
JS is directly transferrable to similar-syntax languages, yes.
But Lisp provides insight into techniques that will expand your knowledge and understanding of all programming languages.
Does JS have a music video like this? (The Land of Lisp)
https://www.youtube.com/watch?v=jxi0ETwDvws ("Bug in the Javascript", not music video but video of musician performing vocal and harmonica parts of song)
Do i prefer JS? Probably not. But to me the draw of emacs is nothing to do with Elisp. It is instead everything to do with customisation, one-editor-many-languages, and the ability to do absolutely everything from a keyboard-based, low-clutter GUI.
Part of it is of course that good people made plugins in Elisp and maybe you'd argue that without it they wouldn't come to be, but I'm not sure.
I keep hearing this argument but it is contradictory: the reason why Emacs is so customizable it is because it is written in a Lisp, a very versatile metaprogramming language.
You simply cannot have the flexibility of Emacs in anything less malleable than a Lisp. You'd have a regular editor with plugins.
I know many will want to prove me wrong, but where is the non-Lisp Emacs killer yet? VSCode is a great editor, but it's nowhere as flexible.
If I could write plugins in Python, within the Emacs environment, I would (i believe it is sort of doable but quite wonky).
Now that Emacs Lisp actually has native compilation, the speed issue is less of a problem, but it's a plain fact that a lot more people can do things with Javascript than Lisp.
I think usually if you have an application you'd prefer to reuse a programming language rather than having a language specific to the application. I think that was the main motivation for the failed port to Scheme.