The second example that you made is perfect for my point.
Why in the world I would possibly want to have 10 different variables, all of them explicitly reinitialised to zero, if I can just write "a = new int[10]" ?
(And it is so compact that it doesn't even deserve the indentation to make it verbatim)
And if the variables are completely independent then much, much better to use some unit of measure or different objects type or something in the same league to avoid mixing them up and killing your software in the worst possible moment.
I honestly can't see how blindingly editing text without any semantic constraint in response to a stream of keystrokes is safer or better compared to what any decent IDE is doing nowadays..
If I'm missing something please explain me what, but I can't really see how it is a more effective way to write software..
Sure, I thought of that. Then instead of a variable named "salary" you've obfuscated your code by calling it a[4].
Ah, but you can just name your indexes, so it's a[salary]. But now you've got ten lines of code naming each of the index values, and a vim macro makes it faster to write again.
In any case, macros are just one of the features that make vim productive. I find that I do a lot more small refactors when I'm using an editor that makes arbitrary edits really fast and convenient. It's complementary to the named refactorings you have in an IDE. If all you're doing is pointing and clicking then you don't need vim, but if you're actually writing code, it helps.
I used to use a vim emulator in Visual Studio, and it was great. Now I'm working with stuff that doesn't have IDE support, and I'm still productive.
A lot of good programmers are hooked on vim. Hasn't it occurred to you that maybe they have good reasons for that?
Or as I suggested earlier you just use objects instead of random variables.
employee = new Employee();
And you have all the fields reinitialized to the correct default value (that can be different from zero) and much better naming because now you can tell the difference between employee.Username and user.Username
Sure, and I do that when I can (e.g. not when I'm writing SQL), but the point of my quick examples isn't to show off my software engineering, but to illustrate what vim can do in the simplest way I can think of.
I guess I'm failing to make the point, so I'll just refer to the articles that got me to try it in the first place.
