1. 52
    Vim9 vim github.com
  1.  

  2. 22

    Bram’s benchmarks are not using LuaJit. So when he mentions my benchmarks (on the mailing list at least) and presents the Vimscript2 vs Lua benchmarks, this is confusing. LuaJit is 10x faster.

    The Vim9 benchmarks are always structured as function definitions, because the Vimscript2 optimizer won’t work at script scope (i.e. outside of a function). And it sounds like “lambdas” will continue to be slow.

    The main disappointment for me is that existing Vimscript plugins won’t benefit from Vimscript2 optimizations, because Vimscript2 is a different language. If authors must rewrite plugins then I would prefer a well-engineered language (like Lua) instead of Bramscript.

    Given how bigoted and petty people are about syntax, my grand prediction is that the unpaired } will be the most disliked feature of Bramscript.

    1. 19

      If authors must rewrite plugins then I would prefer a well-engineered language (like Lua) instead of Bramscript.

      You know, Lisp would be a good choice for a well-engineered choice to extend an editor …

      1. 4

        Given how bigoted and petty people are about syntax, my grand prediction is that the unpaired } will be the most disliked feature of Bramscript.

        I remember people mocking it in Zimbu, so you’re right on the money.

        1. 3

          Out of interest - is Lua interpreter of VimL still in the making or it is paused indefinitely? That would be interesting thing to see in the future.

          But I agree, if there is plan to replace VimL with another implementation then it would be the best to either use WASM and compile any language to it or to use LuaJIT/V8 instead.

          1. 8

            Somewhat counter-intuitively, to make Lua the more popular/standard choice, it could be a good idea to make a translator from Lua to VimScript2, and then proceed to not support VimScript2 in NeoVim. This way, for plugin developers who want to support both Vim9 and NeoVim, Lua would be the reasonable “cross-platform” choice, automatically giving their plugins wider adoption with no extra effort required.

            I remember reading an article long ago which explained how this exact dynamic worked for some technology, but can’t surface any specific details from my memory. I kinda think it was maybe about Sun and Java, but not sure. I think it might possibly be called something like “platformization of a technology” by business people, but also not 100% sure about it. Basically, the idea is to force one’s competitor to become “just” exchangeable infrastructure. Ok, I think I remember now, and the article’s thesis about the Sun story was, that by making Java free, they wanted to make their hardware more popular, but instead they painted themselves into a corner of being “just an exchangeable platform/infrastructure for running Java”, where they were squashed by others.

            1. 6

              This idea also comes up when talking about the python 2 to 3 transition. If, instead of releasing a 2to3 tool, they had released a 3to2 tool, folks might have focused on developing for 3 earlier.

              1. 3

                The biggest problem with Python 2 ↔️ 3 thing is that it’s virtually impossible to reliable translate code due to the nature of the changes in Python 3 and Python’s lack of typing info. Functions that previously returned/accepted str now return bytes, and it’s very hard to reliably detect 100% of all cases in Python.

                1. 1

                  You’re right, and that’s part of why they started using mypy for everything at dropbox– to catch edge cases when transitioning.

              2. 5

                you’re thinking of spolsky’s commoditize your complements

                1. 1

                  So it seems indeed, thanks!

              3. 6

                is Lua interpreter of VimL still in the making or it is paused indefinitely?

                Why continue it? The patch is there for anyone to try. It’s too slow according to its author (ZyX), who later used parts of that work to implement the VimL parser in C (see :help nvim_parse_expression() ).

                Once you have a parser it doesn’t really matter whether it was written in Lua or C. Problem is, Nvim currently only has a parser for VimL expressions–i.e. half of the language. ZyX later disappeared, perhaps driven mad or perhaps realizing that text editors are not a very good thing to spend one’s life on.

                1. 3

                  Out of interest - is Lua interpreter of VimL still in the making or it is paused indefinitely? That would be interesting thing to see in the future.

                  It’s paused.

                2. 3

                  Considering that conversion tools from Python, JavaScript, and TypeScript are mentioned, I would expect that a VimScript → VimScript2 tool would also be included.

                  1. 7

                    Such a tool could target any language, and therefore doesn’t answer the question “why Bramscript instead of an established, well-engineered, existing language”.

                    1. 2

                      Converting from VimScript to VimScript2 is probably going to be easier than converting it to pretty much anything else. Note that those Python/JS tools aren’t necessarily expected to be complete (” Ideally a conversion tool can take Python, JavaScript or Typescript code and convert it to Vim script, with only some things that cannot be converted.”).

                      Arguably, using VimScript is easier as you can use any ex commands without frobbing about. I think there is some value to that.

                      I believe Bram previously stated he doesn’t like Lua much (can’t find ref for that right now), and just “plug and play” a programming language in Vim is probably not so easy; the only two mainstream(ish) easily pluggable languages I can think of are Lua and Tcl.

                      But perhaps most importantly, I think Bram just likes working on this kind of stuff; he said so pretty explicitly actually: “Yes, it’s going to be a lot of work. But it’s the kind of work I enjoy doing”.

                      1. 4

                        But perhaps most importantly, I think Bram just likes working on this kind of stuff; he said so pretty explicitly actually: “Yes, it’s going to be a lot of work. But it’s the kind of work I enjoy doing”.

                        Creating language is fun, maintaining it - not so much.

                        1. 1

                          Bram has been doing this for a while… I think he’s perfectly capable to judge and decide what he finds “fun” or not.

                          1. 2

                            Still, I find having “fun” while creating language isn’t the main problem. The main problem is that others need then to deal with your language. And using another, established, and maintained by someone else, language in general is much easier. This would also provide access to broader amount of optimisations, implementations, libraries, etc. Ok it is nice that someone wants to create language, but IMHO Bram isn’t the best language designer out there. I would be much more happy if he would rather decide to go with something that is already there, and there is a lot of languages/technologies to pick:

                            • Lua
                            • many embeddable Lisps
                            • MRuby
                            • JavaScript

                            Or even ignore all of that and go with WASM so the language in which the extension is written doesn’t matter at all. The last thing I think would be the best option IMHO in current state, as even current VimL interpreter could be compiled as a WASM blob instead of being “built in” into editor itself. This would provide us a lot of flexibility and potential speedups by using well-established VMs.

                            1. 1

                              having “fun” while creating language isn’t the main problem. The main problem is that others need then to deal with your language

                              So don’t use Vim then, if you don’t want to do that. You don’t “need” to deal with this language; there are plenty of options.

                              Aside from the technical arguments (which I don’t really care about, as I think it doesn’t really matter much), I find this kind of reasoning weird.

                              1. 2

                                Oh yeah, the ultimate argument - if you do not like part of X then GTFO. The “you do not like your government - go live somewhere else” argument. So instead of making things we like, we get attached to, we should abandon them instead of trying making them better. That is marvellous idea, that I completely ignore and treat as a lowest point of reasoning. I like Vim, I like using it, I like some ideas behind it, and I want it to be better and better. Partially that is why I have switched to NeoVim now, because I seen it as an advancement over stagnated Vim development in pre-8.0 version.

                                Aside from the technical arguments (which I don’t really care about, as I think it doesn’t really matter much)

                                Technical arguments are THE arguments, anything else doesn’t matter. Unfortunately, for me, Bram has very high NIH syndrome which I think that we all can agree that this is bad thing. “Making new things” because it seems “easy and fun” rarely is a good thing. There is a lot of work already done in matter of the performance, usefulness, libraries, and all the stuff around it, and ditching them just because? Does the Bram knows better? Is he some kind of the god that can do everything better than others? I highly doubt so. Nanos gigantum humeris insidentes is thing we should do, and reducing internal complexity of Vim is IMHO good thing. See how much of completely dead code (that could never end in Vim as the flags were excluding themselves) were removed by NeoVim.

                                Just in case, I do not say that NeoVim is better than Vim, but for sure it make Vim advance faster since it became a thing. I like that both projects make advance the Vi-like editing, sometimes in way I like, sometimes in way I have doubts, but still, if you do not evolve, you are doomed.

                                1. 2

                                  Does releasing something on the internet and having people use it automatically mean you have a responsibility to listen to “users” who feel they know better than you what to work on or how to fix problems?

                                  The problem with a lot of the discussion here is that there is nothing wrong with chiming in (“hey, I think solution X might be better for reasons Y and Z”), but there is a sense that something should be done different. And that is a rather entitled and toxic attitude.

                                  Imagine someone coming on your issue tracker and saying “hey, you should do X, because NIH”, and you reply that you don’t like X, and then this person would persist in telling me that I really should use X. I don’t know what your response would be, but mine would be to tell that person to get lost rather quickly. If my project is useful to you: great! And I’ll gladly accept suggestions, but telling me what I should do? Yeah nah, that’s crossing a line.

                                  I don’t see how Vim is any different from my small personal project.

                                  NIH syndrome which I think that we all can agree that this is bad thing.

                                  No, I don’t agree. Vim is Bram’s project. He works on it for fun. He likes inventing languages for fun. So he invents a language.

                        2. 0

                          But perhaps most importantly, I think Bram just likes working on this kind of stuff; he said so pretty explicitly actually: “Yes, it’s going to be a lot of work. But it’s the kind of work I enjoy doing”.

                          That only thing that troubles me about your conclusion, is the delicacy with which you reached it :) That is, it is obvious to anyone watching the vim_dev mailing list and studying Vim’s architecture, that most decisions are driven by NIH fetish.

                          1. 2

                            So? It’s Bram’s project; he works on it for fun, he works on the kind of things he finds fun.

                            1. 1

                              Pretty sure that’s not the tagline on vim.org, nor in the help files, nor does Bram himself raise such an invincible retort against criticism. But it’s a comfortable reductionist hole for ending discussions.

                  2. 2

                    So, if the new language is fundamentally incompatible with the old VimScript, why keep using VimScript? Lua already seems to me that it’s pretty fast. Why not just make a fork where the default scripting language is Lua? (Note, not considering JavaScript in the benchmarks seems like a pretty big oversight before making a conclusion of a new default language.)

                    1. 2

                      I’d like to see endfunc and enddef and all the other end* keywords just be replaced with end. Why does a block of code need to be so explicit?

                      1. 5

                        It was mentioned on the mailing list thread:

                        Please don’t change endfunction/endif/endwhile… it makes it hard for plugins like match-up to make % work. Also complicates things for very little benefit, at best saving a tiny amount of typing, at worst makes it easy to lose track of scopes.

                        and:

                        It would be even more readable if we use “}”:

                            if cond
                              do something
                            }
                        
                            for i in list
                              do something
                            }
                        
                            {
                              let local = 0
                              ...
                            }
                        

                        “endfunction” should probably be kept, otherwise a missing “}” or “end” is hard to locate.

                        Personally I don’t think it matters much, so not an endorsement of these views. Just posting the arguments that people made.

                        1. 2

                          I’m not saying get rid of anything, just give people the option…but holy crap the end } must make it almost impossible to write tooling around vimscript…

                          1. 2

                            I don’t really see why. Just match closing braces with the first preceding pattern in (if, for, {, while, …).

                            There’s a similar thing in Julia (and Pascal) where a single closing symbol (end) is used for many different structures (function, begin, do, for, while, …) and the tooling is fine.