So, if the new language is fundamentally incompatible with the old VimScript, why keep using VimScript? Lua already seems pretty fast, why not just make a fork where Lua is the default scripting language?
(Note, not considering JavaScript in the benchmarks seems like a pretty big oversight before making a conclusion of new default language.)
Why can't the default be to write extensions in C/C++/Rust/zig/jai or any compiled language with which one can produce a .dll or.so?
Why can't application developers abandon this strange habit of adding a slow "scripting" language?
Why not provide a versioned C API and be done with it?
A compiled language would allow us to use the best debugger and compiler on our systems and performance would be in the extension writer's hands and would eliminate the frustrating need to learn yet another scripting language.
>Why can't application developers abandon this strange habit of adding a slow "scripting" language?
How is it strange? Your suggestion sounds even more bizarro. It's not like those developers don't know about shared libs and .so files.
It's that:
a) Programming in C/C++/Rust is more cumbersome (than in a dynamic/scripting/gc language), and throws off tons of potential extension developers.
b) building extensions as .so even more so, adds different builds per OS/architecture, compilation steps, and tons of potential issues, both for setting up your extension building and for delivering it.
c) encouraging extensions written as .so in different languages, means a smaller pool of common reusuable extension code (each extension will reinvent several wheels). Whereas people could easily develop libs in the editors extension language and share them for re-use in others' extensions.
d) an issue in a C/C++/unsafe Rust etc extension will bring down the whole editor. In an embedded language that just calls API you can mitigate it easily.
f) same for memory leaks and such.
AAA game studios, which are hardcode C++ users with high performance / low latency needs, and have gone to using embedded scripting languages (with great success) and for some reason mere editor developers should abandon them and go pure C ABI?
a) I personally find using scripting languages more cumbersome in the medium to long term when I need to maintain, debug code, and optimise code. Every time I see a scripting/dynamic language, I'm turned off from extending the software that embeds it because debugability and performance will inevitably become a problem.
b) I'm not convinced of the alleged "tons of potential issues" that arise from using a compiled language. The extension can be distributed as C code (or whatever compiled language the text editor's community has decided upon). Every platform has a C compiler. I'd argue that C is the most portable language available. Extensions that don't compile will simply fade away, as do extensions in any scripting language, when they don't work. (There is no need for a complex build process or autoconf or whatever other frustrating arcane/convoluted build systems we've somehow been convinced are necessary.)
c) A dll is a shared library. By definition, that is reusable code. There's no necessity that "different languages" be encouraged, merely _a_ compiled language. Even if one extension were to be written in rust/zig and I choose to write an extension in C, is it really so hard for me to read the code I need from that extension and transcribe it for my purposes? I'm not convinced by the "reusable extension code" argument because I have not seen any statistics to justify it and I'm wary of anecdotes, including my own. How much of vim plugins or emacs extensions or vscode extensions are reused code from other extensions? Is it significant enough to raise this (that scripting language code is somehow more reusable) as an argument in defence of scripting languages as extension languages?
d) Patently false I think. (Recall also that emacs didn't successfully mitigate this case for a long time and extensions in elisp could crash the editor.) It's just as easy, if not easier, to mitigate this kind of thing in C. A loaded dll or function can be run easily in a separate process or thread or whatever else one desires. (Didn't plan9 ACME implement communicating processes, an architecture that might be suitable as mitigation of the sort you describe?)
(Also, reinventing the wheel is a bugbear that we should let go of. Attempting to reinvent a wheel is the only way by which one can truly understand how a wheel works. We shouldn't lose this ability or desire. The more we reinvent wheels, the better we get at examining fundamentals efficiently. If we don't reinvent wheels, we'll eventually lose the ability to make wheels.)
f) Claiming "memory leaks and such" is a bit too abstract for me to understand what you mean. I've seen an emacs extension gobble up gigabytes of memory and crash the editor. I suspect I can write such an extension even today. The fault and responsibility would be mine, the extension writer's. I've seen python scripts consume all of a system's memory. There is no magic bullet that solves how much memory a program needs and when the program needs the memory. The programmer has to solve these things.
I do not have any experience in AAA game studios. That said, I haven't heard of scripting languages being used extensively in recent years: A cursory glance at GDC presentations over the past 5 years doesn't reveal much emphasis on scripting languages or on the great successes you allude to. I gather from this that they've mostly been abandoned, excised from engines, or play a relatively insignificant role in the engines used for such games.
I'm not convinced that compiled languages constitute a significant barrier to entry merely because they are compiled and have low level facilities. That would only be possible if programmers somehow didn't have a working understanding of how CPUs and memory work, could only function with a garbage collector, and were unable/unwilling to run compilers like gcc or debuggers like visual studio, but such a person wouldn't meet the definition of "programmer" anyway, I don't think. My assumption is that a text editor, in particular, is being written for programmers.
(a) I don't think we can agree in the end starting from this though. In general, scripting languages are extremely popular and just fine for most people, and editors with tons of quality extensions (Emacs, Vim, Sublime Text, VS Code) all have them written in those. Even if your argument was valid about building a large system, here we're talking editor extensions.
(b) If you're accustomed to compiled languages (e.g. seasoned C/C++ programmer), then sure you are not. But setting up the correct environment, debugging, etc is more difficult for C/C++ than for any scripting language, and a big barrier to entry.
(c) The necessity arises from wanting to get more extensions, and thus attract more coders. If you only allow C extensions, you'll get much less extensions (and not necessarily higher quality either). So you either give a scripting extension language (low barrier, easy access, lots can start using it), or many scripting langauges (even better), or you allow for many compiled languages though an API/ABI (higher barrier, but at least not limited to a single one).
I hardly believe this is a controversial point. Literally almost any app that ever wanted to get more extensions from users went that route. They didn't tell them: "just set up GCC, get the headers, and be on your way", because they knew the majority of potential users (extension authors) would be put off.
In fact, even hardcore C++ AAA game developers add a scripting engine, not for end users, but to make it easier and faster for themselves to develop the logic, behaviors, etc, of the game, exactly for the same reason: outside of the critical paths C++ is overkill, and slows down momentum.
(d) So, not exactly patently false, but only "patently false if you also make a special architecture choice for it" (off-process, messaging, etc).
> f) Claiming "memory leaks and such" is a bit too abstract for me to understand what you mean.
(f) A scripting GC makes it from less easy to impossible to have memory leaks in your extension that e.g. C.
I do not have any experience in AAA game studios. That said, I haven't heard of scripting languages being used extensively in recent years: A cursory glance at GDC presentations over the past 5 years doesn't reveal much emphasis on scripting languages or on the great successes you allude to. I gather from this that they've mostly been abandoned, excised from engines, or play a relatively insignificant role in the engines used for such games.
I'm not convinced that compiled languages constitute a significant barrier to entry merely because they are compiled and have low level facilities. That would only be possible if programmers somehow didn't have a working understanding of how CPUs and memory work, could only function with a garbage collector, and were unable/unwilling to run compilers like gcc or debuggers like visual studio, but such a person wouldn't meet the definition of "programmer" anyway, I don't think. My assumption is that a text editor, in particular, is being written for programmers.
>I gather from this that they've mostly been abandoned, excised from engines, or play a relatively insignificant role in the engines used for such games.
The scripting language is also the configuration. Does it make sense to have non-portable pre-compiled configuration, or configuration that requires a compiler invocation on startup?
I don't know what kdbus is but you're never going to have less latency than copying a value into your instruction register.
And the fact you think a software bus is good enough is the reason so many things are so slow these days. It just depends on what your standard for latency is.
So you can use all the zillions of existing extensions/scripts, it really only makes sense to rewrite using VimScript as the scripting language to make it faster. Then you have a built in user base.
But according to the README, the new language is syntactically incompatible with the old VimScript. So you can’t reuse those extensions, they have to be rewritten.
Yeah, I didn't notice that. If that is the case, then perhaps there is no purpose in creating a new language. Perhaps the only benefit to creating the new language could be that it might be a little easier to mechanically convert from the existing VimScript to the new style VimScript they are thinking of.
Unless you want to be in some way compatible with Emacs, elisp is not a language I would use. Anyone who has written any non-trivial amount of elisp knows this.
There are other lispy languages, that are easier to embed without many of the warts of elisp. If you really want to have elisp, you have 3 ootions:
* Implementing it yourself
* Trying to break elisp and Emacs apart (not likely)
* Using guile's elisp implementation. It is complete and all that, but then you should just use guile scheme instead.
Sure it does. It is just unsupported :) I cross compiled 2.0 without much fuzz at all many moons ago without other changes than a small work-around for a bug in mingw. 2.2 should be about the same. 3.0 (or rather, the 2.9 beta) could possibly be quite a lot harder
(Note, not considering JavaScript in the benchmarks seems like a pretty big oversight before making a conclusion of new default language.)