Re: C++ in Linux or Windows
On Apr 18, 11:20 am, Zeppe
<zeppe.remove.all.this.long.comm...@email.it> wrote:
James Kanze wrote:
it's just for the 99.99% of the common human beings (I'm among them)
that a good IDE like Visual Studio improves the productivity by 300%...
Does it really? Then why isn't it used by the most productive
programmers?
and this information where does it comes from?
Personal observation.
An IDE has the advantage of being easy to learn.
and easy to keep in mind. That is, if I don't remember something that I
don't use every day, I can expect to find it quite quickly.
Maybe that's the difference. I develop code on a daily basis,
and remembering things I use on a daily basis isn't difficult.
I do use a graphical interface with the debugger, for example,
because that's a tool I'll only use a couple of times a year.
On the other hand, I'm sitting in front of the keyboard many
hours most days, so learning to touch type was worth the effort:
it took time to learn, but that time has more than repaid itself
since.
Typically, the
easier something is to learn, the less powerful it is, and the
less productive you are once you have invested the effort to
learn it. Without any previous knowledge, I'm sure that you can
write and compile a program quicker with Visual Studios than
with gvim/shell/makefiles, etc.
there is no doubt.
Once you have learned the
classical toolset, however, I suspect the reverse is true;
oh, well. It depends, actually. Probably if you are able to keep in mind
every shortcut in vim, every syntax rule of your makefiles and
everything yuo wrote in them, etc, probably it is true.
Makefiles can be a problem, but they are generally only written
once, then included. And from what I have seen of Visual
Studios, the only real difference is that you have to enter the
text in 100's of little pop-up windows, instead of once in a
makefile; the default configurations in Visual Studios (and in
every other tool I've seen, GUI or otherwise) are pretty much
useless.
But if you have
to remove a specific warning or defining a preprocessor symbol in a
specific compilation unit, just for example, and you have a makefile
that you have written long time ago, or you don't have written at all,
because in the real world you don't work just with your code, I think
that a left click of the mouse and a check into a box would be faster
than looking for the appropriate makefile, find the compilation unit,
hope that is written in such a way you can specify a rule for each
compilation unit, and then add the command that you have to keep in mind
anyway in order not to have to look at the manpage of gcc.
The problem is that you probably want to retrofit this change
into all of the other makefiles you use. I use GNU make, and my
local makefiles just define a few variables and include a global
one (which has become very complicated over time); any such
modifications go into the global makefile (or a sub-makefile
included from it, e.g. depending on the compiler or the target
system).
This seems to be a widespread technique; at least, I've seen it
a number of times.
It's the same principle why it's easier exploring a program during the
debug through the IDE, moving through the program stack by clicking on
the single functions, keeping under control multiple variables in a
subwindow, than keeping in mind thousand of "bt", "sb" (I think) and
other obfuscated gdb commands.
For the debugger, I agree. Because it's a tool that you'll
normally only use two or three times a year. (About the only
exception would be for post mortems, and how much effort does it
take to remember the single command bt?)
--
James Kanze (GABI Software) email:james.kanze@gmail.com
Conseils en informatique orient=E9e objet/
Beratung in objektorientierter Datenverarbeitung
9 place S=E9mard, 78210 St.-Cyr-l'=C9cole, France, +33 (0)1 30 23 00 34