Comment by 29athrowaway | Hacker News Reader

Comment by 29athrowaway | Hacker News Reader

Parent Full thread

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.

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.

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.

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.

Most nvim plugins are written in lua.

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.

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?

> 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!

> because even though you could integrate LSP, a linter, etc... a lot of them don't.

I think you overestimate the amount of work needed to get these things working… With Vim, for example, you can install a single plugin “ALE”, and it will autodetect and integrate every known LSP server, linter, and formatter that is in $PATH. For Emacs, you won’t even need a plug-in: “Eglot” is included in Emacs itself, and autodetects and integrates LSP servers in $PATH when you turn it on. Turning it on can be done by clicking a discoverable menu bar item.

> 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

This is a bit of a stretch, isn’t it? If a single dev turning off their linter can cause millions of dollars worth of problems and bankrupt your family, then your org has deeper problems.

This has always been the problem. It takes one faulty line of code to bring down the entire planet and you know it.

My position would still be that:

- If you’re working on critical code where one wrong line can bring down the planet, it is your organization’s responsibility to adapt. This means thorough testing before you roll it out to production, code review, etc.

- If you’re convinced that linting, testing, etc. is essential to prevent calamities, it shouldn’t be up to individual developers IDE choices to use these. Then it’s again up to your org to centralize and mandate those tools, e.g. by adding autoformattets, linters, and test coverage checks to their Git precommit and code review. This is an organizational issue.

- If we take a step back from these calamities, and claim that an IDE just makes people more efficient… Isn’t it again up to your org to promote and pay the efficient developers more, and gradually the top positions will be filled with IDE users and that becomes the company culture if your hypothesis is right?

In any case, I strongly disagree with your angle that not using an IDE is “irresponsible”. I have my reasons for sticking with a terminal-based workflow, but respect and understand why other people might find an IDE better.

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.

You can map most actions in an IDE to a key combination.

And IDEs have integrated terminal panes as well.

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

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.

> 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!

Still better than the circular arguments like vim is faster because vim is faster.

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.

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.

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.

Does your team have required code reviews? This might help reduce production incidents

- sent from my terminal

Checks running on continuous integration is the mitigation for not having used a linter during development in this case.

The linter feedback would take longer to get back to the developer though, increasing the "cost of change".

What does the choice of editor have to do with whether you run tests?

Reply on news.ycombinator.com