🚀 go-pugleaf

In article <25cfc2dc.4a37@polyslo.CalPoly.EDU> jdudeck@polyslo.CalPoly.EDU (John R. Dudeck) writes:
| 
| [Set-up deleted]
| 
| I find that I prefer this arrangement over Quick C.  The only disadvantage
| is that it doesn't point to syntax errors in the editor after I compile.
| But Point will let me have the listing open in one window and the source
| in the another, which gives me more information anyway.  As far as I am
| concerned, the advantages of the Point editor for speed and ease of use
| outweigh the advantages of Quick C or Turbo C.

This may, indeed, be quite valid for some, but editors are largely a matter
of personal preference (I prefer to use vi myself).  However, I think I
gain enough from the TC IDE to put up with the editor (but, then, I
weened on WordStar).  But I'm a bit puzzled by the following:

| I can see no disadvantages
| to my approach in terms of keystrokes, mental effort, or elapsed time
| to get a debugged .exe file.

How many keystrokes does it take to quit editing, run make, start up CodeView
and execute to a specific location in your code?  In the TC IDE, the above
can be accomplished with a single keystroke.  I'd also venture to guess that
the whole process takes a bit less time as well.  But that isn't where the
real time savings comes from.  With such an environment, one is (or at least
I am) more inclined to crank out little stubs of code to test various ideas
during the development process or extract a bit of suspect code and throw
together a driver to test it out.

One can easily reproduce the setup you describe using UNIX and X Windows
(which is the standard workstation here at the UW).  I still turn out
better, and more thoroughly tested, code by doing the bulk of my work
at home.

--
Rick (schaut@garfield.cs.wisc.edu)

Peace and Prejudice Don't Mix! (unknown add copy)