Let's be honest though; vim saves you hours of work if you're already good at vim. If you're not then it'll just slow you down. It takes practice and daily use to learn. I love vim but let's not sugar coat it.
Doesn't that just mean you've selected VIM's syntax for all your IDE's? Most IDE's seem to have plugins for other popular editors.
Maybe this is a mindset issue, but I'm having a hard time imagining how one would want to just get the work done, without trying to pick up a skill in the process.
Despite the current UX trends of dumbing down software, it's rare you'll use a tool just once in your lifetime.
My wife has used SublimeText and Notepad++ for total of maybe 10 hours in her entire life. I'm not suggesting her to learn Vim (or Emacs), because the kinds of tasks she does with computers don't benefit that much from a proper text editor. However, most developers spent inordinate amount of time editing plain text files, and a lot of tasks they do in other tools - like task management, time tracking, documentation writing, drawing diagrams, commenting on StackOverflow - could receive stupidly huge efficiency improvements by being done in plain text too. Vim and Emacs are the two tools that are dedicated for precisely this class of problems. In my opinion, the couple dozen hours one has to invest over the course of a month to get some basic proficiency in them is worth the across-the-board payoff in work speed and comfort.
--
One trick I've learned is being explicit and deliberate about learning. To things like learning a new piece of software, recursive Pareto rule applies - 20% of time gives you 80% of value. 4% of time gives you 64% of value. So, say you're willing to entertain the thought of learning a little bit of Vim. Allocate a single pomodoro to it right now, and fire up vimtutor. 25 minutes, full focus. You'll notice it only takes a few minutes to break through your own habits and learn the basics of a new interface. You'll be impressed by how much you've learned in just 25 minutes[0]. Next step: commit to 5 hours over a week. 10 pomodoros. Find some introductory tutorials, and work through them this way.
Personally, I did above trick a couple of times to learn new Emacs features. Getting comfortable with multiple cursors, or with paredit, are things that turned out to take 1 or 2 pomodoros, and have been improving my editing speed and comfort for the past couple years.
--
WRT. mindset, a proper one can smooth out the learning curve quite well. The most basic trick that I see even developers not recognizing is this: every time you click on a button in your program, figure out if there's a keyboard shortcut for it. If there is, try to use it instead. Soon, you'll find yourself working much faster and comfortable than before.
--
[0] - though you'll lose half of it in a day. Committing new skills to long-term memory takes more time and exposure; muscle memory takes even more. Good news is, this happens pretty much by itself, as you apply the new skills to the tasks you're doing.
Most people don't want to put in anything more than 40 hour work week these days. Which also means no time to learn and upgrade your skill set. That is for doing their everyday tasks.
Now selling vim or emacs to this set of people would never work for one reason. They just can't get themselves to spend that time.
That's also a big reason why people hate Nerds. These people spend to get better at things in a way we don't want to.
And truthfully, the productivity wins for me weren't so much tied into being able to input text at a faster rate with Vim.
It was being able to leverage Vim itself to help me rethink and reshape how I organize large amounts of structured text, which saves a lot of time and headaches when dealing with files. Plus there's other wins too with limelight and video editing (an added bonus).
I'm still not 100% as fast as I was with VSCode for inputting and editing text but after 2 weeks of using Vim, it's not a complete train wreck anymore. It was brutal for days, but it's slowly getting better.
Bonus points for using it in mutt for all electronic correspondence.
Also, why the Dickens are you using Windows when your heart clearly yearns for a nice native i3 setup?
That was explained a few weeks ago in this post:
https://nickjanetakis.com/blog/i-tried-linux-as-my-main-dev-...
Ah OK. Haven't had that myself, even using USB audio interfaces in a similar fashion, so I wouldn't put that down to Linux. I use monitor speakers and have good hearing and definitely not getting those issues with a simple pulseaudio setup. I flick between youtube, cmus, recording on my old Zoom H2, audio from a VM etc. so have run the gamut of opportunities for it to pop and click.
Sounds like you had to spend a lot of time troubleshooting and in the end thought it wasn't worth the fight. I hear you, but I would see if I could borrow another audio interface from a store or contact of yours before giving up on OS-freedom for good. The Scarlett is an entry-level device anyway, known to have dubious build quality. I'd also take it up with the manufacturer before looking for more fixes.
Good luck!
After I finish this next course I will try again with a different distro, and then see if my other USB mic that worked on the Chromebook (running native Linux) also works on my main machine.
It's a lot of fun and I really can't go back.
Some people find even an iPhone too complicated, others don't mind reading the manual for a minute. For some users Vim just makes sense, while certain people will struggle with saving files in Notepad because they think a specific button is at the wrong place and refuse to learn it any other way than they imagined.
> I still get frustrated setting up a new computer
Why is that? Setting up Vim is the easiest task for me, it's literally just a matter of copying some files.
A mindset that is suspiciously similar to an engineer's. :P For example, you need the user to memorize the fact that all the configs are in a ".vimrc" file in their home directory. Oh and since it's a dotfile they might not see it immediately. And then if they want to add custom shortcuts they need to learn exactly how the syntax works, the different "modes", the types of remaps, etc. It's a horrible experience for a non-engineer.
> Why is that? Setting up Vim is the easiest task for me, it's literally just a matter of copying some files.
I have a lot of plugins (e.g. syntax highlighting, linting, and autocomplete for different languages), and each of those can have their own dependencies that they require you to install before they'll work.
I tend to use the example of a car in these topics, but I have a better one: a coffee maker. There are numerous non-obvious things one has to learn about coffee makers - like how to apply a water filter, and what kind to buy. Like the symbols that mean "not enough water", "not enough coffee", "dredge drawer full", and what to do when they show up. Somehow, I never see anyone complaining about this - because there's a social expectation that people can and should figure this out. The coffee machine comes with a small booklet explaining all of this in pictures and a dozen languages.
Yet somehow, with software people think that the UI should just have a button labeled "get my job done", pressing which will get their job done. It's a really broken mindset, because it's impossible (or rather, it's an AI-complete problem) to have software like that.
People complain about that, because they think things should be handled and explained within the machine itself. I don't complain about coffee machines, but I agree with the principle. If I have to go searching through manuals to figure out what actions I need to take to get something working, that piece of software has failed at user interface design.
Sometimes it's ok to fail at UI. I don't expect everything handed to me on a silver platter when I'm writing a bootloader for an 8051, but I do expect my tools to be reasonably user friendly. Vim isn't user friendly, and that understandably drives people away. Hell, even emacs can be a pain to work with.
A HUGE problem with developers learning VIM is that they think they have to go from 0 - 100 immediately when you can adopt VIM gradually and still see noticeable efficiency increases.
That iterative process is exactly what I'm talking about. It's taken years to develop my vimrc, because starting with a "prebuilt vimrc" means that you don't really understand what is pure vim, what's custom, and what issues you might run into because of those custom settings conflicting with new plugins.
Obviously there can be snags on the road and things get more difficult the more complicated things you want to do, but learning the basic keybindings and being able to efficiently edit files with vim just isn't that hard.
I would say vim is easier to configure than, for example emacs
But still, I have a lot jotted down. Mainly the hotkeys, but also things just to remind myself that a feature exists (like * to highlight the current word).
The premise of the article is that the VIM is better enough than alternatives that it's worth the learning curve. Just like a drill is better enough than a screwdriver to learn ho to use it. If you want to contest that, that's a different discussion.
If your argument is, "some people don't have the energy to use the best tool for the job"... idk how to respond to that.
If you go far enough, you can cause the analogy to break down, but that's true of any analogy. This breaks down because the ROI for a drill is too short to compare with Vim.
And trends go around in IT just like any other field. So before someone jumps into vim to save themselves hours of work they should know that it requires practice use to use well.
I wouldn't say I am learning Vim due to it being a trend. I'm learning and using it based on problems I discovered using other editors to write books and courses.
You can use it to visually warn you that your git commit is going past a certain amount of characters. Basically it can help you create better git commit messages.
But if you hate it and are on a Unix-like environment you can export EDITOR="nano" in your profile and now git should use nano instead. I think there's a git specific setting you can set too if you don't want to do it system wide.
This approach is especially nice when there are great vim keybindings for things like Visual Studio. The only thing you have to learn to start using vim is to always pay attention to if the cursor is a block or not, and if it is, remember to hit "i" before you mash keys if that's not what you want.
It not only has menus, but the shortcuts on the right side of each menu item aren't special - the they're the same commands you'd just type into vim normally. I picked up a bunch from those, but in particular I remember folding being one I didn't even know existed in vim until using it in one of the menus.
Anything you're not good at it is going to slow you down. The question is that even tho you might be slow, if you put in the effort, learn it then get good, will the savings and speed up make up for the initial slow down?
I'm a vim fan and won't try to convince others. But I personally believe that the answer is yes. One of the secret to being successful with vi is that of mindset. You need to have a positive mindset that it's worth learning, you need to commit to learning it. I learned vi when network speed was very slow and systems didn't have enough memory. It was faster than any other editor. So I had the mindset that I needed to learn it. if I was starting out today, it probably would be hard when you have editors like vscode.
I have typed and used computers everyday for 25 years non stop and I have no issue with my fingers and I believe a major part of it is using vim and my fingers not having to travel and move out to find a mouse or hitting Ctrl+ keys.
And even if we're talking about 20% of your time, improving that 2-10x is nothing to shake a stick at. 20% of 10 hours is 2 hours, if Vim makes you edit 2x faster, that's 1h saved, per day. And that's without accounting for other work you could move to your suddenly more efficient plaintext mode, and the work you don't even consider doing because your editing experience is too painful (it sometimes work the other way too; there are things I won't do in Emacs, but I will in IntelliJ, where project-wide, language-aware refactors can be done with two clicks in full confidence that nothing will break).
Vim still isn't my exclusive dev editor, but it has almost become my exclusive terminal editor. Learning older technologies may not always be top priority, but it can do a large amount to enrich your personal perspective- particularly if you discover the niche where its usefulness is best utilized (and like you mentioned, if the amount of time to get up to speed will save you proportionate future time).
The main downside is that you don't learn things like window managing, file exploration, etc - mostly because other editors are already good at that, and it's not something plugins focus on.
The thing is, vim forces you to do a lot of stuff that the machine could do for you. E.G: you need to remember states and how to transition between those states. Plus the human mind sucks at context switching.
All in all, this adds up, and there is a limit to the cognitive load you can accumulate. You only have one brain and you need to share it between all tasks, including solving the problem at hand and using tools to do so.
Half of my income comes from training professionals on site. Experience taugh me that every time somebody uses vim, 4 things will happen:
- the person will be one of the best of the team
- the person will have some weird bug/config problem/compat issue at some point and will waste time fixing it at least once during the training, swearing it never happens (also the person with vim usually has a very custom setup so this compounds)
- at the end of each day, the person will be one of the most exhausted, and will make way more mistakes than the others compare to the morning baseline
- at equal technical level, the person with vscode/sublime/jetbrain will be faster on average. Maybe not the first hour. But it will come.
So, yes. Vim may be fun. It may suit your workflow and ecosystem, and even your sense of aesthetic. But I don't buy the productivity boost.
For example, let's say you want to put the cursor next to a specific word in a sentence.
If you use the mouse, now you need to stop writing, goto the mouse, find your mouse pointer, look at the mouse pointer, then move the mouse to the word you want to be at, click the mouse and start typing again.
I'm an avid gamer. I'm super used to this. I can move my mouse at pixel precision and do it very quickly, but even if it's fast, it's still a context switch.
With Vim, it almost feels like Vim itself is another input device that's almost a mind control device. I can just direct my eyes to the word I want to move to, hit 3 keys and then have my cursor jump directly to it (by using vim-sneak and pressing any 2 characters of the word).
Even if doing this is only equal speed to the mouse, it's still a win in my book because it feels less of a context switch. Plus if you want to talk about mistakes, looking at the word you want to jump to instead of your mouse cursor forces you to look at the word, so you have 1 more chance of avoiding a spelling mistake -- although to be fair, most editors including Vim can visually show you these errors.
wow, that's pretty cool!
With vim being on every system, i don't really carry much baggage around. I have my vim settings file in cloud storage. And maybe one pluggin (NERDTree) on my main machine.
I'm not even waiting on people with Vim problems anymore during the lectures. I just go on, they will catch up.
I believe that there may be some post hoc, ergo propter hoc at play here.
For instance did you include the age of the persons in your observations? It wouldn't be surprising that the persons choosing vim are a bit older on average, and then one could think that they have a bit less stamina and are exhaust faster?
Or maybe they are actually doing more, like spending part of their energy helping others? That's also a pattern you can see often in group training sessions.
Also, you mentioned that you won't help them with the "weird issues" they usually have with vim. Do you apply the same treatment to non-vim users?
That being said one person's anecdote supporting a highly subjective opinion deserves to be torn to shreds without ample evidence or at least better context.
I don't think that makes any sense at all. If anything Vim does a lot for me because it's programmable. When doing heavy editing, the whole point is the automation does the heavy lifting.
Switching modes doesn't have any cognitive load effects that I can notice. The cursor changes the shape for example, so you instantly know what to do. It's pretty much second nature.
What you're describing is a novice or clumsy Vim user. I don't know what "compatibility problems" should have a text editor, but I haven't had any in many years.
> So, yes. Vim may be fun. [...] But I don't buy the productivity boost.
Kind of condescending, really. Thinking that Vim is a toy and all users are using it for the heck of it, when they could be more productive otherwise.
Even if the correlation is real, there's just no way that difference between using vim and using something else is so great that it's causing people to exhaust themselves, so best case scenario there's some hidden variable causing it.
Give me VS Code with the Vim plugin and I'll code circles around someone using the standard controls simply because it takes so little effort to do most complex things and if a mouse actually makes things faster, I can use that too.
The right education is: vimtutor (type it in your CLI and within 30 minutes you're done).
I deleted my rant but I dare anyone to take my challenge: do vimtutor for 30 minutes and then answer the following question twice (before vimtutor and after it) in a comment.
I perceive vim to be difficult:
(1) strongly disagree, (2) disagree, (3) agree, (4) strongly agree.
Once you know the basics of vim, then it won't slow you donw.
Well I just discovered a new thing to do over the next 25-30 minutes
Beyond this, see also the tour over the basics here: https://www.gnu.org/software/emacs/tour/.
That's what it did on my first run. It indeed wasn't perfect, but there were already a couple of tricks that I've learned that I really liked and that's what you get out of it.
I'm not saying you work faster, I'm saying after vimtutor you won't work slower.
I suppose you still work slower if you compare it to your favorite text editor, I'm not very strongly proficient in any text editor, which is why I'm not noticing slow downs.
Buffers, windows, autocomplete, files browsing, all of that requires you to dig around the help files and the web.
You have to get down to hunt-and-peck until you see typing ability actually affect productivity (and I have seen those people). If you can touch type using any keyboard layout, though, then typing speed won't be a meaningful limitation for you.
That being said if I anybody reading this is tempted to switch away from QWERTY towards a more ergonomic layout I'd suggest looking into Colemak, it's supposed to be at least as ergonomic as Dvorak while being closer to the standard QWERTY layout.
I suspect Colemak is better, but it's a much smaller gain going from Dvorak to Colemak than from Qwerty to Dvorak, so I'll stick to what I have. Otherwise I suspect Colemak is better than Dvorak when switching from QWERTY.
Yeah I'm in the same boat, that's why I was mainly aiming my comment at people using QWERTY and looking to switch to a better layout. Even the Colemak people acknowledge that:
https://colemak.com/FAQ#Is_it_worth_switching_from_Dvorak_to...
> The Colemak keyboard layout fixes all the issues mentioned above, and wins in virtually every criterion, but the difference will be less noticeable than the difference between QWERTY and Dvorak. The switch won't be as easy for veteran Dvorak users. If you're generally happy with Dvorak, you should probably stick with it.
The FAQ also has an interesting list of "what's wrong with the Dvorak layout" which might be of interest for people looking to learn it: https://colemak.com/FAQ#What.27s_wrong_with_the_Dvorak_layou...
Layout switchers have some bias here because they don’t type as well in QWERTY anymore or they didn’t touch type QWERTY.
When I'm writing something that doesn't require a lot of cognitive overhead (typically chatting online, when I may have a lot to say but it's not particularly intellectually demanding and doesn't require a lot of precision or proofreading) I can reach pretty high WPMs.
I'm not convinced that typing speed is always brain-bound outside of typing tests. If I'm telling you about my day at work I'm pretty sure I can just "stream-of-consciousness" directly through the keyboard with very little overhead, especially if I do it in my native French.
I was trying to talk about comfort difference between keyboard layouts anyhow, not the speed difference.
Given the same proficiency level of QWERTY and Dvorak/Colemak, comfort difference would be more noticeable for high intensity / little breaks / long duration activity like typing tests.
Are alternative keyboard layouts significantly more comfortable for practical tasks? I’m skeptical. (Most enthusiasts already agree they aren’t really faster).
It's not about speed. Sure, some people say it's about speed, on either side of the debate, but I'm not a faster typist, nor a faster editor, nor would it matter in my profession (coding.)
It's about ease of use.
Once you're used to them, these tools save you (cognitive) overhead. Dvorak doesn't tire out my wrists (subjective, but I switched away from Qwerty&Emacs after developing RSI when writing larger technical documentation. Never had the same problem with Vim&Dvorak, even when writing frantically day and night on my thesis.) And Vim allows me to navigate text easily. It's not about speed. It's about intuitively navigating to something quickly, without having to think about it, and to stop and completely upend my current focus because I have to hunt & peck for something with my mouse.
Oooops!
I've changed my keyboard layouts in the past. My conclusion: there's value in standardization.
Colleagues have a switch. setxkbmap -option compose:ralt or whatever your DE wants you to use.
From the person you replied to
> Never had the same problem with Vim&Dvorak, even when writing frantically day and night on my thesis
Most of the graduate students I've knew spent a lot of time working alone, and had at some point to type a lot of things already clear in their head meaning ease and speed of typing was a very important factor, keyboard sharing not so much.
And then I've observed the same things as you, it's really annoying working at the desktop of my colleagues using non standards keyboards.
So, really, it's all dependent on context, and as usual there's a right tool for a given job. Kudos to both of you for coming to correct conclusions in your given environments :-)
I decided to stay with qwerty at work because I want a colleague to be able to work on my system, and switching keyboard layouts multiple times per day only causes me to type gibberish more often. And as you say, there is value in standardization.
If you switch machines so often you can't keep up with moving your customizations between them, by all means, learn just the defaults (but do learn them - e.g. whatever the "standard" editor IDE, learn the keyboard shortcuts). As for pair programming, switching keyboard layouts and opening a project in a different editor/IDE takes only a small fraction of the time your colleague will spend in front of your machine.
I'm not lying, co-workers think you are a god damn wizard. I try not to be a doosh, but I have one co-worker who loves VIM but doesnt really use it (insert mode ftw). Whenever I can i try to subtly drop hints. "Instead of hitting the arrows keys over and then backspacing, you can type cw to change the word" Just little things like that. Once you realize that vim is modular and chainable, you really start to take off!