Re: The start of a C/C++ adventure...
On 7/16/2013 11:20 AM, James Kanze wrote:
I for example don't use any of those. In the last heavy vim-using
environment the best C++ programmer used joe. Those working for
non-unix would puke from any vi-descendant,
I'm currently working in a 100% Windows environment, and I use
BAH, misphrased, I meant those who started and evolved there. Of course
you use vim -- that is the editor you used. I used visual studio in unix
developpment for the very same reason. But it doesn't say anything
about the editor really, only about our (in)flexibility. ;-)
and for emacs you'd need a kind of accident.
And certainly we know that it's not the editor that makes a programmer
good but the gray matter. ;-)
Yes, but good gray matter will affect how you chose an editor.
How, yes. Which -- will vary all the same. :)
An interesting side-light: the people I know who prefer vim,
even in a Windows enviroment, all touch type.
I try to recall people from my past, and just can't find a single one
who did not touch-type.
None of the people I know who prefer the VS editor touch type.
Hm, I start wondering where the winds blew you this time. ;)
I don't know what conclusion to draw from that, though.
Probably that you're in some weird place. But maybe it's the other way
around really, and touch-typing is connected more to being aged. And new
environments with completion work against TT? We have three fresh-grads
and they type alright, I honestly never thought it's an attribute worth
checking on interview or something.
(Another co-relation, at least in people I know: programmers who
prefer vim or emacs tend to make heavy use of regular
expressions and external tools. Those who use VS tend to do
everything in VS.)
And what counts "external"? VS has hundreds of plugins, are those in or
out? How about macros you write or record in emacs or vs?
What is the virtue of external tool if you get it inside? The most
frequent one is IME definitely grep -- that was built-in VS from 1.0.
Along with globalreplace.
Build/compiler and debugger is inside, so is source control (well,
mostly). And the bug tracker. Even an internal web browser is
available. So WHAT is left needed for externalia?
Well, I'm not happy with the integrated git support so use a plenty of
it outside, but possibly it will be better covered in a year.
IMO the practical approach is to look *how problems are solved* and
whether they are actually. Not the composition of the applied clicks
and keystrokes. If time is wasted on manual work or workaround what a
program could just do -- that *is* a problem.