Discussion How does Vim affect your problem solving?
Currently learning Vim, after a failed attempt some months ago.
Starting to get the hang of the basics. I notice that it makes my problem solving more methodical. It also makes me slow down, in a good way.
With Vim I have to memorize more of the code and structure, because switching views is expensive (might be a skill issue).
I don't care too much for the speed/efficiency, but this seems what keeps me going in my current attempt.
Wondering how you guys feel about this aspect.
12
u/vagrantchord 3d ago
Switching views is expensive? You mean switching between files, or going between different places in one file? If it's the latter, look up marks- they're dead easy.
I have a vim superiority complex as much as the next guy, but I wouldn't say it has any bearing on my problem solving skills.
3
u/sharp-calculation 3d ago
This is really the key question. What exactly is the OP talking about here?
"View" doesn't really mean anything specific in vim. So what do you mean u/hibuna ?
In a general sense, I find that VIM makes my code editing "feel better". It's kinda weird. 4 or 5 years ago when I finally gained some level of VIM skill, I noticed that I was happy while editing. Things seemed a lot faster because my "flow" was mostly continuous. I realized after a while that my process had been interrupted in previous editors by common operations: Cutting or copying and then pasting was a BIG one. With vim that's all extremely fluid. My hands never leave the keyboard and these operations just happen with little effort. With GUI editors my brain had to switch gears over to "visual mouse mode", which is an analog operation. Aiming, moving, and very precisely selecting. All analog "video game" operations. Which are totally different than the deterministic action of pressing a sequence of keys.
So generally speaking, I do better with vim because there's less context switching and no analog video game actions.
2
u/mgedmin 3d ago
"View" doesn't really mean anything specific in vim.
2
u/sharp-calculation 3d ago
Well, I was obviously incorrect there!
I've experimented with these and find them not very useful for me. But I do remember them now that you point it out. :)1
u/hibuna 3d ago
I meant viewport operations, scrolling/splitting/jumping.
That makes sense. Did you notice you approached problems differently than you did before at all after learning Vim?
5
u/sharp-calculation 3d ago
I still don't know exactly what you are finding difficult. You seem to only use meme words to describe everything. "Expensive", "Skill issue", "viewport operations".
Scrolling is very easy in VIM and has great operations that are functionally equivalent to what you would normally do with a mouse. You probably need some practice or to learn some of the ones you do not know. You should know how to scroll by page and by line. "Drag" your cursor (with it's page position) to the top, middle, or bottom of the window. Jump by absolute line number. Jump by relative line number. You should be using relative line numbering mode.
I use splits very rarely. I don't understand these busy IDE views with 4, 5, 6 separate areas. They are just visual clutter. The things I work on very rarely need me to touch multiple files at once. If I do, I usually switch between buffers with a leader command and just go back and forth as necessary. Why would I need to see two files at the same time? In my world this is rarely useful.
A few carefully selected plugins can help with some of this. For example vimfzf makes switching buffers really easy and much more intuitive. Map this to a leader command and it really fast.
2
u/gsmitheidw1 3d ago
In the need to jump between files, thats the job of a terminal multiplexer for me (GNU screen or tmux etc)
If it's reference material a second monitor is useful
3
u/sharp-calculation 3d ago
I like tmux as much as the next person. But there’s no reason to use it just to see another file. Multiple file and buffer handling is a core part of vim. You should really learn to use filing buffer commands.
1
u/gsmitheidw1 3d ago
I probably should, I suppose it depends on your typical workflow. I do more remote admin than dev so lots of remote ssh connections- I guess we all settle into a workflow that works for us and stick with it out of laziness etc
1
u/CCCFire 2d ago
The main reason I use vim is how cheap navigating and manipulating different files is. I tend to use 6-10 splits at once, and even more buffers because I have ADHD and I struggle to keep many things in my working memory simultaneously. Even in the same file I often find it useful to see many different parts at the same time. I tried VSCode a while back but I gave up because the splits were not smooth enough and various UI elements ended up cluttering my workspace.
It sounds to me that you have much to learn.
1
u/morewordsfaster 1d ago
This sounds like it could be a keybinds issue. If I find myself slowing down because of using command mode or multistep keybinds, I generally take that as an opportunity to add a new mnemonic keybind. Leader key is particularly helpful, although chords can be good as well, just depends on preference. I have friends who came to vim from emacs and prefer chords.
I put a bunch of split and buffer actions on <leader>/ and <leader>b plus some other key. <leader>// is open split right with current file, <leader>/\ is same but left. Combine this with marks and quickfix and lsp, you can navigate a codebase so fast it's not even funny.
1
u/SpecificMachine1 23h ago
with scrolling, a lot of time I use ctrl-b and ctrl-f if I am trying to page back or forward through a file, like when I first read it. After that I usually use / or ? to jump to the part I'm looking for.
I don't usually use splits unless I need to be reading one file (or a different part of the same file) while working on another
and for working with multiple files/buffers I usually use the buffer list if it's more than a couple
28
u/TheEyebal 3d ago
Vim is a text editor. It is like saying using notepad or vs code is effecting your problem solving
What is it that you are struggling with BTW
19
u/Schnarfman nnoremap gr gT 3d ago
“Edit at the speed of thought” it absolutely can have effects on problem solving
6
u/Psychological_Soil28 3d ago
I don't know about others but when I'm editing the code I've already thought about the problem/solution and just need to implement the changes. Vim simply let's me do it without having to use the mouse to navigate and do specific actions "quicker". It doesn't help me problem solve.
5
u/roku_remote 3d ago
I normally wouldn’t comment on something like this but I’m having an akshully moment:
“edit at the speed of thought” elaborates that how one edits is the dependent variable, meaning your cognition (“speed of thought”) impacts how you edit and not the other way around
3
u/Schnarfman nnoremap gr gT 3d ago
The language of vim has influenced how I think about text
For example: I used to “triple click and drag to the end of the paragraph to delete it”. Now I think “delete to whitespace”
d}.I personally structure my code differently to make this more useful
1
u/hibuna 3d ago
Imo GUI vs TUI is a huge difference.
I think it boils down to: 'Solving the problem' vs 'the problem of solving'.
Like I said, maybe it's just a skill issue, I have to be more thoughtful in e.g. struct declaration, because going back and forth is expensive.
Obviously this is the same for normal IDE's, but it's a lot more forgiving. It never held me back at least.
I could see how some time down the line, I could go back to a regular IDE and be a better problem solver, because I was forced to think about all these things that didn't matter before.
9
u/zephyrinian 3d ago
Skill issue. After the initial learning curve vim is way faster than a gui editor. When I have to use vs code I use a vim extension so that I have keyboard controls and my custom commands.
1
u/TheMcDucky 21h ago
Or you're like me and use vim for 10 years and still don't edit any faster than I do in e.g. Visual Studio.
3
u/Narrow-Low-3137 3d ago
gt, gT - if you are talking about switching tabs
:bn, :bp - if you are talking about switching buffers
CTRL_W + V for vertical split CTRL_W + S for horizontal split CTRL_W + T to move current buffer to its own tab
:ls - lists all open buffers, you can jump to them by number or name with :b <buffer>
Use marks:
m A creates a global mark you can jump to from anywhere by typing ' A in normal mode. m a defines a buffer specific mark. I use this all the time to quickly jump between blocks of code.
I usually define my own mappings for all of these commands in my vimrc.
Put set hidden in your vimrc so vim doesn't complain when you switch buffers without saving first.
I use Vim everyday as a scratch pad to do things Visual Studio is too stupid to do, or that the VSVim plugin I have can't manage to do.
I take my notes in vim.
Vim solves problems for me all day long.
If I could love a piece of software, it would be vim.
9
u/nujuat 3d ago
As a general rule I feel like one should solve the problem on paper or a whiteboard and then implement it in code, not solve it while coding. Maybe that's just me.
3
u/hibuna 3d ago
I think this might be the essence of it. I'm forced to be more methodical in lower level work, because it's so much more expensive to rewrite.
1
u/TankorSmash 3d ago
I think just getting an LSP going in most languages shrinks the difference between an IDE and vim considerably.
1
u/vagrantchord 3d ago
So that sounds like you're having the opposite experience of most vim users, because right now you're slow and still learning the basics. I find myself constantly "doodling" in vim while I'm thinking- moving around without purpose, highlighting sections, editing little things and undoing it.
For me, and probably most folks here, there's no friction using vim, so there's no "expense to rewrite" like you say. I think you need more time with it before philosophizing about how it changes problem solving.
1
u/gsmitheidw1 3d ago
^ this! Design is everything. I'd be thinking about data flow diagrams or entity relationship diagrams etc.
Mermaid is great for diagrams and can be done in vim and rendered in markdown in GitHub or equivalent. Or just output svg from mermaid cli
3
u/gumnos 3d ago
I found that my writing (whether code or prose) tends to be more consistent (things like indentation, punctuation, bracket/brace placement, etc.), allowing me to do predictable operations across things in bulk.
Yes, there's also a dimension of becoming more familiar with the document contents/structure (and the directory hierarchy where relevant such as whole projects). But even with that, predictable conventions simplify a lot of aspects.
3
u/GrandBIRDLizard 3d ago
It has nothing to do with my problem solving. It's just a method to convey my thoughts it's like having a regional dialect, except yours is objectively the best. ;)
2
u/ESnyder9 3d ago
vim, specifically neovim, has been an absolute game changer in my development process. i'm surprised many in this thread are saying otherwise.
being able to essentially minimize the friction of performing any navigation or edit (aside from typing, which will always remain limited to... your typing speed, which is probably not what you're doing most of the time anyways) to a muscle-memory-known series of keystrokes allows me to continue considering a problem uninterrupted without having to, say, scroll through a file, find a file, find a button in a menu, etc. this is crucial! when you are constantly interrupted from a problem with small-fries stuff, you are distracted from the actual work at hand.
neovim's extensive configurability helped in this regard greatly. with it, i was able to basically construct the direct brain-to-computer interface i needed from a known pretty-good point in around ~4 months. i still occasionally tweak, as any unix nerd will with their machine, but the time i save with vim is immeasurable, and it will likely be the editor i use for the rest of my life! it brought life back into programming!
2
u/-romainl- The Patient Vimmer 3d ago edited 3d ago
It's just a phase.
What holds you back is that you are not yet familiar enough with your text editor to let it take its intended place in your workflow: an invisible extension of your body that makes reading/navigating/editing code effortless.
Right now, you are essentially trying to solve two problems at the same time: whatever problem you are working on and how to get your text editor to do what you want. The difficulties you have operating the latter cause a larger-than-normal cognitive load that you shouldn't read too much into. It's not Vim rewiring your brain. It's you juggling with too many balls.
It will take some time but you will eventually get to a point where the low-level tools stop being a burden and you can allocate resources more efficiently.
2
u/DogInternational9332 2d ago
If by "switching views" you mean `vs :find ThingToCheckAgainst<RETURN>' *fuck* wrong file. `:bd<RETURN>` SHIT I just lost my split, why is it like this? `vs[...]` I hear you.
2
u/Serious-Chair 2d ago
I've read "Practical Vim" twice. I've forced myself using Vim for 2 months instead of IDE. Vim slows me down considerably, especially when I have to edit English mixed with Cyrillic texts. However, I have plenty of spare time, therefore, I don't mind.
2
u/EgZvor keep calm and read :help 3d ago
I started using Vim (in 2016) to better understand how programming works when I couldn't tell the difference between "Run" and "Debug" in Visual Studio and what release mode meant. This forced me to learn "the toolchain" so to speak. Using terminal-focused workflow in general also helped.
Nowadays, as a senior swe, I don't think Vim per se has an effect on how I think about code. It's more so that I developed my personal configurations and workflows that can't easily be replaced by anything else.
1
1
1
u/beef623 3d ago
It doesn't. It has some nice features that cooperate with how my brain works, it's available without any extra install most of the time (on linux) and it doesn't have bloat, but at the end of the day it's just a text editor and a text editor has no real meaningful impact on problem solving.
1
u/faultydesign 3d ago
Idk I just like that the editor does what I want from it
0
u/haikusbot 3d ago
Idk I just
Like that the editor does
What I want from it
- faultydesign
I detect haikus. And sometimes, successfully. Learn more about me.
Opt out of replies: "haikusbot opt out" | Delete my comment: "haikusbot delete"
1
u/PlanetVisitor 3d ago
Do you mean you don't have the the popups that show a syntax after you start typing something?
I like an uncluttered screen, but I don't work on huge codebases.
I've always been annoyed by how slow working with text can be. Vim is not the speed of thought, but definitely faster and so less annoying.
It depends on the problem but if it's bigger than a few lines, I like to write a textual description first, or peusdo-code.
1
u/feketegy 3d ago edited 2d ago
There's nothing wrong in saying that you memorized a bunch of cool shortcuts and that's it.
Not everything has to have some mystical higher meaning to it.
1
u/Nerrawnam 3d ago
I am not seeing the VIM = problem solving. You can say that about anything that makes you think and learn.
1
u/Snarwin 3d ago
It sounds like what's forcing you to slow down is just the fact that you're using tools you're not familiar with. Experienced Vim users can navigate projects and manage views very quickly and fluidly.
I do think there's value in experimenting with unfamiliar workflows like this, but it's not really specific to Vim.
1
u/cocainagrif 3d ago
vim is unboring enough that it overcomes my urge to do something else and makes me actually do my job
1
u/RelationshipOne9466 1d ago edited 1d ago
My journey went like this:
nano (yeah I know) --> micro --> vim (vundle pm) --> doom emacs --> neovim (lazy pm) --> helix.
I am not a dev, but I do some light coding and vim was great but a pita with all the plugins I had to use. I installed doom emacs mostly for fun and the learning experience with elisp. I dropped it because I realized it was overkill for me, but it is a great project imo. Neovim was better, especially with lazy, but every update seemed to bring on breaking changes that took me off my workflow. Helix imo is much better, more inuitive, easy to configure and just does what I need ootb.
2
u/Illustrious_Fuel_390 macvim 1d ago
In quantum mechanics, sometimes I use it to write down commutators and long operations (e.g. expanding commutators) since I can "copy and paste" easily. Then I use a regex/substitution to put it in proper LaTeX. Now I can do step-by-step computation. Nowadays, I also use AI to "polish" the results and apply proper formatting.
1
u/RyanCargan 1d ago
Frees up working memory. Enables supreme laziness. Started off with some other setups (Spacemacs / Doom / VS Code / Vim + tmux, etc).
Changed it up to keep it as dumb as possible for my use case. Using WezTerm + Neovim + zsh with skywind3000/z.lua rn.
LSPs w/ FIM models for auto-complete using nvim-cmp + fugitive (git) + telescope (fuzzy nav) mainly.
Touch typing over a subset of the keyboard (mostly the ~ to RCTRL area), without having to reach for the mouse or arrow keys. Barely any hand movement. Also very rarely use motions or visual mode.
Heavily rely on text objects & related normal mode actions instead. Also more or less ignore exact formatting with auto-format on save.
You can kinda "fuzzy navigate" within and across files, and "fuzzy type" craptons of text "without" thinking in terms of exact lines, dir structure, exact syntax, etc.
I don't use every applicable feature (probably even when I should), like marks, views, etc. I just think in terms symbols, filenames, text objects, and buffer history to go back and forth fast.
Switch to terminal tab on wezterm for running stuff. Agent tab as needed. I prefer it over a lot of stuff now.
For syntax level stuff, unless it's a crapton of text (thousands of not-totally-repetitive lines), I find it easier to type the thing directly instead of typing (or narrating even with STT/ASR), or thinking about a prompt first, and I doubt I even type that fast in wpm.
I can't really comment on the more methodical thing, cus if anything it's the opposite for me lol
Why overthink or have any back and forth (with yourself, bots, whatever) when I can just type something and run it as I think? To have an ongoing back and forth with the machine with less middlemen. Often works better when domain is tricky anyway. Disciplined trial and error and all that.
I feel like preserving working memory is key (something vim can sometimes help with) and stuff like absurd wpm and better awareness/debugging, etc. are all downstream.
Take wpm for example:
The biggest trick there (to not be bottlenecked by typical reaction times) is to "chunk" actions.
Plan out multiple actions, execute as a single "script", and before that phase ends, plan next phase. Repeat.
To keep chain going, you need enough working memory to plan "while" you're doing the current phase. Size the chunk so it's not too big or too small.
If there is any kind of friction, or context switch, it breaks your "script" throws you off. Touch typing and being very familiar with shortcuts helps here. That way you can just keep the chain going and the wpm can look absurdly fast and low-error on paper, but that's mainly a side effect.
Didn't see much point in vim at first because thinking is the bottleneck usually and not typing, but taking away enough friction can make typing kinda... replace thinking to an extent? More or less treating the entire codebase as your scratchpad instead of your limited and fallible working memory.
1
1
1
u/theGalation 3d ago
Vim system has a way of rewarding you learning.
Once you see the pattern is amount + command you can be in your way with less documentation.
61
u/mgedmin 3d ago
Vim distracts me into spending 30 minutes improving my Vim config so I could save me 5 seconds of effort actually editing text. But it's fun and I like it!