|Of course, I prefer command-line based systems too, but what control and precision you tolking about? |
If I use a GUI interface to a programme such as a debugger, I can only do what the writer of the GUI decided to let me do, and I won't even know that there are other capabilities that are hidden. Your question contains the answer - what control? What precision? You have to ask because you don't know because the GUI hides it! :) At the very least, users of a GUI for debugging should read the debugger manual once so they know what it can actually do for them; sometimes the options are hidden so deeply in GUIs, almost impossible to find (and sometimes the options just aren't there, or the GUI just gives up and you have to type in your options anyway - many people who have only ever used the GUI will never get as far as manually entering their options).
I also trust that the GUI does what is claims to do; a decent GUI will at least show me the command line being passed, but some of them hide that.
I'm not against GUIs; I just find that I am more productive coding and debugging with as little as possible between me and the code, and with full control as much as possible. Many newcomers to coding don't even know that they're writing text files that are being passed to a command-line compiler.
Addendum: I do, however, steadfastly believe that a new coder should start with a simple text editor and a command line compiler. By all means, at the end of week one grab a pretty GUI, but the simplicity of the text file and the command line compiler cuts away all the distractions and cements permanently what the coder is actually doing. Manually typing in the compiler command, linking to a single library, seeing what happens if the library is left out or one of the files isn't compiled. If nothing else, it would eradicate forever the endless questions about the meaning of "undefined reference"!