[vim/vim] I can be wrong, but option to drop vimscript to JS is only good path (#8327)

[user84441]

Bram Moolenaar has been a lot of work with vimscript, and he can try and tuning that again and again, but reality is - need a platform for the future, that will be forever with us. Vimscript is a dead end and everybody knows that. JS will be ~10-20 years and probably more.

If somehow path exists - it should be picked, like:

https://github.com/jerryscript-project/jerryscript

or

https://github.com/ccxvii/mujs

and many others implementaions. I know, that project like vim cannot use that, because future of these projects is not clear.
But creating breaking version and experiment with that and then drop to it - good path. I know that Bram Moolenaar canont waste his time on it, but if we wanna use vim forever - it need to be done.

Main problem -it's maintenance, and if only Bram Moolenaar knows how to make vimscript fast and good - it's bad, he cannot compete with JS. And his attempts it's just sad, because it's just 1 human vs millions who work with JS.

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub, or unsubscribe.

[user84441]

Closed #8327.

[Dominique Pellé]

@user84441 wrote:

Vimscript is a dead end and everybody knows that.

VimScript is certainly not the ideal general purpose scripting language, but to write Vim plugins, it is very good.
Just to give an example, search for string "foo", you merely need to do:

/foo

Want to jump to line 42? It cannot be simpler:

42

What to edit file foo.txt:

e foo.txt

I don't think any scripting language can compete with this, since they are not designed for Vim.
Vim had integration with Python, Ruby, Perl, Tcl, Lua, MzScheme for many years, and yet most plugins use VimScript and there are good reasons for that. Admittedly Lua is gaining momentum in neovim, but it can be a controversial choice and VimScript won't die in neovim in any case.

[user84441]

@user84441 wrote:

Vimscript is a dead end and everybody knows that.

VimScript is certainly not the ideal general purpose scripting language, but to write Vim plugins, it is very good.

Just to give an example, search for string "foo", you merely need to do:

/foo

Want to jump to line 42? It cannot be simpler:

42

What to edit file foo.txt:

e foo.txt

I don't think any scripting language can compete with this, since they are not designed for Vim.
Vim had integration with Python, Ruby, Perl, Tcl, Lua, MzScheme for many years, and yet most plugins use VimScript and there are good reasons for that. Admittedly Lua is gaining momentum in neovim, but it can be a controversial choice and VimScript won't die in neovim in any case.

Tell me why approach like coc-nvim with extensions so popular and MORE robust than other plugins written in vimscript - it's easy, because of JS.

[Bram Moolenaar]

JavaScript is dead, TypeScript is the replacement.
And later: TypeScript is dead, is the replacement.
There is no end to this.
Calling something "dead" is not nice, better use more friendly terms in a discussion about programming languages.

[user84441]

JavaScript is dead, TypeScript is the replacement.
And later: TypeScript is dead, is the replacement.
There is no end to this.
Calling something "dead" is not nice, better use more friendly terms in a discussion about programming languages.

Yes, sorry for this term, it was rude, vimscript now pretty fast and robust. I closd that, because i was wrong after i think about a little.

[Ingo Karkat]

If you compare Vimscript with other general-purpose programming languages, your points are indeed valid: Vimscript cannot compete in terms of investment, width of knowledge, ease of learning. But Vimscript is used for customization and extension of Vim, so it's much more a domain-specific language (that has general programming capabilities, though).

What I particularly like in Vim is the smooth transition from simple macros recorded on the fly, then stored in a register across sessions, then turned into mappings in one's .vimrc file, and finally put into a plugin and published for others to use. Same with Vimscript: You'll notice a combination of commands used together often, put them into a custom :command, later extract a :function to make it more robust.

For that, I gladly put up with all of Vimscript's idiosyncrasies and quirks. I personally haven't seen another configuration system that allows such a smooth progression, without having to stop altogether at one point and switch to another system. Amazing algorithms can be implemented in Vimscript (though with a bit of pain), and there's always the possibility to use one of the integrated languages or external commands for tasks that go beyond that.