What's the biggest appeal of ViEmu over VsVim?
Vim Creep (2011)
81–90 of 169 posts
Re: Vim Creep (2011)
#82Truly a great story! Reminds me of this story... Two years ago I was collaborating with a coworker. Most of our time was in his office. I would look over his shoulder as he typed. He had recently adopted a new IDE and spent considerable time configuring it and learning its features. He was very proud of how productive it made him. Then one day we collaborated in my office instead. I use plain Unix tools, all independ…
In general though Emacs single handedly can do most of everything required in software development. One could practically spend all ones development time inside it, so I would say Emacs workflows are more impressive than Vi ones, especially since so much of great functionality is baked into it without even needing pluggins. This I say after a couple of recent days in which the GUD gdb interface was a great help in so…
neither emacs nor vim workflows are half as impressive as emacs-evil workflows, though. the unique strengths of each are lethal when combined.
Re: Vim Creep (2011)
#83Earlier quoted context omitted.
Just a single data point, but as a matter of principle I never use a debugger. Any time spend inside the debugger is 100% lost and useless to other people. To study a code, it is best to copy it, run it, and keep adding assertions, comments, and logging infrastructure. Besides helping you to understand what the code does, all these changes are useful for other people who may need to understand the code in the future.
I don't understand - how is using a debugger a waste of time? I don't often use a debugger, but they have proven to be useful in a lot of cases.
Not OP, and I think never using a debugger is silly, but IMO if I need a debugger to figure out a problem then I'm missing either sufficient unit tests or sufficient logging, and spending my time on that rather than in the debugger will aid future devs as well.
I do think the write/debug/edit cycle is a very, very slow way to program, and I have to admit I'm suspicious when somebody tells me they spend 90% their time in the debugger (but a lot of this is dependent on type of work).
Re: Vim Creep (2011)
#84If your editor makes you significantly more productive, maybe you're just writing boilerplate code, or something someone already implemented in a library. Touch typing is similar - it's useful because it removes some unnecessary barriers and thus makes the job more enjoyable, but it won't magically make you a better a programmer.
Yeah I always wonder who these people are for which the editor is a bottleneck and how they work or what they work on. 90% of my time is spent debugging, understanding legacy code and drawing trees or writing pseudo code on my notepad. The actual time I type stuff into an editor is like 10minutes per day.
It's not about typing speed, it's about reducing mental load. When vim (or any editor for that matter) becomes second nature, you stop thinking about how you're editing the text, it just happens, like moving a part of you body. And then you can better concentrate on the problem at hand, which matters even more for solving novel problems/algos/architecture.
Same with touch typing: you don't need the speed, you need to eliminate the distraction of looking for a key.
Even when you're debugging/reading code, you're still making small changes: adding a print here, removing an argument there. I read somewhere that the main insight behind creating vim was that you spend more time moving your cursor and parts of code around than you spend writing new code. So that's what it optimises for.
Re: Vim Creep (2011)
#85> You recorded macros, you moved entire blocks of code with the flick of a finger, you filled dozens of registers, and you rewrote and refactored entire components without even glancing at your mouse. You mean: spend untold hours scripting and recording interactions that give you about 10% of capabilities of a modern IDE. I've personally seen long-time vim users switch to Idea after looking over my shoulder.
Ah yes, I call it mouse-driven-programming.
You clearly have never used a modern IDE.
Re: Vim Creep (2011)
#86Earlier quoted context omitted.
Just a single data point, but as a matter of principle I never use a debugger. Any time spend inside the debugger is 100% lost and useless to other people. To study a code, it is best to copy it, run it, and keep adding assertions, comments, and logging infrastructure. Besides helping you to understand what the code does, all these changes are useful for other people who may need to understand the code in the future.
I don't understand - how is using a debugger a waste of time? I don't often use a debugger, but they have proven to be useful in a lot of cases.
> I don't understand - how is using a debugger a waste of time?
The debugger may help you understand, at some moment in time, what an unclear piece of code does. When you revisit this piece of code later, or another person finds it, your first experience with the debugger is not remembered, thus lost. This is what I meant. On the contrary, if you clarify the code and make it easier to instrumentate (by adding assertions, tests, comments, logging, etc.), it helps you right now, you in the future, and everybody else at any time. Furthermore, as a result of these efforts you will create a code that is clearer and nobody will ever need to debug to understand what it does.
The only case where debugging makes sense to me is for cases that are difficult to add instrumentation to, like assembly programming, where it will be somewhat inevitable that you need to step through the instructions to see what's going on.
Re: Vim Creep (2011)
#87If your editor makes you significantly more productive, maybe you're just writing boilerplate code, or something someone already implemented in a library. Touch typing is similar - it's useful because it removes some unnecessary barriers and thus makes the job more enjoyable, but it won't magically make you a better a programmer.
I agree with this.
This whole story gives me "hacker in movies" vibes. Programming isn't about artfully manipulating input devices while watching characters scroll fancifully across the screen.
It's about understanding a problem in depth, and considering possible implementations/problems/edge cases.
If you spend more time typing than thinking - I will unequivocally call you a bad developer (or a developer who's job is ripe for automation...).
---
Now - no knock on Vim. I much prefer it to nano, and if you enjoy using it, more power to ya. I do agree there's a certain sense of "playing a musical instrument" feeling to it.
But playing music and composing music are NOT the same. In the same way that entering text and programming are NOT the same.
Re: Vim Creep (2011)
#88I studied piano full-time for a short while. My favorite thing about it was how working on my technique or a particularly tricky rhythmic pattern tickled my brain. I often found that I went through a few phases: “ahrg, this is impossible!”, “getting there but sloppy” and finally, often suddenly (after a good night’s sleep) “this is easy! I don’t know how I was ever not able to do this”. Using vim and learning new fea…
I never had the words to express that feeling. Tickling the brain is exactly the experience. I also love learning a new trick in Vim even after all these years.
I love the related "I know kung fu" feeling (from the Matrix) when you realize what was very difficult, or almost impossible is doable now.
Great feeling.
Re: Vim Creep (2011)
#89Probably the best second person POV story I've ever read. Very funny and I got a kick out of it. As a relatively new part time vim user (about a year), I felt portions of this. I still use VSCode for a handful of tasks, but Vim has taken over more and more. This past semester I had to SSH into our CS servers for my OS class, and the way my group would work was usually me sharing my screen and us peer programming. The…
I think I'm probably at a similar stage with regards to vim usage. I have mixed feelings about it, but it seems that VSCode has spread itself into my consciousness in the way that I had hoped vim would. With VSCode, I know how to quickly select a word, jump the selection to a multiselect, and rapidly selection by words or lines that I wish to edit simultaneously, all without touching the mouse. It's gotten to the point where selecting or jumping a word with alt-arrow is reflexive instead of `w`, where `ctrl-D` and `alt-down` are more reflexive than the more composable alternatives in vim. This ALL was supposed to be vim! Damn you VSCode!
I wouldn't be bothered by this except I compose Unix tools quite a bit, so it's like I'm maintaining two separate working environments. If I had just started with vim (or emacs) from the get-go, then these two worlds would eventually meet. I've even got my own handful of extensions to send things from VSCode to the integrated terminal and back as a sort of poor substitute for the things that emacs and vim have been doing for decades. I'm pretty sure that I'm an idiot.
Re: Vim Creep (2011)
#90Truly a great story! Reminds me of this story... Two years ago I was collaborating with a coworker. Most of our time was in his office. I would look over his shoulder as he typed. He had recently adopted a new IDE and spent considerable time configuring it and learning its features. He was very proud of how productive it made him. Then one day we collaborated in my office instead. I use plain Unix tools, all independ…
In general though Emacs single handedly can do most of everything required in software development. One could practically spend all ones development time inside it, so I would say Emacs workflows are more impressive than Vi ones, especially since so much of great functionality is baked into it without even needing pluggins. This I say after a couple of recent days in which the GUD gdb interface was a great help in so…
all except 5, natively