Well yeah, vim is just a bunch of niceties on top of vi, like syntax highlighting, scripting, and whatnot. Most of the actual commands I use also exist in vi, and I often don't bother installing vim for a one-off project on a remote server (on some systems, it's not just vim, like FreeBSD).
My only problem with vim is that it's just an editor, and scripting it kind of sucks. I don't usually need more features (I only have a few non-syntax plugins), but it's just not a good fit for opinionated platforms, like mobile development. I've tried vi mode on IDEs, but there are always missing features, and setting up commands in vim or scripting deployment is a bit of a pain.
Vi(m) is a second-class citizen these days because people don't bother actually learning the software they use upfront, but instead expect the software to be intuitive. This isn't a problem, it's just a different approach that limits the design space for highly productive tools.
>Vi(m) is a second-class citizen these days because people don't bother actually learning the software they use upfront, but instead expect the software to be intuitive. This isn't a problem, it's just a different approach that limits the design space for highly productive tools.
I don't really get that sentence. Software can be both intuitive and lead to productive usage. There are all kinds of productivity enhancing tricks in Sublime Text or VS Code, yet you can just open up an instance, start typing, save normally, and exit, notepad style. In fact, I'd argue that time spent learning about "modes" or how to actually type text (or even exit, see https://twitter.com/iamdevloper/status/435555976687923200) in a text editor counts as time not being spent productively. "Yes but you'll be so much productive once you've learned all the tricks", you retort. But why should I bother learn tricks in vi(m) when there are plenty of those in Sublime Text and I can use it intuitively? They aren't mutually exclusive, and the benefits of being "super-productive in vi(m)" as opposed to "super-productive in ST/VSCode/Atom/etc." are murky at best. It's not like latex vs. Word or git vs. subversion where there are tangible benefits to using the former (i.e. superior design choices lead to your being able to to things in one that you wouldn't be able to do in the other).
When I was younger, you were expected to read the manual before getting into the software. The manual gave a lot of helpful tricks to use the software effectively, and users often had a better grasp of what it was capable of.
These days, people seem to have no patience for learning their tools. Many (most?) of my co-workers learn through someone else showing them some feature instead of learning it through a natural process of using the built-in help. People seem to assume that if it's not painfully obvious, the software probably can't do it. With him, I know it's probably capable of doing what I want, so I'm accustomed to searching the documentation to automate a repetitive task.
I'm not saying that being intuitive is bad, and it's certainly the right choice for the majority of software. I'm saying that for power tools, you can often end up with a more efficient tool if you require the user to put in some effort at the outset.
I think the problem with this is it assumes that there is something inherently intuitive about notepad-style editing, rather than the style coming from a bunch of historical accidents (how typewriters work, etc).
I'm not going to argue that vim is intuitive (I think it is, but regardless), I think it would be sad if we reified last-centuries' 'practical' into this centuries' 'intuitive'. You'd end up with everybody working through a bunch of really weird historical anachronisms, jumping hoops to satisfy design limitations that haven't existed for centuries.
What I mean by 'intuitive' is that if I show notepad.exe to my mother, she can easily open up the program, start editing text, save, and quit. The cognitive load to assimilate first hand is very low. On vim, to even get started with anything in the first place, you have to learn about 'modes'. You also have to learn about special commands about the most basic things like saving or exiting. This has nothing to do with typewriters that my mother never used.
I’ve been using vi since 1992, and I _still_ learn interesting new things about it pretty regularly. That’s what I love about it - you’re never really finished learning it.
My only problem with vim is that it's just an editor, and scripting it kind of sucks. I don't usually need more features (I only have a few non-syntax plugins), but it's just not a good fit for opinionated platforms, like mobile development. I've tried vi mode on IDEs, but there are always missing features, and setting up commands in vim or scripting deployment is a bit of a pain.
Vi(m) is a second-class citizen these days because people don't bother actually learning the software they use upfront, but instead expect the software to be intuitive. This isn't a problem, it's just a different approach that limits the design space for highly productive tools.