3 ms·

I believe that your toolchain should be doing work for you, not the other way around. A toolchain should also be discoverable and well documented. A toolchain

I believe that your toolchain should be doing work for you, not the other way around. A toolchain should also be discoverable and well documented. A toolchain should also be complete: - editing - syntax highlighting - syntax validation - linting - building - testing - profiling - debugging - searching - documentation - version control Optionally also - deploy - inspect logs You can do a lot of work and testing to these working correctly, install a "distribution", or you can simply use an IDE. You can argue that you can do all these things with plugins, but plugins do not follow unified guidelines and the result can be an inconsistent experience like the Dwarf Fortress menus. A TUI editor with many plugins installed isn't necessarily faster than an IDE. Languages like vimscript are interpreted, not compiled. And many implementations not always take advantage of multi-threading capabilities. Among the distribution of TUI editor users, only a small subset of users can get their toolchain to be ergonomic, complete and work correctly. The rest just have a minimal experience that just gives them more work to do and that places a quality handicap on them. How do you read profiler output in your TUI editor? or show test coverage? or run a specific test case in a test file and get a test report? 99.9% of the time the answer will be "Well, I haven't set that up yet...but look at this multiple cursor trick!". And the median skill level TUI editor user often hasn't even set up a linter or something like LSP integration. What TUIs are excellent for, in my opinion, is to encourage an immersive experience that's distraction free. But now many IDEs have distraction free modes. They can be good for customization (which can even result in customizations that make your work more difficult), although IDEs have SDKs that are not hard to use and many plugins are open source. TUI editors are also more compatible with working on remote hosts. Now, through customizations you could in theory create a universally superior development experience compared to what IDEs offer, but that is yet to be seen. Only in some aspects TUI plugins have achieved this level of excellence in specific areas, like Magit for emacs.

c-tb 2y ago
the problem with that mindset though, is if you don't want several of these features. or you use a variety of languages and tools where the common interface is the terminal. i work professionally in Kotlin so i would never use vim over IDEA over that. but getting all sorts of other languages working in something as bulky as IDEA is a huge pain and not generally worth it. for the longest time (pre-LSP), my non-kotlin dev experience was just vim-polyglot and running watch - build in a :vsp and it gets you far.
drawnwren 2y ago
This reads like the sort of academic engineering that I hate working around. You ask great questions for research, but the truth of the matter is quite simple. You can just open both editors next to each other and ask how they are. For me, it's trivial to see that vim is at least an oom faster than VSCode. I don't need to profile or show test coverage. I can just use it and it works. Even if they were about the same speed, the less-than-perfect vim mode implementation always takes too much time out of my editing flow. Occasionally, an ide will have such a great curated experience that I'll use it for something specific -- but the general case is a no contest for me.
- 29athrowaway 2y ago
  The vimscript implementation doesn't have many of the innovations of modern scripting languages. No JIT, pretenuring, inline caching, etc. All your "one OOM away from VSCode" scripts run in a script language that is in the slowest category among all programming languages: interpreted languages. There are probably millions of dollars invested in making scripting languages like JavaScript faster, but that's not the same case for vimscript. Same applies to other languages behind IDEs such as Java. So that intuition is not true. With hardware accelerated widget toolkits, the TUI advantage is not necessarily true either.
  - ibotty 2y ago
    Most nvim plugins are written in lua.
  - drawnwren 2y ago
    Yeah, I'm not arguing whether that's right or wrong. It just doesn't matter. Vim is objectively faster. I don't care how many millions of dollars or pl optimizations my editor has. I care how quickly it works.
vincentkriek 2y ago
I usually doubt about this, am I missing out on useful tools because I like my terminal based environment. Editing is much better when you have tools that are keyboard first, I think everyone agrees about that. My conclusion now about an integrated environment (like an IDE) versus a more handbuilt (like vim) is that a handbuilt one requires the dev to know it's tools. With an IDE you are seduced to trust the magic black box, that the box will help you. This makes it that when stuff goes different then expected (usually user error), you are lost. With a more custom environment you are pushed to learn your tools. And while this is not a given, I like this approach more. I might miss some fancy new tools, but the tools I do use, I *know*. This could be done with an IDE but is more forced in a terminal based flow.
- 29athrowaway 2y ago
  You can map most actions in an IDE to a key combination. And IDEs have integrated terminal panes as well.
  - vincentkriek 2y ago
    Never said it can't be good in an IDE. But there is something that draws people to vim, which isn't just the cool factor. IDEs often even have vim modes but vim itself is a nicer editor. Same way an IDE is a nicer debugger, linter, profiler, test run platform...
eikenberry 2y ago
The primary mistaken assumption you've made (though some TUI users also suffer this) is that the TUI is the integration point (the IDE) and that is not the case. Text editors, like Neovim, are are only the editor part or component of the IDE, your terminal shell environment. The shell has had decades to refine its place as the integration point for development. It works very well and keeps closer to the classic, do one thing and do it well, mentality. This has many benefits that don't translate well to GUI IDEs as they just can't match the flexibility and maturity of the shell ecosystem.
- 29athrowaway 2y ago
  We can all agree that the UNIX philosophy is powerful. Having a uniform interoperability mechanism (e.g.: stdin/stdout/stderr, exit codes) helps integrate different tools easily. I use shell commands to get things done often. But that doesn't necessarily negate what I said: having a complete toolchain with a complete set of capabilities is the end goal. How you achieve that is means towards an end. If you achieved it with a TUI editor, good. But there's a subculture in the TUI editor world where the end goal is often the prestige of being a TUI editor user rather than how capable the tooling makes you. And the situation in the wild is that most of these TUI users have a sub-optimal development experience that causes them to push more defects, because even though you could integrate LSP, a linter, etc... a lot of them don't. With respect to when vim was invented, you have a supercomputer now. You may be solving a performance problem you don't have. If editing with a minimal experience is a deep part of who you are, yet you are not going to pay for the cost of detecting and correcting preventable problems which can cost the company thousands to millions of dollars... maybe you are not acting in the best interest of your development org, your colleagues, your career or your family even. What do we call a person that exhibits that behavior?
  - jclulow 2y ago
    > the situation in the wild is that most of these TUI users have a sub-optimal development experience that causes them to push more defects What an amazing pile of unsubstantiated horsefeathers!
  - 2y ago
sodapopcan 2y ago
> 99.9% of the time the answer will be "Well, I haven't set that up yet...but look at this multiple cursor trick!" Ah yes, the classic "takedown" with the invented statistic about what people "probably" haven't done while "probably" focusing on something less important. Bravo. Side note: most Vimmers don't use multiple cursors... it's 99.9% of them, I believe!
- 29athrowaway 2y ago
  Still better than the circular arguments like vim is faster because vim is faster.
  - sodapopcan 2y ago
    It’a not better, they are both worse. The best editor is the one you know. I also know lots of people who use IDEs and don’t use most of their features.
    - 29athrowaway 2y ago
      If we have a test or a linter that prevents a problem, that runs in a couple of milliseconds, and you didn't run it because you are too cool to run it, then we are no longer talking about subjective preferences about tools. We are talking about responsibility. If your code caused data loss on production because you are LARPing about being a hotshot instead of adopting the processes that keep the code running I don't care how fast your editor is.
      - sodapopcan 2y ago
        Lol, you're exactly who I'm complaining about. I do agree with you: I also dislike people who don't learn their tools and don't do the things you're talking about. But just because you're using an IDE doesn't mean you're going to use all of its features. Conversely, if you're going to use a text editor, you absolutely have to ensure you have that stuff.
      - 12345hn6789 2y ago

c-tb 2y ago

the problem with that mindset though, is if you don't want several of these features. or you use a variety of languages and tools where the common interface is the terminal. i work professionally in Kotlin so i would never use vim over IDEA over that. but getting all sorts of other languages working in something as bulky as IDEA is a huge pain and not generally worth it. for the longest time (pre-LSP), my non-kotlin dev experience was just vim-polyglot and running watch - build in a :vsp and it gets you far.

drawnwren 2y ago

This reads like the sort of academic engineering that I hate working around. You ask great questions for research, but the truth of the matter is quite simple. You can just open both editors next to each other and ask how they are. For me, it's trivial to see that vim is at least an oom faster than VSCode. I don't need to profile or show test coverage. I can just use it and it works. Even if they were about the same speed, the less-than-perfect vim mode implementation always takes too much time out of my editing flow. Occasionally, an ide will have such a great curated experience that I'll use it for something specific -- but the general case is a no contest for me.

29athrowaway 2y ago
The vimscript implementation doesn't have many of the innovations of modern scripting languages. No JIT, pretenuring, inline caching, etc. All your "one OOM away from VSCode" scripts run in a script language that is in the slowest category among all programming languages: interpreted languages. There are probably millions of dollars invested in making scripting languages like JavaScript faster, but that's not the same case for vimscript. Same applies to other languages behind IDEs such as Java. So that intuition is not true. With hardware accelerated widget toolkits, the TUI advantage is not necessarily true either.
- ibotty 2y ago
  Most nvim plugins are written in lua.
- drawnwren 2y ago
  Yeah, I'm not arguing whether that's right or wrong. It just doesn't matter. Vim is objectively faster. I don't care how many millions of dollars or pl optimizations my editor has. I care how quickly it works.

vincentkriek 2y ago

I usually doubt about this, am I missing out on useful tools because I like my terminal based environment. Editing is much better when you have tools that are keyboard first, I think everyone agrees about that. My conclusion now about an integrated environment (like an IDE) versus a more handbuilt (like vim) is that a handbuilt one requires the dev to know it's tools. With an IDE you are seduced to trust the magic black box, that the box will help you. This makes it that when stuff goes different then expected (usually user error), you are lost. With a more custom environment you are pushed to learn your tools. And while this is not a given, I like this approach more. I might miss some fancy new tools, but the tools I do use, I *know*. This could be done with an IDE but is more forced in a terminal based flow.

29athrowaway 2y ago
You can map most actions in an IDE to a key combination. And IDEs have integrated terminal panes as well.
- vincentkriek 2y ago
  Never said it can't be good in an IDE. But there is something that draws people to vim, which isn't just the cool factor. IDEs often even have vim modes but vim itself is a nicer editor. Same way an IDE is a nicer debugger, linter, profiler, test run platform...

eikenberry 2y ago

The primary mistaken assumption you've made (though some TUI users also suffer this) is that the TUI is the integration point (the IDE) and that is not the case. Text editors, like Neovim, are are only the editor part or component of the IDE, your terminal shell environment. The shell has had decades to refine its place as the integration point for development. It works very well and keeps closer to the classic, do one thing and do it well, mentality. This has many benefits that don't translate well to GUI IDEs as they just can't match the flexibility and maturity of the shell ecosystem.

29athrowaway 2y ago
We can all agree that the UNIX philosophy is powerful. Having a uniform interoperability mechanism (e.g.: stdin/stdout/stderr, exit codes) helps integrate different tools easily. I use shell commands to get things done often. But that doesn't necessarily negate what I said: having a complete toolchain with a complete set of capabilities is the end goal. How you achieve that is means towards an end. If you achieved it with a TUI editor, good. But there's a subculture in the TUI editor world where the end goal is often the prestige of being a TUI editor user rather than how capable the tooling makes you. And the situation in the wild is that most of these TUI users have a sub-optimal development experience that causes them to push more defects, because even though you could integrate LSP, a linter, etc... a lot of them don't. With respect to when vim was invented, you have a supercomputer now. You may be solving a performance problem you don't have. If editing with a minimal experience is a deep part of who you are, yet you are not going to pay for the cost of detecting and correcting preventable problems which can cost the company thousands to millions of dollars... maybe you are not acting in the best interest of your development org, your colleagues, your career or your family even. What do we call a person that exhibits that behavior?
- jclulow 2y ago
  > the situation in the wild is that most of these TUI users have a sub-optimal development experience that causes them to push more defects What an amazing pile of unsubstantiated horsefeathers!
- 2y ago

sodapopcan 2y ago

> 99.9% of the time the answer will be "Well, I haven't set that up yet...but look at this multiple cursor trick!" Ah yes, the classic "takedown" with the invented statistic about what people "probably" haven't done while "probably" focusing on something less important. Bravo. Side note: most Vimmers don't use multiple cursors... it's 99.9% of them, I believe!

29athrowaway 2y ago
Still better than the circular arguments like vim is faster because vim is faster.
- sodapopcan 2y ago
  It’a not better, they are both worse. The best editor is the one you know. I also know lots of people who use IDEs and don’t use most of their features.
  - 29athrowaway 2y ago
    If we have a test or a linter that prevents a problem, that runs in a couple of milliseconds, and you didn't run it because you are too cool to run it, then we are no longer talking about subjective preferences about tools. We are talking about responsibility. If your code caused data loss on production because you are LARPing about being a hotshot instead of adopting the processes that keep the code running I don't care how fast your editor is.
    - sodapopcan 2y ago
      Lol, you're exactly who I'm complaining about. I do agree with you: I also dislike people who don't learn their tools and don't do the things you're talking about. But just because you're using an IDE doesn't mean you're going to use all of its features. Conversely, if you're going to use a text editor, you absolutely have to ensure you have that stuff.
    - 12345hn6789 2y ago