6 ms·

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

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

layoutIfNeeded 7y ago
Or emacs lisp!
- bjoli 7y ago
  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.
  - wbl 7y ago
    There already is an editor that uses Emacs Lisp for scripting.
- nathell 7y ago
  Or Guile.
  - earenndil 7y ago
    Guile doesn't work on windows.
    - bjoli 7y ago
      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
      - earenndil 7y ago
        Ahh, TIL. Last I looked into it, it seemed technically possible but very impractical.
noch 7y ago
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.
- majewsky 7y ago
  You need some sort of VimScript anyway because VimScript is the language for the command mode prompt.
  - coldtea 7y ago
    The language for the command mode prompt is "ed", no?
    - majewsky 7y ago
      VimScript is a descendent of ed, yes.
    - ncmncm 7y ago
      ex, really.
- kyberias 7y ago
  I think you know the answers to your questions. You just choose to ignore them.
- monsieurbanana 7y ago
  You can support .so extensions if you want, but it has to be secondary to a scripting language. Most extensions don't need raw performance, but an editor needs those extensions. An entry barrier as low as possible is needed to reach the critical mass of third-party extensions that turn an editor into something worthwhile.
Gaelan 7y ago
> just make a fork where Lua is the default scripting language If you're not aware, Neovim is just that (although it supports vimscript as well)
- bananamerica 7y ago
  The fact the Neovim supports vimscript is basically a guarantee that vimscript will never die. I'm not sure that's a good thing.
  - coldtea 7y ago
    It's also a guarantee that Neovim wont be a niche clone, with very few own extensions and no classic extensions supported tho...
saturn_vk 7y ago
> why not just make a fork where Lua is the default scripting language? doesn't neovim have first-party Lua scripting support?
grok2 7y ago
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.
- CGamesPlay 7y ago
  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.
  - grok2 7y ago
    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.

layoutIfNeeded 7y ago

Or emacs lisp!

bjoli 7y ago
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.
- wbl 7y ago
  There already is an editor that uses Emacs Lisp for scripting.
nathell 7y ago
Or Guile.
- earenndil 7y ago
  Guile doesn't work on windows.
  - bjoli 7y ago
    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
    - earenndil 7y ago
      Ahh, TIL. Last I looked into it, it seemed technically possible but very impractical.

noch 7y ago

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.

majewsky 7y ago
You need some sort of VimScript anyway because VimScript is the language for the command mode prompt.
- coldtea 7y ago
  The language for the command mode prompt is "ed", no?
  - majewsky 7y ago
    VimScript is a descendent of ed, yes.
  - ncmncm 7y ago
    ex, really.
kyberias 7y ago
I think you know the answers to your questions. You just choose to ignore them.
monsieurbanana 7y ago
You can support .so extensions if you want, but it has to be secondary to a scripting language. Most extensions don't need raw performance, but an editor needs those extensions. An entry barrier as low as possible is needed to reach the critical mass of third-party extensions that turn an editor into something worthwhile.

Gaelan 7y ago

> just make a fork where Lua is the default scripting language If you're not aware, Neovim is just that (although it supports vimscript as well)

bananamerica 7y ago
The fact the Neovim supports vimscript is basically a guarantee that vimscript will never die. I'm not sure that's a good thing.
- coldtea 7y ago
  It's also a guarantee that Neovim wont be a niche clone, with very few own extensions and no classic extensions supported tho...

saturn_vk 7y ago

> why not just make a fork where Lua is the default scripting language? doesn't neovim have first-party Lua scripting support?

grok2 7y ago

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.

CGamesPlay 7y ago
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.
- grok2 7y ago
  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.