33 ms·

Was there some reason why Bram didn't go for Lua adoption, and instead opted for his own language? Is is the NIH syndrome only? Lua seems just a really good opt

by kubb 5y ago

Was there some reason why Bram didn't go for Lua adoption, and instead opted for his own language? Is is the NIH syndrome only? Lua seems just a really good option as far as embeddable languages go. People love complaining about minor issues with it like the 1-based arrays, but building a new language from scratch is just not worth it, no matter how you look at it. Maybe I'm missing something here.

Trex_Egg 5y ago
What is NIH syndrome? Edit: got it, its called "Not Invited Here" syndrome.
- darrenf 5y ago
  “Not Invented Here” is how I’ve always known it.
  - deleted 5y ago
    [deleted]
  - ncmncm 5y ago
    This is the correct one.
- soperj 5y ago
  not in house.
tyingq 5y ago
Vim and Lua evolved in similar timelines. It's plausible that vimscript was written without him knowing Lua was a choice.
- capableweb 5y ago
  I don't know about the timeline of Vimscript in particular, but seemingly Vim was first released in 1991 while Lua first 1993, so by the first release of Lua, Vim already existed by then. Not sure when Vimscript appeared though. On other trends (Google Trends to be specific), search volume for Lua only became larger than for Vim in 2004, with Lua hitting it's peak in 2009. Search volume for Vim would have been much larger before 2004 if we had a single search engine everyone could have used, but hard to know in afterhand I guess.
- blindseer 5y ago
  vim9script was most definitely written way after lua was integrated into neovim, and well well after lua was popular as an embedded programming language choice. While it is plausible that the idea for vim9script was conceived without him knowing Lua was a choice, it is unlikely that work on it was started without Bram knowing. There's even people that have commented on the google groups as far back as 2016 about neovim's use of lua. It's unlikely that Bram wouldn't have seen that.
  - tyingq 5y ago
    vim9script, though, is the evolution of vimscript, and has some amount of backwards compatibility, short-ish migration guides, etc. Initially choosing an embedded script language and migrating to a new one are fairly different scenarios.
- pull_my_finger 5y ago
  Vim already could be compiled with Lua, Ruby, Python with their own respective vim APIs. How is it possible that he didn't know he could use an established programming language for scripting?
capableweb 5y ago
> building a new language from scratch is just not worth it Seems this has been said about every single language ever (except the first I guess?), even languages as Golang and Rust have gone through a phase where many question "why even build a new language when X does Y and Z perfectly fine already?", and then they end up really popular anyways as they solved some slice of problem(s) is a particular way that many like.
- victorvosk 5y ago
  Go and Rust compared to vim script is an Apples to Space Shuttle comparison.
  - capableweb 5y ago
    Yes, if you compare their functionality, performance and on a bunch of other attributes sure. But I'm not doing that, I'm comparing them on the attribute of "new programming language", which all of them have been at one point or another. It might just have been that Vimscript didn't go the way it was intended to, or people moved towards different paradigms to doing modal editing in a sane(r) way, but maybe in some alternative universe, Vimscript became a popular scripting tool.
- blindseer 5y ago
  For every golang and rust, there's probably tens or hundreds of programming languages that will never end up popular. I guess that is to say the probablity that vim9script will succeed isn't high. And golang initially started off as a replacement for C, and then pivoted because they couldn't achieve that purpose ... now, it's touted for simplicity. When Rust was a pet project of Graydon, it looked VERY different to what it is right now. My point is that vim9script as it stands right now doesn't solve any real world use case that lua wouldn't be better suited for. Maybe vim9script will be better for something else entirely in the future, and that will be, as you describe something people may like. But right now we don't even know what that is, and surely that can't be a reason to decide to go explore language design in such a large community such as the one vim has? It is definitely Bram's right to do so, but I fear that people will rather move to neovim or vscode or emacs than learn and write vim9script, and as a user of that community I think that would be bad. Also, it's not like people were proclaiming vimscript was awesome you know. There's a talk from one of the core devs of vim-lsp on YouTube [1], on features of vimscript, and literally in every slide the presenter caveats the vimscript feature in one way or another. I find it hilarious, it's a perfect example of the frustration of when writing plugins with vimscript. [1] https://www.youtube.com/watch?v=7fcJWwl1-SU https://www.youtube.com/watch?v=7fcJWwl1-SU
thayne 5y ago
You could ask the same question about why he decided to make the async api and terminal mode incompatible with existing equivalents in neovim. Sadly, the ecosystem seems to be splitting more and more between vim and neovim.
- Yuioup 5y ago
  My impression is that Bram is trying his best to outcompete neovim.
  - mi_lk 5y ago
    That goes without saying, and it's just unfortunate that he chooses to compete rather than collaborate
    - BooneJS 5y ago
      Competition is good, and it’s the reason why Neovim was created in the first place!
      - Tyr42 5y ago
        I mean, the reason is that those async patches were just sitting in the queue for a year, and by starting Neovim, they could get them in right away. Then Bram started competing afterwards.
        bitigchi 5y ago
        Those patches were broken to begin with when submitted to Vim, and never got fixed until NeoVim was forked out of the blue. People generally don’t know the details of this, and blindly blame Bram.
        dolni 5y ago
        Why did it take neovim being forked to get those patches fixed?
MichaelMoser123 5y ago
Lua and vimscript are both the same age; Lua came out in 1992, and vimscript in 1991, so it would not have been an obvious choice. I think that vimscript has the same problem as shell scripts: there are a lot of editor/shell commands, and they didn't want to introduce a special syntax for distinguishing between the language proper and the editor commands. I don't think that vimscript is that bad. What i don't like about are the scope rules, i.e. special prefixes for function arguments, locals and globals. Also the call keyword is required for function calls and let keyword for assignments. Anyway, Python can be used as a vim extension language, i am not sure if Lua is superior in this respect to python.
- ncmncm 5y ago
  Lua is probably way, way faster. Does that matter? It could matter. It would be awful if it did matter, and you chose wrong.
  - MichaelMoser123 5y ago
    What would cause such a performance difference? I thought that both lua and vimscript were interpreted languages. (asking as a long time vim user, really curious about it)
    - ncmncm 5y ago
      Lua is JITed nowadays. Python has numerous design gotchas that force it to be slow. (But Numpy manages to work around many of them, and be fast.)
      - MichaelMoser123 5y ago
        Interesting. With java the just in time compiler starts to work, if you have iterated several thousand times over the same spot (java cmd line option -XX:CompileThreshold sets this, the default 10000 by default for hotspot server) Interesting if lua has a similar thing... have to learn more about it.
bitigchi 5y ago
It was the result of a poll: 1 - https://groups.google.com/g/vim_dev/c/__gARXMigYE/m/iskHVwgUCAAJ https://groups.google.com/g/vim_dev/c/__gARXMigYE/m/iskHVwgU... 2 - https://github.com/vim/vim/issues/3573 https://github.com/vim/vim/issues/3573
bitigchi 5y ago
I think he does not like to go with the flow, but instead implement things the way he thinks best suited and best performant with Vim. I don't think he cares about NeoVim.
Taywee 5y ago
Vim started in 1991. I don't know when VimL became a thing, but there's a serious possibility that Lua wasn't a great option at the time, and the only established embeddable language might have been some lisp or Tcl. I am not super versed in this area though.

by kubb 5y ago

Trex_Egg 5y ago

What is NIH syndrome? Edit: got it, its called "Not Invited Here" syndrome.

darrenf 5y ago
“Not Invented Here” is how I’ve always known it.
- deleted 5y ago
  [deleted]
- ncmncm 5y ago
  This is the correct one.
soperj 5y ago
not in house.

tyingq 5y ago

Vim and Lua evolved in similar timelines. It's plausible that vimscript was written without him knowing Lua was a choice.

capableweb 5y ago
I don't know about the timeline of Vimscript in particular, but seemingly Vim was first released in 1991 while Lua first 1993, so by the first release of Lua, Vim already existed by then. Not sure when Vimscript appeared though. On other trends (Google Trends to be specific), search volume for Lua only became larger than for Vim in 2004, with Lua hitting it's peak in 2009. Search volume for Vim would have been much larger before 2004 if we had a single search engine everyone could have used, but hard to know in afterhand I guess.
blindseer 5y ago
vim9script was most definitely written way after lua was integrated into neovim, and well well after lua was popular as an embedded programming language choice. While it is plausible that the idea for vim9script was conceived without him knowing Lua was a choice, it is unlikely that work on it was started without Bram knowing. There's even people that have commented on the google groups as far back as 2016 about neovim's use of lua. It's unlikely that Bram wouldn't have seen that.
- tyingq 5y ago
  vim9script, though, is the evolution of vimscript, and has some amount of backwards compatibility, short-ish migration guides, etc. Initially choosing an embedded script language and migrating to a new one are fairly different scenarios.
pull_my_finger 5y ago
Vim already could be compiled with Lua, Ruby, Python with their own respective vim APIs. How is it possible that he didn't know he could use an established programming language for scripting?

capableweb 5y ago

> building a new language from scratch is just not worth it Seems this has been said about every single language ever (except the first I guess?), even languages as Golang and Rust have gone through a phase where many question "why even build a new language when X does Y and Z perfectly fine already?", and then they end up really popular anyways as they solved some slice of problem(s) is a particular way that many like.

victorvosk 5y ago
Go and Rust compared to vim script is an Apples to Space Shuttle comparison.
- capableweb 5y ago
  Yes, if you compare their functionality, performance and on a bunch of other attributes sure. But I'm not doing that, I'm comparing them on the attribute of "new programming language", which all of them have been at one point or another. It might just have been that Vimscript didn't go the way it was intended to, or people moved towards different paradigms to doing modal editing in a sane(r) way, but maybe in some alternative universe, Vimscript became a popular scripting tool.
blindseer 5y ago
For every golang and rust, there's probably tens or hundreds of programming languages that will never end up popular. I guess that is to say the probablity that vim9script will succeed isn't high. And golang initially started off as a replacement for C, and then pivoted because they couldn't achieve that purpose ... now, it's touted for simplicity. When Rust was a pet project of Graydon, it looked VERY different to what it is right now. My point is that vim9script as it stands right now doesn't solve any real world use case that lua wouldn't be better suited for. Maybe vim9script will be better for something else entirely in the future, and that will be, as you describe something people may like. But right now we don't even know what that is, and surely that can't be a reason to decide to go explore language design in such a large community such as the one vim has? It is definitely Bram's right to do so, but I fear that people will rather move to neovim or vscode or emacs than learn and write vim9script, and as a user of that community I think that would be bad. Also, it's not like people were proclaiming vimscript was awesome you know. There's a talk from one of the core devs of vim-lsp on YouTube [1], on features of vimscript, and literally in every slide the presenter caveats the vimscript feature in one way or another. I find it hilarious, it's a perfect example of the frustration of when writing plugins with vimscript. [1] https://www.youtube.com/watch?v=7fcJWwl1-SU https://www.youtube.com/watch?v=7fcJWwl1-SU

thayne 5y ago

You could ask the same question about why he decided to make the async api and terminal mode incompatible with existing equivalents in neovim. Sadly, the ecosystem seems to be splitting more and more between vim and neovim.

Yuioup 5y ago
My impression is that Bram is trying his best to outcompete neovim.
- mi_lk 5y ago
  That goes without saying, and it's just unfortunate that he chooses to compete rather than collaborate
  - BooneJS 5y ago
    Competition is good, and it’s the reason why Neovim was created in the first place!
    - Tyr42 5y ago
      I mean, the reason is that those async patches were just sitting in the queue for a year, and by starting Neovim, they could get them in right away. Then Bram started competing afterwards.
      - bitigchi 5y ago
        Those patches were broken to begin with when submitted to Vim, and never got fixed until NeoVim was forked out of the blue. People generally don’t know the details of this, and blindly blame Bram.
        dolni 5y ago
        Why did it take neovim being forked to get those patches fixed?

MichaelMoser123 5y ago

Lua and vimscript are both the same age; Lua came out in 1992, and vimscript in 1991, so it would not have been an obvious choice. I think that vimscript has the same problem as shell scripts: there are a lot of editor/shell commands, and they didn't want to introduce a special syntax for distinguishing between the language proper and the editor commands. I don't think that vimscript is that bad. What i don't like about are the scope rules, i.e. special prefixes for function arguments, locals and globals. Also the call keyword is required for function calls and let keyword for assignments. Anyway, Python can be used as a vim extension language, i am not sure if Lua is superior in this respect to python.

ncmncm 5y ago
Lua is probably way, way faster. Does that matter? It could matter. It would be awful if it did matter, and you chose wrong.
- MichaelMoser123 5y ago
  What would cause such a performance difference? I thought that both lua and vimscript were interpreted languages. (asking as a long time vim user, really curious about it)
  - ncmncm 5y ago
    Lua is JITed nowadays. Python has numerous design gotchas that force it to be slow. (But Numpy manages to work around many of them, and be fast.)
    - MichaelMoser123 5y ago
      Interesting. With java the just in time compiler starts to work, if you have iterated several thousand times over the same spot (java cmd line option -XX:CompileThreshold sets this, the default 10000 by default for hotspot server) Interesting if lua has a similar thing... have to learn more about it.

bitigchi 5y ago

It was the result of a poll: 1 - https://groups.google.com/g/vim_dev/c/__gARXMigYE/m/iskHVwgUCAAJ https://groups.google.com/g/vim_dev/c/__gARXMigYE/m/iskHVwgU... 2 - https://github.com/vim/vim/issues/3573 https://github.com/vim/vim/issues/3573

bitigchi 5y ago

I think he does not like to go with the flow, but instead implement things the way he thinks best suited and best performant with Vim. I don't think he cares about NeoVim.

Taywee 5y ago

Vim started in 1991. I don't know when VimL became a thing, but there's a serious possibility that Lua wasn't a great option at the time, and the only established embeddable language might have been some lisp or Tcl. I am not super versed in this area though.