
Vim9: An experimental fork of Vim to explore making Vim script faster and better - earenndil
https://github.com/brammool/vim9/blob/master/README.md
======
enricozb
Check out Kakoune[1] for a different take on an editor’s scripting language.
It offloads as much as possible to existing Unix tools such as bash, sort,
fmt, etc. It uses a clever system of string substitutions that’s a bit
unintuitive at first, but not too difficult to grasp quickly. I spent two
weeks trying to fix a bug in a Vim plugin that ended up being a 3 line change.
After that I felt like I barely understood just a small section of vimscript.

I ended up switching to Kakoune after trying it for a bit because I realized
that in the two weeks of me exploring it I had entirely understood it’s
“scripting language”, or at the very least understood how to use the onboard
docs to write any plugin I wanted to.

[1]: [https://github.com/mawww/kakoune](https://github.com/mawww/kakoune)

~~~
timeattack
Sorry, but I find this to be very bad design.

Check this out [1]: kak script evaluating sh script which in turn call perl
which constructs kak script commands and output them to stdout to be evaluated
by kak.

Or this one [2]: same, as before, but now it's calling awk, which calls `date`
binary (so it's kak → shell → awk → date → kak).

It seems that it's done this way because sh is not good programming language
to use for manipulating text. Moreover, sh is not good programming language to
write complicated programs, which later can be successfully maintained &
tested.

For me, kak approach is past the border of unmaintainability.

Also, it raises question of why not to use embedded language like python or
lua instead of creating such a limited editor-specific language.

[1]:
[https://github.com/mawww/kakoune/blob/25429a905b717d29bdf92c...](https://github.com/mawww/kakoune/blob/25429a905b717d29bdf92cb0da5347b7fef04436/rc/tools/git.kak#L114)
[2]:
[https://github.com/mawww/kakoune/blob/25429a905b717d29bdf92c...](https://github.com/mawww/kakoune/blob/25429a905b717d29bdf92cb0da5347b7fef04436/rc/tools/git.kak#L73)

~~~
dmos62
I'm interested in seeing a response to this. I sympathize with wanting to use
unix tool composition, but I've personally found shell languages inadequate
for more interesting applications.

~~~
coldtea
Small staple unix programs, pipes, job control etc are all great ideas.

POSIX shells languages however, are awfully designed (including zsh/fish for
historical compatibility with POSIX concepts reasons).

Something close to TCL as a shell would be much better.

~~~
dmos62
I wouldn't say that they're badly designed. They make it easy to deal with
text, the bread and butter of shell, while neglecting other data structures,
which is fine 99% of the time, unless you're using these shell languages as
general purpose.

They also neglect parallel, concurrent, async programming. Which agan is fine
for a shell language. The shell does have use cases for simple parallel
processing and you can delegate to dedicated unix tools for that and it works
great. If you need more, you're expected to jump into a more powerful
environment.

So they're poor in data structure variety, and more interesting
(nonsequential) ways of executing programs, which, again, is fine for a shell
language, but those were exactly the things I wanted. I wanted to pipe and tee
a bunch of programs programs into one "executable graph" a la dataflow
programming using bash or something similar, but quickly understood that due
to the above reasons I need a different environment. I'm still on the lookout
for good dataflow programming environments.

~~~
fwip
You can definitely do parallel / concurrent / async programming directly in
the shell, without any helper programs. It's not exactly ergonomic, but with a
few patterns it's not too difficult.

Async:

    
    
        long_running_cmd & > results.txt
        cmd_pid=$!
        # other stuff
        wait $cmd_pid
        # do something with results, if you want
    

Parallel:

    
    
        for script in "${scripts[@]}" ; do
          "$script" &
        done
        wait
    

Dataflow:

    
    
        mkfifo my_channel
        mkfifo another_channel
        my_cmd > my_channel &
    
        tee my_channel \
          >(cmd1) \
          >(cmd2 > another_channel) &
     
        another_cmd < another_channel
    
    

But if you want a useful dataflow environment, I really recommend checking out
[Nextflow]([https://www.nextflow.io/](https://www.nextflow.io/)). I use it at
work for constructing bioinformatics pipelines, and it's really natural. The
"preview" DSL2 is worth looking at, as well.

~~~
dmos62
Thanks you for the recommendation, Nextflow looks exactly like what I was
looking for! Thanks for the bash examples as well.

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

~~~
noch
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.

~~~
meain
There will still be a need for a non compiled language as we might have to
change stuff on the fly.

~~~
NilsIRL
We _could_ do that with a compiled language.

~~~
tzekid
Hmm ... how would you do that and keep the level of entry low?

Julia would come close to that - script while prototyping and compile when
done.

~~~
PuercoPop
Several Common Lisp implementations do it, ej. SBCL. Why do you think
interactivity is opposed to compilation?

I'm not too familiar with Julia but afaik it compiles the forms entered in the
REPL as well.

------
wyclif
Why would people want to adopt and use Vim9 instead of NeoVim, which
eliminates a lot of cruft and uses Lua? Interested in knowledgeable responses
from Vimmers and NeoVimmers.

~~~
runningskull
I’m torn by the idea of replacing vimscript with lua. I honestly enjoy both
languages (vimscript is not as bad as its reputation!) but they each shine in
different use-cases. Lua is more ergonomic for writing programs/plugins, but
vimscript is more ergonomic for interactive use (and maybe config files, more
below).

For non-vimmers, a good analogy is the shell: would you want to replace sh
with a more robust language like lua? Few people seem to enjoy writing larger
programs in sh, and are quick to jump to perl/python/ruby once a script
crosses some complexity threshold. However, I doubt many people would want to
give up sh for interactive use. Mainly[0] due to omitting “cruft” like
parens/quotes/commas, and also pipe syntax. Minimal example:

    
    
        ls -laht | grep foo
    

is nicer than

    
    
        grep(ls(‘laht’), ‘foo’)
    

especially when you’re doing thousands of commands of varying complexity every
day.

Vimscript is similar, again mainly due to omitting “cruft” like
parens/quotes/commas, and also some specific sugar. Minimal examples:

    
    
        iabbr cosnt const
    

is nicer than

    
    
        iabbr(‘cosnt’, ‘const’) 
    

and

    
    
        s/foo/bar/g
    

is nicer than

    
    
        sub(‘foo’, ‘bar’, ‘g’)
    

especially when you’re doing hundreds (thousands?) of commands of varying
complexity every day.

Besides setting options, the vast majority of the “meat” of my config file
boils down to these types of commands, and is thus much more readable with the
cruft omitted, even though I only have to type it once.

This could probably be addressed with some light syntax sugar on top of lua,
and I think I remember seeing some comments from the Neovim folks about this
very thing, but I’m not able to find anything concrete at the moment. Does
anyone know where this stands?

—

[0] Of course, another issue (for both shell-scripting and vim) is the huge
amount of tools built on top of the existing language, which we may be remiss
to abandon. For shells, it’s probably practically impossible. For vim, I
suspect it is possible, though it would be painful enough to merit a long hard
think.

~~~
ncmncm
I you are having your editor change "cosnt" to "const", or "isntall" to
"install", you are programming your fingers to be unable to type them
correctly. You will regret it, but it will be too late.

------
bachmeier
Many of the comments here appear to have been made without reading the full
post. Maybe because I'm not a Vim user it made sense to read the post in its
entirety.

From the post:

"Attempts have been made to implement functionality with built-in script
languages such as Python, Perl, Lua, Tcl and Ruby. This never gained much
foothold, for various reasons.

Instead of using script language support in Vim:

Encourage implementing external tools in any language and communicate with
them. The job and channel support already makes this possible. Really any
language can be used, also Java and Go, which are not available built-in.

Phase out the built-in language interfaces, make maintenance a bit easier and
executables easier to build. They will be kept for backwards compatibility, no
new features.

Improve the Vim script language, so that it can be used when an external tool
is undesired.

All together this creates a clear situation: Vim with the +eval feature will
be sufficient for most plugins, while some plugins require installing a tool
that can be written in any language. No confusion about having Vim but the
plugin not working because some specific language is missing. This is a good
long term goal."

So, as I read this, his argument is that it makes sense to offer _both_
external language support and Vimscript.

------
vikinghckr
I find it quite impressive that Bram still finds time to not just maintain Vim
but also adding drastic new features like this, while doing a full time job at
Google at the same time.

------
Avi-D-coder
I have the displeasure of knowing vimscript. I have a couple plugins and
contribute to others. vimscript is terrible, it's unintuitive, neither fp nor
oop, and fails to integrate any domain specific features. It could and should
be replaced by any other fast scripting language.

Kill vimscript adopt Lua for compatibly or Gluon for fp.

~~~
stewbrew
Vimscript is a collection of ex commands (i.e., a DSL for editors) with a few
functions bolted on that provide for a simple form of OOP. I don't think your
argument is 100% fair.

~~~
Avi-D-coder
Being a collection of commands that can be entered in a repl does not make it
a text centric DSL Text manipulation in vimscript is more verbose than Rust
including all ownership syntax. What elements of vimscripts design make it
good at parsing and manipulating text?

I can imagine a beautiful text centric EDSL in Haskell or a lisp that
integrates tree sitter to provide syntactic hooks. I don't blame vimscript for
not having this modern integration, but I do blame it for being a poorly
designed language and I condemn any attempts to prolong its life. Over in
NeoVim land treesitter is being integrated. Once it lands someone should write
a EDSL in the Lua lisp.

~~~
stewbrew
`:help :syntax`?

~~~
Avi-D-coder
I've written vim syntax files before. Syntax highlighting and an error
tolerant syntax aware Text manipulation EDSL are very different.

------
coldtea
I've seen this posted 4-5 times (via the "past link") and 0 comments in all.

Are the usual posts with comments (e.g. on some minor version release of a
framework) on HN so much more interesting than a potential feature direction
of a staple UNIX editor with a redesigned scripting language?

~~~
sojournerc
Seems like some impressive improvement in benchmarks, but for me vim already
just works.

I never feel like it's slowing me down, and I can get everything I need from
it.

Maybe it's a sign of vim's maturity that such news isn't received with much
fanfare.

~~~
JadeNB
> Seems like some impressive improvement in benchmarks, but for me vim already
> just works.

> I never feel like it's slowing me down, and I can get everything I need from
> it.

I feel the same way personally, but do you do a lot of scripting of vim? I
don't, and I get the impression that that is a lot of pain points for vimmers
much more experienced than I, so that that may explain why people like us
don't see the need for such optimisation.

------
csscrack
While I am reading this I just compare Bram as a maintainer re pace,
creativity and ideas before and after Neovim was born.

People who more into that stuff are the Vim9 benchmarks not underwhelming
compared to Lua or did I miss something?

~~~
runningskull
You’re right about Neovim’s effect on Vim improvements and lighting a fire in
Bram.

Even if neovim goes belly-up (unlikely), or totally diverges (slightly less
unlikely), they’ve done a huge service to the vim community simply by existing
and offering compelling, thoughtful enhancements while respecting the core
spirit of vim - and being exceptionally mindful of practicality in how they
approach changes.

Probably one of the best-ever examples of a fork that is Doing It Right.

------
xvilka
Reminds me of early attempts[1] by NeoVim developers to make VimL to Lua
translator.

[1]
[https://github.com/neovim/neovim/pull/243](https://github.com/neovim/neovim/pull/243)

------
kzrdude
Why not have it as an incremental improvement? Similar to javascript engines,
jit the easily executable code and fall back to the slow path if any of the
listed slow features are encountered.

Incrementalism is powerful, even if it also takes a lot of work; breaking
changes in Vim script are probably not worth it for anyone.

------
mutant
I thought this was the goal of neovim as well.

