[rebootthesystem]

No, you understand just fine. VIM has developed mostly irrational cult following. It exists because it came from an era when computer keyboards were not much more than typewriter keyboards. In that context you needed to get creative in order to interact with any software. I was building and messing with computers as far back as 1978, so yeah, I lived that era. And, yes, I too wrote editors and programs that operated in similar fashion. The motivation wasn't to make it more efficient or to keep your hands on the keyboard. The mouse did not exist. All you had was a crippled keyboard.

I don't know anyone of my generation that doesn't simply laugh or look at the cult of vim and isn't perplexed by some of what proponents of the cult say. We ran as fast as we could from those kinds of interfaces once the computer keyboard developed further and the GUI took to the world. The people who had to use that shit 'cause there was no other choice dropped it like hot potatoes as soon as they could.

Here's reality from the perspective of designing, building and programming all sorts of computers for over 30 years:

If you are spending so much time typing that fractions of a second at the keyboard make a significant impact on the development cycle, you are a hack and don't know what you are doing.

Real software and hardware engineers spend far more time designing and planning than coding. Coding is the end result of a process and, in terms of time, is often dwarfed by design and debugging.

As an example, we are in the middle of a month-long process of designing a database for a project. Not one line of code has been written. Every day is devoted to database structure discussions and documentation. Once settled, the DB code might take a week to write.

We are also designing an FPGA-based board as part of the same project. Over three months have gone into research, circuit design and other tasks. The time coding in Verilog won't even compare to the effort before getting to that point.

And then there's debugging and the inevitable pivot or two.

There's nothing whatsoever an editor can do to impact this development cycle in a measurable way. We use several GUI-based code editors. Nobody here is saying "if I could only keep my hands on the keyboard for another few seconds I could...". If they did, the laughter in the room would be so loud you could measure it with a seismograph because it is so utterly ridiculous.

Do I use vim? Of course, only when I have no other choice.

[wtetzner]

> If you are spending so much time typing that fractions of a second at the keyboard make a significant impact on the development cycle, you are a hack and don't know what you are doing.

The win isn't that you saved fractions of a second. It's that your quick edit was fast enough that it didn't interrupt your thought process.

> As an example, we are in the middle of a month-long process of designing a database for a project. Not one line of code has been written. Every day is devoted to database structure discussions and documentation. Once settled, the DB code might take a week to write.

You say this like trial-and-error isn't a valid way to design something. You can spend as much time as you want designing things up front, but until you try them, there's a good chance you won't know if it's a good design. You'll always find issues later on.

Another way to look at it is this: you could write down you ideas on paper or in diagrams, or you could write them down in code, and run them to see if they make sense/work the way you think they should.

The code you write while designing doesn't have to be the same codebase as the final product. It can just be a bunch of small programs you use to help formulate your ideas.

[rebootthesystem]

Once you have enough experience you do far less trial and error. I rarely write code that does not work. By that I mean, my code generally solves the problem to be solved on the first write and is generally significantly bug-free.

That's not because I am a genius or somehow super-human, I have a lot of experience and have developed a decent process of design-before-coding. Trial and error is really wasteful. It still has it's place in areas that might not be entirely clear. Outside of that, design-before-coding can save tons of time and aggravation.

In other words, coding is the end of a process, not the process.

[wtetzner]

Ah, I think the difference is that usually when I'm working on something, it's a new problem, and I need some time to not only try to find a solution, but first understand the problem. I find that trying to write a solution helps me to get the problem space loaded into my head.

Different people have different processes, I suppose. And that's a probably a big reason for why people have different opinions on tools: they have different use cases.

[rebootthesystem]

Whatever works.

[imron]

If you are spending so much time typing that fractions of a second at the keyboard make a significant impact on the development cycle, you are a hack and don't know what you are doing.

This is a point addressed in the article.

And that’s why I don’t really care about Vim “speed”. I am not “faster” using Vim. I do not generate noticeable more code at the end of the day. But I generate it with less effort and caring more about the quality than battling with my keyboard. I am more relaxed, more in control, focused in what matters. Caring about getting stuff done. More productive. That’s Vim killer feature.

[rebootthesystem]

I think I can say with a good degree of certainty that the hundreds of editors I have used during my career so far, including vi, vim and some self-written, have been absolutely and utterly irrelevant to the success, failure, timeline or budget of any project I've ever done.

In case the question comes up. Why self-written editors? In the early days of using Forth to bootstrap embedded systems you pretty much had to write yourself a decent code editor to go with the system. I've never written an editor for other systems I've used. Whatever was available was always good enough.

[hsitz]

"Real software and hardware engineers spend far more time designing and planning than coding. Coding is the end result of a process and, in terms of time, is often dwarfed by design and debugging."

This part of your post is correct. If you don't spend much time coding then you don't have much reason to use Vim. ON the other hand, for those "fake" software guys who do spend a lot of time coding, especially editing code, then . . .

[rebootthesystem]

There have always been at least two camps in software development, and I'll throw in hardware in there due to FPGA's.

One goes to code right away and just hacks their way towards a solution.

The other camp is one where the problem is well understood first, design is done "on paper" and coding is simply the embodiment of that design process.

I say "on paper" because today it is likely to be a set of software tools such as state-machine editors, Excel, CAD, MATHLAB, etc.

It is my opinion that to write bug-free code that solves the problem efficiently, elegantly and as close as possible to on time and budget one has no choice but to design first and code as the end-result of the design process.

That's not to say that sometimes you need to write some test code as part of the design process in order to understand what might be going on. This happens a lot in embedded systems. Another scenario is web development where you need to interact with an API a bit before you can really understand how to work with it.

So I am not proposing not coding at all. What I am saying is that those code experiments are part of the "First Seek To Understand" rule (from "The 7 Habits...") that will make the project a success. The code experiments don't seek to solve the problem but rather add knowledge and understanding to the design process that will form the foundation for the actual solution.

[return0]

> irrational cult following

I am very rational thank you very much. You don't know what you 're talking about.

[rebootthesystem]

The fact that you resort to attacking the messenger just furthers the idea that, for some, vim is an irrational cult, one that has never been shown to have a measurable impact on project performance from nearly any metric.

Look, I used vi for probably a decade while working on Silicon Graphics supercomputers and Sun workstation (Irix and Solaris). I know it pretty well. If I was maintaining Linux servers full time today there would be no question that vim would be the tool to use for obvious reasons. Beyond that...it has no impact on project performance.

To be totally clear, my position isn't that vim is useless. I never said that. What I am saying is that vim offers no advantage in the context of a non-trivial project when compared with GUI-based tools from Notepad++ on up. The design and debugging process offers far more significant gains than vim ever could. In fact, I'll go farther, I'll bet that solid documentation has a far greater effect in any project metric than the negligible gains ascribed to vim.

Want to use it? Fine. Your choice. Nothing wrong with that.