SQL is just inherently repetitive. What I would do with macros is start with a simple list of column names and turn it into a statement updating them all, or a join, or whatever I needed. Eg. a macro could turn "FirstName" into "a.FirstName = b.FirstName", and then work just as well on "LastName".
In other programming I don't have particular favorite macros, but still find small repetitive bits here and there that can be turned into temporary macros. Say for example you have ten variables that each need to be reset to zero. Don't type all the resets, just type the variables, turn one of them into a reset while you're recording into macro w, then type 9@w to do the rest.
Copying up to the second f is just a silly example. It could maybe occur though if you were manipulating lines in a data file. You look at it, see that on each line you want to do something with everything up to the second f, so you make a macro. You don't save it for general use.
In short, macros aren't for major repetition that should be factored out, they're for the minor repetitive edits which, if you're not using vim, you might not even think of as repetitive. Sometimes they're useful for refactoring.
So no, I'm not using macros "without even thinking" and this would probably be a more productive discussion if you didn't make such assumptions.
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.
In other programming I don't have particular favorite macros, but still find small repetitive bits here and there that can be turned into temporary macros. Say for example you have ten variables that each need to be reset to zero. Don't type all the resets, just type the variables, turn one of them into a reset while you're recording into macro w, then type 9@w to do the rest.
Copying up to the second f is just a silly example. It could maybe occur though if you were manipulating lines in a data file. You look at it, see that on each line you want to do something with everything up to the second f, so you make a macro. You don't save it for general use.
In short, macros aren't for major repetition that should be factored out, they're for the minor repetitive edits which, if you're not using vim, you might not even think of as repetitive. Sometimes they're useful for refactoring.
So no, I'm not using macros "without even thinking" and this would probably be a more productive discussion if you didn't make such assumptions.