Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!usc!apple!agate!shelby!neon!pescadero.Stanford.EDU!philip
From: philip@pescadero.Stanford.EDU (Philip Machanick)
Newsgroups: comp.sys.mac.programmer
Subject: Re: THINK Pascal debugger (Re: THINK C Debugger)
Message-ID: <1990Nov16.012356.20536@Neon.Stanford.EDU>
Date: 16 Nov 90 01:23:56 GMT
References: <1990Nov13.223209.16268@midway.uchicago.edu> <25759@dartvax.Dartmouth.EDU> <4716@husc6.harvard.edu> <1990Nov15.210134.7758@svc.portal.com>
Sender: news@Neon.Stanford.EDU (USENET News System)
Reply-To: philip@pescadero.stanford.edu
Organization: Computer Science Department, Stanford University
Lines: 28

In article <1990Nov15.210134.7758@svc.portal.com>, leonardr@svc.portal.com writes:
|> 	Only one problem with the Observe Window (which does serve admirably
|> for normal uses) is that you can view entire records, which is a VERY common
|> thing to do when debugging!   I also agree with Jim that Lightsbug is a bit
|> too cluttered.  I like the multiple panes, at least the bottom two (the data
|> view and raw hex views are WONDERFUL (wish Think C had one!)), but I NEVER 
|> use the icons and they are distracting.   
|> 
|> 	I think a lot of this stuff is historical.  What we now call Think
|> Pascal (what started life as QuickSilver), was designed originally as a 
|> basically 'MacPascal w/Compiler'.  It was (and still is) used in many
|> educational institutions as the Pascal environment for their students - even,
|> I teach a class using it (try that with MPW)!  Given this, many of the features
|> and choices of implementation lead towards this 'introductory' product, and
|> not for the professionial programmer - that doesn't mean that you can not
|> write a commercial or professional level product using it (I, and others, have
|> certainly done so) but does not make it easy - at least not as easy as Think
|> C!
Some of this is a matter of opinion. You can resize the panes and make the ones
you don't want disappear. Also, I find the simplicity of using the debugger
makes for a different programming style. If I'm in a hurry, I just do a rough
approximation to the program, then stop it at critical points and examine the
data. Amazingly enough, this really can be faster than thinking about
how to write the program (since you have to debug it anyway, and it's no big
disadvantage to start out _expecting_ to find bugs).
-- 
Philip Machanick
philip@pescadero.stanford.edu