4 ms·

Shame that Bram is doubling down with vim9script. This will give vimscript a Python 3 moment, splitting an already small community into even smaller pieces. I

by mikl 4y ago

Shame that Bram is doubling down with vim9script. This will give vimscript a Python 3 moment, splitting an already small community into even smaller pieces. I wish he’d have embraced Lua like Neovim. It has already been proven to work great (half my plugins are Lua these days, and it performs great), but alas, it was not to be.

orev 4y ago
I agree that making a new custom scripting language wasn’t the best move, but the release notes deal with backwards compatibility concerns (and calls out Python specifically as a lesson learned).
layer8 4y ago
Since Vim has been Bram’s project for decades, I have some empathy for him to want to continue doing things his way and to not compromise on that. It may have taken Neovim to convince him that certain features are important, but that doesn’t mean he has to like how those are realized in Neovim. Open source is freedom, and I believe it’s okay for him to make use of his freedom to design things in his way, even if the dichotomy with Neovim is not optimal for the community. And maybe it’s not worse than (say) having both GCC and Clang.
- dvogel 4y ago
  I don't disagree with anything you've said but I would personally take this line of argument a step further. I think Bram learned from the neovim fork. Neovim bolstered the existing lua support by reducing the impedance mismatch between the lua language and the vim host. A lot of people enjoy writing lua more than vimscript but the value-add hasn't proved compelling enough for people who didn't mind vimscript. The official neovim repo still has twice as much vimscript code as it has lua code. Even if you claim vimscript is 2x as verbose that would still leave them on equal footing within the project that is putting lua forth as an equal competitor. My impression of vim9script is that Bram had a list of goals (clearly outlined in the docs) and saw the typescript project as a model to follow. The docs themselves mention typescript as a source of inspiration for some features. The typescript project had a similar set of goals and managed to gain massive adoption both among people who had previously disliked javascript (due to the improved semantics) and people who had previously like javascript (due to the speed improvements, transpiler ergonomics, etc).
  - bongobingo1 4y ago
    > The official neovim repo still has twice as much vimscript code as it has lua code Much of that is "just" the runtime files (things that define language syntax, etc), which are x-compatible (broadly) between nvim and vim. Seems it would be foolhardy to just re-write all that in lua, "just because". https://github.com/neovim/neovim/search?l=vim-script&p=1 https://github.com/neovim/neovim/search?l=vim-script&p=1
  - wirrbel 4y ago
    Last time I touched lua support on neovim it really was not as easy as i hoped as an api. As compared to let’s say eMacs lisp.
omoikane 4y ago
There is a Lua interface: https://vimhelp.org/if_lua.txt.html#Lua https://vimhelp.org/if_lua.txt.html#Lua
Beltalowda 4y ago
> This will give vimscript a Python 3 moment Not really; the Python 3 problems were due to incompatibilities in the APIs (e.g. functions returning str previously now returning bytes) that couldn't be automatically converted, not merely due to "being incompatible". You can safely mix VimScript and Vim9Script; you can even use both in the same file. It's not a problem. I wish people would stop using "Python 3!" on any incompatible change; the details on what is incompatible really do matter. > I wish he’d have embraced Lua like Neovim Vim has supported Lua since 2010, and Lua doesn't exactly have the best story on compatibility by the way.
- dvogel 4y ago
  This is all correct. To quote from the official description of vim9script: Vim9 script and legacy Vim script can be mixed. There is no requirement to rewrite old scripts, they keep working as before. You may want to use a few :def functions for code that needs to be fast. So entirely the opposite of the python3 split.

by mikl 4y ago

orev 4y ago

I agree that making a new custom scripting language wasn’t the best move, but the release notes deal with backwards compatibility concerns (and calls out Python specifically as a lesson learned).

layer8 4y ago

Since Vim has been Bram’s project for decades, I have some empathy for him to want to continue doing things his way and to not compromise on that. It may have taken Neovim to convince him that certain features are important, but that doesn’t mean he has to like how those are realized in Neovim. Open source is freedom, and I believe it’s okay for him to make use of his freedom to design things in his way, even if the dichotomy with Neovim is not optimal for the community. And maybe it’s not worse than (say) having both GCC and Clang.

dvogel 4y ago
I don't disagree with anything you've said but I would personally take this line of argument a step further. I think Bram learned from the neovim fork. Neovim bolstered the existing lua support by reducing the impedance mismatch between the lua language and the vim host. A lot of people enjoy writing lua more than vimscript but the value-add hasn't proved compelling enough for people who didn't mind vimscript. The official neovim repo still has twice as much vimscript code as it has lua code. Even if you claim vimscript is 2x as verbose that would still leave them on equal footing within the project that is putting lua forth as an equal competitor. My impression of vim9script is that Bram had a list of goals (clearly outlined in the docs) and saw the typescript project as a model to follow. The docs themselves mention typescript as a source of inspiration for some features. The typescript project had a similar set of goals and managed to gain massive adoption both among people who had previously disliked javascript (due to the improved semantics) and people who had previously like javascript (due to the speed improvements, transpiler ergonomics, etc).
- bongobingo1 4y ago
  > The official neovim repo still has twice as much vimscript code as it has lua code Much of that is "just" the runtime files (things that define language syntax, etc), which are x-compatible (broadly) between nvim and vim. Seems it would be foolhardy to just re-write all that in lua, "just because". https://github.com/neovim/neovim/search?l=vim-script&p=1 https://github.com/neovim/neovim/search?l=vim-script&p=1
- wirrbel 4y ago
  Last time I touched lua support on neovim it really was not as easy as i hoped as an api. As compared to let’s say eMacs lisp.

omoikane 4y ago

There is a Lua interface: https://vimhelp.org/if_lua.txt.html#Lua https://vimhelp.org/if_lua.txt.html#Lua

Beltalowda 4y ago

> This will give vimscript a Python 3 moment Not really; the Python 3 problems were due to incompatibilities in the APIs (e.g. functions returning str previously now returning bytes) that couldn't be automatically converted, not merely due to "being incompatible". You can safely mix VimScript and Vim9Script; you can even use both in the same file. It's not a problem. I wish people would stop using "Python 3!" on any incompatible change; the details on what is incompatible really do matter. > I wish he’d have embraced Lua like Neovim Vim has supported Lua since 2010, and Lua doesn't exactly have the best story on compatibility by the way.

dvogel 4y ago
This is all correct. To quote from the official description of vim9script: Vim9 script and legacy Vim script can be mixed. There is no requirement to rewrite old scripts, they keep working as before. You may want to use a few :def functions for code that needs to be fast. So entirely the opposite of the python3 split.