Path: utzoo!attcan!uunet!timbuk!cs.umn.edu!msi-s0.msi.umn.edu!srcsip!sol.ctr.columbia.edu!emory!wuarchive!zaphod.mps.ohio-state.edu!uakari.primate.wisc.edu!pikes!boulder!chase
From: chase@boulder.Colorado.EDU (A. Chase Turner)
Newsgroups: comp.sys.next
Subject: A plea for a Structured Objective-C code browser in 2.0
Message-ID: <27092@boulder.Colorado.EDU>
Date: 27 Sep 90 18:11:50 GMT
Sender: news@boulder.Colorado.EDU
Reply-To: chase@tigger.colorado.edu (A. Chase Turner)
Organization: University of Colorado, Boulder
Lines: 69

I am listing my experience in programming environments -- in 
descending order of preference:

	ParcPlace's ObjectWorks -- both Smalltalk and C++
	Symbolic's Genera programming environment
	LightSpeed C on the Mac
	Sun's dbxtool (for C and C++) 

I rate NeXT's gdb and Edit at the very bottom.

Don't get me wrong: I WANT to develop code on the NeXT platform 
but I am finding myself completely dismayed at the disjoint cycle of 
development I must waddle through:

	- Write and modify code with Edit.
	- Compile till gnu pukes.
	- Correct syntax by walking through line numbers returned by 
	   the compilier;  associate line number with code using 
	   Edit's Select Line option.
	- Syntax is okay but application is not behaving correctly -- 
	   need to step through the code using gdb -- gave up 
	   because it is too primative of a user interface
	- Finally laced my code with printfs and successfully debugged 
	   my application code....

At this moment, I am looking at Communications of The ACM -- 
September 1990, page 92 -- an article written by Gibbs, Tsichritzis, 
and Casais -- and realizing that I am hitting the wall they describe 
in the article:  I am having trouble finding classes, relationships 
between them, and not being able to easily modify code on the 
NeXT platform.  The following are some brief examples of troubles 
I have had....

	- mistyped a name in the .h and forgot to update the .m (or vice versa)
	- added a method in my .m and forgot to include it in my .h 
	  (or vice versa)
	- mistyped the file name
	- used lower case for a .h or .m file -- 
	   ie) myObject.m instead of MyObject.m
	- don't know were to find the appropiate include file for some class
	- using the UNIX approach, debugging is a seperate task from 
	   code writing. Intead of interactive debugging environments where
	   one can insert breakpoints, observe stack and object values, etc,
	   i must use two terminal windows, Edit, and printfs.

I am blowing off some steam -- code I am trying to write today 
(in 6 hours time) took less than 1 hour in Smalltalk.  My experience today is 
another process of "enrichment" where I learn that I should avoid the 
frustration that builds within me when I find myself trying to work with 
primative tools for developing application code....

But why must it be that way, NeXT?  Why is it that I can buy a $500 Lightspeed
C compilier for the Macintosh which runs circles around your development
environment?!  I *KNOW* the emphasis of your platform is on the AppKit -- but
why let the basic programming tools (such as "direct manipulation" interface
linking all the programming steps -- browsing, modification, testing and
running code) fall out of step with the other parts of your development
environment?  

In 2.0, simply linking Edit with gdb so that when code pukes,
gdb will associate a line number in the Edit window with the error isn't good
enough--I want gdb to show me *exactly* where the parse error occurred.  Or,
that I can click in an Edit window to set a breakpoint -- or view the
variables in the current context of a step operation...

I hope that when 2.0 is finally ready for shipment, you will suprise me
with an Objective-C structured code browser that allows me to edit class
definitions, automatically generate .h and .m files, and integrates
with the gdb so that I can step through code, etc....