Why do you recommend VIM, vs. IDEs that make beginners far more productive?

[dandv]

In this answer, you recommend using the command line, without going into details. Presumably that's because it shows the programmer what's going on behind the scenes, as opposed to the "magic" of a UI. It can also be faster. I mostly agree with that recommendation.

However, using an IDE vs. one of the most arcane, backwards and outdated editors out there, is a different topic.

Why would you recommend that beginners learn VIM, along with its esoteric key sequences, that no other player in the editors space has saw fit to adopt? Is that the point of learning to program? Why not advocate for an IDE that focuses on writing the code and enables debugging of its logic (which you do recommend)?

Using an IDE like WebStorm (free for open source projects), I can run circles around a beginner who tries to use VIM (I could probably run circles around VIM pros, but that's not the point; we're dishing advice out to beginners here). Where do I even start...

• In a proper IDE you have linting and syntax errors integrated as squiggles underneath words; that's simply just not possible in VIM's 1980's text-only UI.

• An IDE integrates a debugger with watches, breakpoints, console evaluation and whatnot. These are all native features and work seamlessly. VIM is an editor. Sure you can hunt around for a debugger plugin and work to integrate that, but again, is that the point of learning to program?

• An IDE understands that you have a test suite, and enables you do perform operations specific to that. You can easily run/debug tests, jump to where a test failed etc. An editor is just a dumb editor in this case.

• An IDE integrates with version control so you have an easy visual way to diff, merge, rebase, commit and push. Throwing git into a beginner's bag of tools to learn, when they want to learn programming, just risks alienating them. See http://ohshitgit.com/ or 10 things I hate about git.

I could go on an on about features, you one can look at https://www.jetbrains.com/webstorm/features/. My point is, in today's day and age, recommending that a beginner learn VIM, is misguided and unproductive. One can get started with an IDE right away, without having to use any of its advanced features. Running a program, editing it while you're debugging it, are at your fingertips, within easily accessible menus. The same cannot be said about vim.

If for some religious reasons IDEs are a no-no (though I'd love rational arguments on that topic), at least recommend Sublime, or some other text editor that doesn't have a learning curve steeper than that of programming itself.

[IonicaBizau]

If I chose using VIM for a religious reason, probably that would be the efficiency. 😁 Probably that's one of the reasons why you're using an IDE which is fine as long it fits for your needs.

I will write a blog post about this, explaining why I recommend VIM.

In short, I believe that using the command line and VIM helps the beginner anybody in the learning process. For short-term it's harder, but for long term is easier—I see this from the web-developer perspective (if you're working in C#, maybe it's easier to integrate the VIM bindings in VS 😏, at least that's what I did when I needed it).

Until then I will keep the issue opened and if you have any other ideas/questions, let me know.

[dandv]

Probably that's one of the reasons why you're using an IDE which is fine as long it fits for your needs.

Not at all. I started with plain editors (nano, mcedit, sublime), and ended up using IDEs (Turbo Pascal, Borland C, Delphi, Visual Studio, IntlelliJ, *Storm etc.) for the productivity advantages I've spelled out above.

In short, I believe that using the command line and VIM helps the beginner anybody in the learning process. For short-term it's harder, but for long term is easier

I haven't seen any rational arguments for vim in your reply, but perhaps those are for the blog post. I'll stay tuned.

[IonicaBizau]

for the productivity advantages

Exactly, isn't efficiency synonym with productivity?

Yes, I will write more about that in the blog post. 📝

[juliomatcom]

If only makes you more productive then it's not a valid argument :bow:

[dandv]

for the productivity advantages

Exactly, isn't efficiency synonym with productivity?

Not sure I understand the point here... ?

My argument is that for beginners, there are software development tools that far easier to learn than vim, and that also make them more productive than vim, given its inherent limitations (text-only, designed ages ago for terminals accessed over slow connections) can. There have been so many advances in UX that a text-based tool just can't take advantage of. How do you do tooltips in vim? Super useful when debugging, to quickly peek at a the value of a variable. How do you underline warnings with squiggly lines etc.

If you find yourself reaching a reasoning wall trying to argue for vim, that means the only "reason" keeping you attached to it is that you're just attached to it. For you, that may be reason enough. But is it for someone new, who doesn't have a path dependece to vim (shortcuts memory, plugins etc.), but who instead has a clean slate and can easily choose either vim or another tool?

[trosh]

Might be late to the party, but here goes:

vi was designed for ancient terminals, vim was designed for normal terminals, which can also be accessed over slow connections; however what we call a slow connection today is enough to have your whole editor working nicely through ssh.

You are mixing up vim as a vi-like modal editor, and using the vim editor for development. The super useful things you mention about IDEs (most of which are available through vim plugins, in a far more modular and user-empowering way than in IDEs, also most of them I rarely if ever actually needed to use, or if so used more efficiently with dedicated tools) have little to do with vi-like modal editing.

All those shortcuts and vi/vim grammar can be used to edit texts through plugins within other environments (e.g. VS, emacs, chrome, bash). Even though it doesn't Look'n'Feel like one-size-fits-all MS text editing, and therefore has a steeper learning curve, I promise anyone would benefit from learning to write/edit code "the vi way".

As to the vim editor, it does indeed have shortcomings if you try to use it as a full fledged IDE, mostly because it's not built around a strong concurrency model. Neovim is a fork that has reworked the whole editor to make it suited to these complex behaviours. I haven't used it ever but I'm pretty sure you can do interactive debugging (with the same fancy tooltips you can have in vim with ^X-^... auto-completion commands woo).

A big problem I have with IDEs (esp. for beginners) is also that most of them make no effort to reduce mouse usage, which is a total mind killer when coding. I guess I have a bias against IDEs because I always watched other students who used IDEs work on their projects through numerous menial loops, like click, right click, drag, menu click, click breakpoint, click click click what am I doing; when using dedicated tools I feel like I have to figure out what really needs to be done. When groking vi your actions become descriptive and you don't think "left right up down click button select area with mouse click context button", you think "delete paragraph, change inside parens, repeat command, complete file, s/foo/bar, man page current word". You start to give shape to your actions and to think in terms of commands. In MS-like interfaces, the user merely suggests "what happens if I click there?", you never feel in total control. It might seem more inviting at first but it leaves you in your state of beginner, even though you might have productively made something you don't feel as productive as with better tools, it doesn't push you towards betterness.

Finally I'd say people try to push beginners towards "old-school" tools like vim because they felt a better understanding of what they were doing when they used tools that shaped them instead of immediatly trying to shape the tools they used. However sometimes it can be simple stupid "we didn't have it so easy in my days", which is why I would also suggest newer, alternative tools, like Kakoune for example. The point of suggesting vim shouldn't be "it's the right way to program", it should be "it's a right way to program"

[IonicaBizau]

@trosh You're not late. Good points! 👍 I didn't have time to write a good answer on this subject yet.

The discussion is opened anyways.

[dandv]

@trosh: I've only used powerful and keyboard-friendly IDEs, so I can't speak about "most IDEs". Likewise, we're not speaking about "most text mode editors", but rather about "vi(m)". So let's focus the discussion on WebStorm, since it's an IDE I can talk about and also available for free to open source projects.

A big problem I have with IDEs (esp. for beginners) is also that most of them make no effort to reduce mouse usage

I never need to use the mouse in WebStorm. All actions have keyboard shortcuts.

"esp. for beginners" - do you think beginners will be more or less frustrated if when they want to learn a new programming language, or even programming itself, they also have the steep learning curve of learning all the keyboard shortcuts of the IDE, or when the IDE helps them, such as by having easily discoverable menus, or by leting you search for all possible actions:

which is a total mind killer when coding.

Maybe for you, but certainly not for me. Switching from the keyboard to the mouse is a "break" (if you call a 1-second motion a "break") that I pick, and Paul Graham wrote about this very well:

A programmer can leave the office and go and get a sandwich without losing the code in his head. But the wrong kind of interruption can wipe your brain in 30 seconds.

I don't have numbers, but I'd be curious how many programming beginners 1) Start with a decent IDE and continue learning to program 2) Start with vi(m) and switch to a less arcane editor 3) Start with vi(m) and get frustrated and give up programming

Anecdotally, I believe there are far more Android beginners in the developing world than C developers, and we could suspect that's thanks to Android studio being a decent IDE (based on IntelliJ, so very similar to WebStorm).

what we call a slow connection today is enough to have your whole editor working nicely through ssh

I think connection speed is no longer a concern. You can comfortably develop locally and have your code be automatically deployed to any server(s) you want (at least with WebStorm).

[IonicaBizau]

I had been busy with random things and couldn't find time to write a blog post about VIM, and another reason is that I am not sure if I will come with something new (compared to the blog posts on the subjects).

I observed that VI(M) is not for everybody. During the time I recommended it to many mentees. Most of them tried it, found it scary and gave up on using it.

Those who survived with VIM for about 4 weeks, got comfortable and they use the VIM shortcuts everywhere (e.g. a friend who switched from Node.js to Java, and working in Eclipse, uses the VIM shortcuts there).

---

If I would have to list a few reasons why I use it, here they are:

• :sparkles: One single editor on many platforms

  No matter if I'm working on my desktop machine running Ubuntu, on my MacBook, on a server (or RPi) via SSH, helping a mentee running Windows (and eventually having Git Bash), there it is: VIM.

  Some shortcuts may be different than what I have setup on my main machine, but it's the same editor I'm comfortable with.

• :four_leaf_clover: It's resource & battery friendly

  Back in 2013 when I started learning it, I was using IDEs which were consuming my Samsung's laptop battery quickly. After started using VIM, coding in parks or other random places was more fun.

• :rocket: Commands & Macros

  I'm sure the IDEs have something similar, but I love the way I can set up a macro in VIM. The VIM commands are like sentences you're telling to that editor and it simply obeys. With macros, I can repeat a set of commands.

• :eyeglasses: Learning new things

  It's so much fun when friends come to me and say: Hey, did you know this VIM command? I'm like: Umm, nope. What does it do?, and then I'm in awe for another few days. :joy:

---

At the end of the day, I recommend people using whatever they are comfortable with. Love Atom? Cool, I contributed to it! VS Studio Code? That's cool too, it's open-source. Trying VIM is a thing. Trying ed is a non-forgettable experience as well.

[cochiseruhulessin]

Especially beginners should use Vim (or in any case, not an IDE) since software engineering entails much more than writing lines of code. Competent software engineers need to master all tools and technologies used in a software project, which means using Git from the command line, writing a Dockerfile/Makefile by hand, and invoking code quality tools from the shell.

[dandv]

@cochiseruhulessin: by that logic, especially beginner bikers should use the meanest baddest Kawasaki Ninja H2R, and while at it, not ever use any power tools while maintaining it. Preferable unscrew nuts and bolts by hand.

@trosh:

A big problem I have with IDEs (esp. for beginners) is also that most of them make no effort to reduce mouse usage

What are you talking about? Both WebStorm and VSCode are configurable AF when it comes to keyboard shortcuts.

[cochiseruhulessin]

The correct analogy would be the software engineer as the mechanic of the bike, not the driver (i.e. user).

[dandv]

The real analogy, which people revolt against, is with religions. Once you've bought into one, it's extremely hard - impossible even - to accept that you've been duped all along, and that they're a simpler or easier way, or one with far more possibilities. Once you've expended months mastering vim, your brain needs to justify that immense cognitive effort by refusing the mere possibility that there are overall more powerful and easier to use tools. Thus you have the entire discipline of apologetics, which is an amazing exercise in contorted thinking. See for example how ridiculous the avoidance of certain activities gets on Sabbath.

An example in our case is the bogus argument about IDEs "making no effort to reduce mouse usage". Well guess what, in vim, you can't do much with the mouse to begin with. Do you have mouse-over inline symbol documentation tooltips? No - but hey, there's no mouse usage! Win!