Mail Archives: cygwin/1996/12/22/19:36:27
root AT jacob DOT remcomp DOT fr writes:
> Yes. That's great idea. And when you are at it, use 'vi', what a GREAT
> editor. And then, what a GREAT relief of not using the GUI debugger!!!
> For instance, instead of just clicking over the name of something to
> be displayed at the screen, type gdb's commands (how easy isn't it?
> Oh! you forgot it, type help !)
If you have a problem with typing speed, you have a long way to go to
become productive programmer. Besides, most gnu tools allow tab
completion, I bet you'll never see that in GUI.
M-x praise-emacs
If you do not like vi I'd suggest looking into emacs. In many ways
emacs has evolved to provide all the essential user interface features
you get in a typical "GUI":
* compilation from editor with intelligent processing
of error messages - hit enter on error message and voila you're
there
* symbolic debugging in editor using your choice of debugger - mark
breakpoints and inspect variables by moving cursor over them
in your source code window and hitting a keyboard accelerator
* use tags to bookmark and move around your code fast
* syntax highlighting
* check files in and out of source code management systems - all
without ever leaving your editor
And emacs is does this with tool approach: you use the very same
command line debuggers and compilers that you would have used from
shell. This means that emacs is fully compatible with make or what ever
automation you build into your development process.
The last point is where I feel the GUIs tend to fail most
miserably. When your project grows to a certain size (say about 10000
to 20000 lines of code) the dependency and build mechanisms that the
GUI environments have stop being effective. With any worthwhile
project you need automation and custmization of the build
process. With make you glue together commands and perl scripts that do
things exactly the way you want and make wont go changing the rules
behind your back.
Trying to convince a GUI to do what you want is often an error prone
process of trial and error. In the end I have grown so cynical of GUIs
that I verify what they understood from all those check boxes by
looking at the make file they generate (at least VC 1.52 generates a
kind of a makefile, Borland is more difficult case).
Another plus for make based build processes is
documentability. Makefile is a printable document that unambiguosly
describes all necessary compiler options and dependencies. Suppose you
tell another member of your programming team to use the same
compilation options for project bar as I used for project foo. With
Makefiles its a simple matter of cut and paste, with GUIs its an
arduous task of browsing through all different dialogboxes and
verifying that the options match.
> For all others, I am writing an IDE/Visual debugger that will try to
> incorporate the windowed interface conceptually. It is stupid that
> programmers write GUI programs for others and do not benefit from
> the easy of use of the GUI programs themselves!
As an advice to your project, its difficult to beat gdb as a debugger
even if the user interface sucks. I'd recommend figuring out a way to
add GUI to gdb. In fact I belive some German university already has a
project called DDD going along those lines, so why don't you just port
their system to cygwin32.
--Sampo
-
For help on using this list, send a message to
"gnu-win32-request AT cygnus DOT com" with one line of text: "help".
- Raw text -