> An IDE like Medium, not Vim
Sorry. You lost me here. If you don't understand why so many developers are so committed to Vim, then I don't believe you understand how actual developers (not beginners) interact with code well enough to replace it.
Sorry. You lost me here. If you don't understand why so many developers are so committed to Vim, then I don't believe you understand how actual developers (not beginners) interact with code well enough to replace it.
This is actually one of my core reasons for using Vim. I agree, but all of those "more powerful ways to interact with code" happen in my head, not in an IDE. And my head is far more flexible than the IDE. In pretty much every IDE I've used you start thinking according to the patterns of transformation that the IDE supports, which can be helpful for a beginner, but is ultimately very limiting. New languages start with no IDE support. This is mostly for practical reasons I concede, but it is usually also often the case that the new language is being written because it represents a new paradigm of thinking. It's not until the language matures and the common patterns of thought become known that they then become encoded as "helpers" in IDEs.
The other main objection to this, I think, is to point out that linear textual encoding of code is itself a bottleneck, and that a strict text editor like Vim will never let you move past that. Implicit in this assumption, however, is the belief that there is a better way to represent code than linear text. However, I would point out that throughout all of mankind's history, language (and text as it's persistent form) has been the highest form of communicated logical representation. We have had access to pictography and other forms of communication for millennia, but none has had the same ability to encode and transfer knowledge and logic like text. I think we are primarily adapted as humans to think in terms of language. My bet is that there isn't a more powerful abstraction than this given the structure of our brains. I'm happy to be proved wrong though.
Given both of the above, personally I find the most productive means of working is to work primarily at the conceptual/abstract level in my head, model the problem and solution in thought, then translate the solution into the most natural form for expressing thought: language (as text).
So most of the tools that the IDE gives me (especially regarding code transformation, etc.) are hard-coded, less powerful versions of the kind of mental processes I am already doing. I don't need those. What I do need is a way to encode my thoughts in text as quickly and efficiently as possible. I don't want to have to think about that at all. I want it to flow naturally from my mental model into prose (though not English prose, obviously). For that an IDE again gets in the way. It's slow and full of distractions. The Vim keybindings have become so ingrained that it's muscle-memory. And I've yet to find another paradigm that lets me manipulate text as effortlessly.
Actually, I think that this line of thinking holds a lot of promise: building specific tools well-tailored to solving specific types of problems. I think we could easily find models and alternate modes of thinking that outperform text for given domains.
I guess my argument is that as humans language is our most fluent medium for communicating abstractions. In the general case I don't think it will be outperformed.
For one, constructs like loops that we have mostly internalized as natural, can look a bit intimidating to non-programmers (they are not found in regular language either though!). Even among fairly experienced coders, for example in statistical programming, people who come from general-purpose coding background sometimes find loops easier to read and write compared to "vectorized" code, and vice versa.
Thinking about it, the way say much Java code is written is not what I would call a linear language either, although that I suspect might be more a result of path dependence and optimizing for "large teams of replaceable programmers".
A lot of thought and experiment went into what became eve.
I'm glad someone is exploring it. Maybe I'm wrong. Maybe this will yield promising results. But so far it seems like every time this kind of work come around again it continues to make big promises without concrete benefit. At best it provides a more gentle introduction for beginners, which is a good thing. But I have yet to see anything that would provide to me as a professional even half the utility and "accessibility" of my current toolset. Typically many of the simplifications they make in the name of accessibility become more of a hindrance than a help as you advance past the beginning stages.
I'm probably going to get down-voted to hell for this opinion here but it's literally the least productive, least intuitive, and most frustrating editor I've used.
But "learning curve" it's advocates cry! The time I have to spend getting up to speed with vim is better used actually programming, not to mention the people I know who are advanced users don't appear to code any faster than I do. A couple of occasionally used text operations are faster perhaps (though in modern editors it's debatable) but it appears to not have much cumulative effect.
As far as I can tell the only reason developers use vim is because developers use vim. It's a tautological tool.
However, vim is just great fun. That's why people obsess over it, fundamentally. It makes tricky and repetitive transformations of text intuitive and enjoyable.
This is such a fundamental disconnect from my idea of fun that I don't think we're going to see eye to eye on this ;)
> It makes tricky and repetitive transformations of text intuitive and enjoyable.
Given the fact that the number one phrase involving vim is "how do I do X in vim" I think intuitive is something that shouldn't even be in the same zipcode as it.
That's the thing, though. It's very different to non-modal text editors, so there's this learning 'cliff', where you get frustrated by how unfamiliar it is.
However, when it comes down to it - the neat thing about Vi is it's a re-imagining of what a text-editor is. Non vi-like editors essentially derive from the metaphor of a typewriter. You have a cursor, the print head, and you enter text there. You can use your hand (mouse) to change where the print head is pointing. You can highlight sections, as if with a pen - copy and paste stuff, as if you were using scissors. These functions are displayed a bit like the extra functions of one of those late-model electronic typewriters, where you could press a key-combination to get some neat functionality.
The nice thing about Vim is it accepts that editing text on a computer isn't like this. When you edit on a computer, you jump into a pre-existing text, mostly, adding or changing. So, for this reason, it has lots of functions for accurately manipulating sections of text, like words, or things between brackets, or sentences.
This kind of functionality is pretty standard for a good editor, but I think the thing Vi got really right is organizing these functions. The problem with having lots of functions is that they're hard to remember. So Vi structures them like a language.
So in the end, I think it's more intuitive than other editors. It doesn't work within the context of an outdated metaphor, and, it structures the functions that allow it to surpass that metaphor in a way that makes them extremely easy to discover and to remember.
The Vi keybindings and command set is largely self-consistent and follows common patterns. So while it might not be intuitive to someone unfamiliar with it, it becomes very intuitive once you grok the core patterns and concepts. There have been plenty of times I have strung together sets of commands and only noticed afterwards that this was technically a new behavior I'd never invoked before.
Not a selling point.
Genuinely curious if someone can explain how they're more productive in Vim than say Sublime? Take for example syntax highlight. If these things are feasible and easier, I'd really like to know.
I doubt you'd be "outperforming" if you were writing Java in say Vim, over Eclipse/Intellij...which have vi-keybindings.
That's exactly what I'm doing.
----
edit If you're actually interested in a discussion: what does your IDE actually give you in Java?
* Syntax highlighting? Every code editor (including Vim) gives you that, especially for such common languages as Java.
* JavaDoc access? Cool, but not worth the overhead. I've got the JavaDoc up in a browser pane on my second monitor, easy to search, doesn't make typing laggy or crap all over my text editing pane like the IDE does, and isn't triggered until I actually need the JavaDocs. I've found that by looking them up myself and not having autocomplete I actually internalize the documentation better, which means I need it less. My brain is much faster at autocomplete than the IDE too.
* Automated variable rename. Again, cool. This is one of the few net benefits. Doesn't out-weigh the rest. And silver surfer/grep + Vim gets me 95% of the way there. The only real trouble is when you have lots of duplicate names for un-related things, and that's a bad pattern I'm try to eliminate in my code anyway.
* Debugger? This is a powerful tool, to be sure. But it's not IDE-only. And I've seen it abused. I've never been anti-debugger, quite the contrary. I love my debugger. But I've noticed that as I've gotten older and have developed deeper experience I use it less and less. In fact, I don't think I even have a debugger installed on my work machine right now!
* Automated refactor/etc. I'm convinced this is the cause of bugs more often then the fix. Certainly for poor architectural decisions. I've elaborated in other comments, but basically: train your brain.
That last one I'll emphasize. I don't want the IDE doing any of my thinking for me. It doesn't think it applies canned patterns which may or may not be appropriate. Certainly it can be used well, but the more you use your brain to do it the better your brain will be. And if you train your brain it will be accustomed to doing the work so that the value lives in you, not your IDE. Now it's language-agnostic. Now you can jump onto the next cool language without being hobbled by the lack of IDE support. Now you are forced to learn the details of all the tools your IDE is wrapping for you and are more prepared to actually solve problems with, for example, your build environment.
Of course, I'm not saying that it's a binary your brain vs the IDE thing, but personally I find it more productive to live outside the IDE all the time.
Intelillij's vim plugin is an example of delete the source code repo and start again. It is ... not good.
Sure! I'd love to hear your opinion. I will caution you: I've heard "it's just more productive" as a general statement so many times that if it's just that then I'm going to shrug and point you at my original post where I address that.
But if its something other than that - I love to hear it (even if I end up disagreeing).
I do note that you're comparing vim (a - feature rich - text editor) to massive, bloated, IDEs... I'm curious if you've tried other, often programming related, leaner text editors to compare? (ie, Sublime Text, VSCode, Notepad++, etc)
To summarize, for me most of the real work of programming happens in my head, and in my experience that's a much more powerful place to work when you train yourself to do it. In light of that, all the "features" of the IDE become bloat and distraction. What I need is a fast, responsive editor that doesn't get in my way.
> I do note that you're comparing vim (a - feature rich - text editor) to massive, bloated, IDEs... I'm curious if you've tried other, often programming related, leaner text editors to compare? (ie, Sublime Text, VSCode, Notepad++, etc)
Yes, exactly, and many of those are other good alternatives to Vim. Above is why I strongly prefer text editors to IDEs. I know Vim-style modal editing with basically a language of commands in and of itself is not a good match for everyone's mental model, but personally I'm at the point where I don't have to think when I'm manipulating text: it's all automatic, and extremely powerful. Moreso from a text-manipulation than any other editor I've used. That's why I'm with Vim specifically and why it's so productive for me. Vim+unix has become (over the years) the fastest way to author and manipulate large amounts of text: it's the quickest way for me to encode the model in my head in textual, language-oriented form.
I suffered through learning "Brief" back in the 80s, and vim. The only feature I miss in modern editors is copying columns (usually from a bitmapping enum table). Not even drunken nostalgia is enough to make me want those control-this-that-or-the-other combos back. It's not worth the pain. It's impressive for me to see someone dance around the screen in vim, in the same way I watch somebody play a pipe organ with lots of ranks -- pulling this lever and stamping on that pedal and pushing this key and such while beautiful music pours out. Always impressive, but at what cost?
Besides, I like being able to see my code as it's executing, stop it, edit in place, back up, change execution points, etc. Maybe the visual editors have made me soft, but I can get far more done these days then back in the 80s anyway.
The only real reason I've heard people use vim instead of a GUI IDE is because it's simply what they're used to and don't want to change. (EDIT: And the fact that it's available on every system, but that only gives a reason to learn vim, not a reason to prefer it over an IDE)
In terms of features, there's not a damn thing vim can do that an IDE can't, while there are tons of things IDEs can do. It's excruciating to hear developers say "I use vim instead of an IDE because I can do X in vim" when every IDE made in the last 10 years can do X. And it does it out of the box without needing plugins!
I've literally heard people say they like vim because they can do some key combination to highlight several lines of text and then hit TAB to indent them all at once.
1.) They abstract important (to me) details. For example, build system integration. I prefer to see the actual Makefile to ensure that things are being linked correctly. This is especially important on large HPC clusters where there are a plethora of compiler options.
2.) They are too graphical. Essentially all of my programming is done through the terminal, which is fast and lightweight as compared to, say, Visual Studio or XCode (or w/e the standard OS-X IDE is).
3.) They do too much to 'help' the user, which ultimately just gets in the way. This is obviously a highly personal and biased opinion on my part. However, it is important (to me) to physically type the source, rather than starting from some template with boilerplate and adapting it to my needs. This is perhaps a reflection of the poor design of many languages (e.g. Java, C++) which necessitate such quality of life 'improvements' for some. But, for me, I just want to code what I want to code without an IDE getting in the way ala the maligned Microsoft Paperclip.
While I personally prefer emacs to vim, I have no doubt that these points may be common to developers who prefer either to an IDE. To your point, I do not know (but would not be surprised) to learn that some fantastic modern IDE could do all of the above. But, why do all that when emacs works so darn well for me?
Vim is at the end of the day also just a text editor, so no, there's no things that it does that you cannot achieve in some way or another with any other text editor.
The point is how quickly you can achieve these things.
Vim requires a lot of learning before you can use it effectively, but if you do know it, you can do things with it quicker than you can with other text editors.
For example, to delete the last three words in a line, you can type into Vim's command mode "$ 3b D".
The $ moves your cursor to the end of the line, the 3 does three times whatever comes next, the b moves your cursor back a word, and the D deletes everything to the end of the line.
This is the kind of stuff you can do with it. And well, you can mix and match these to do lots of different things.
It is somewhat ridiculous, but for people who actually know these commands, they have every right to feel horribly slow in any text editor that doesn't work like this.
And aside from that, Vim is really extensible, so whatever feature an IDE might offer, you can probably get that in Vim, too.
Perhaps it depends on the type of work. I imagine some types of programming require more typing than others. I could see typing efficiency being really beneficial for front end web stuff. I mostly work on game engine things, and rarely does my speed-of-thinking-of-things-to-type exceed my typing speed.
I'm currently in the middle of writing an application with Java, which is more or less just a GUI to enter things into a database. And both, the GUI code and the database code, is 90% just spelling out the obvious.
I mean, for the GUI code, context-sensitive autocompletion is still important, no doubt, even just so I don't have to type out "pnlInputTimeSpan" and similar all the time, but the naming is relatively consistent, so I could certainly imagine just typing it.
And there is something to be said as well about actually just typing things out, rather than also interacting with the GUI of your IDE. Remembering the name correctly and typing it, to me, feels closer to the core thought process than interacting with the GUI of my IDE.
Lastly, many people tell themselves they edit text all day long, so whatever helps to speed that up, even if it's just a few percent, is going to be worth it in the long run.
Press End to move the cursor to the end. Then hold CTRL-SHIFT and hit left arrow 3 times to highlight the last three words. Press Delete or Backspace. It's just as fast as typing "$ 3b D" and is far more intuitive.
I know. It was just an example to illustrate the sort of syntax that you'll find more of.
If I myself actually properly knew Vim, I would have given you an example that by itself is most definitely quicker than normal keybindings, too. But I figured, if you actually care to understand, you'll see that it's just an example, if you don't, then you won't.
All I know, is that you can find videos of people using Vim well and they're most definitely faster than anyone I've ever seen with a normal text editor.
The big thing with Vim's modal editing is that it allows you to have keyboard shortcuts involving keys that aren't way off in the boonies. Some examples:
* / or ? to search for text
* dd to delete the current line
* Stuff like ciw or ci" will delete a word or the contents of a double-quoted string, and drop you into insert mode. I use this one constantly.
When prompted, people try to come up with really crazy complex things, but frankly the bigger thing is just being able to actually reach things.
If I tried to use shortcuts in other editors to the extent that I do in vim, my hands would constantly be in pain. This is why I never got into emacs, though I've seen some folks be terrifyingly fast with it as well.
# Edit text without having to constantly move hands off of the keyboard home row to move the mouse or hit keys like PgUp/PgDn.
# Change all the 'X's to 'Y's on the current line in 5 seconds.
# Syntax highlighting for [any language the IDE doesn't compile].
# Pipe text through an external program.
# Start quickly enough to pop open text files whenever you need it.
There's probably more you can do without using the mouse than you realize.
> # Change all the 'X's to 'Y's on the current line in 5 seconds.
In PyCharm, I can easily select the current line with Home followed by Shift+End, hit CTRL-R, X, Tab, Y, click Replace All. Doesn't really take much more effort than whatever black magic command vim uses.
> # Syntax highlighting for [any language the IDE doesn't compile].
Then you're using the wrong IDE. PyCharm is primarily a Python IDE, but also does syntax highlighting for JavaScript, HTML, XML, YAML, CSS, and CoffeeScript. Visual Studio Code supports C/C++, C#, CSS, Go HTML, Java, JavaScript, JSON, PHP, Python, and a few others.
Both of them have support for adding custom syntax highlighting.
> # Pipe text through an external program.
I'd be doing this on the command line anyways.
> # Start quickly enough to pop open text files whenever you need it.
I'll give you that one. But that's not enough to do your general development in vim.