Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!sdd.hp.com!think.com!paperboy!husc6!endor!siegel From: siegel@endor.uucp (Rich Siegel) Newsgroups: comp.sys.mac.programmer Subject: Re: THINK Pascal debugger (Re: THINK C Debugger) Message-ID: <4743@husc6.harvard.edu> Date: 17 Nov 90 08:10:26 GMT References: <1990Nov13.223209.16268@midway.uchicago.edu> <25759@dartvax.Dartmouth.EDU> <4716@husc6.harvard.edu> <1990Nov15.210134.7758@svc.portal.com> Sender: news@husc6.harvard.edu Reply-To: siegel@endor.UUCP (Rich Siegel) Organization: Symantec Language Products Group Lines: 95 In article <1990Nov15.210134.7758@svc.portal.com> leonardr@svc.portal.com writes: > I am split on this issue...I like the concept and some of the >implementation of the Think Pascal 'debugging environment'. It was a neat >idea back before MF, and even today is not so bad - BUT given the concurrent >application world of MF, not to mention the unrealisticness of it (bugs which >don't occur in the environment, but do in the real world - and vice versa), >it's about time to follow in Think C's footsteps! > I will concede that the nature of the THINK Pascal debugger makes it difficult to debug programs in the background under MultiFinder; part of this is because MultiFinder forces applications to be suspended, whether they like it or not. Also, your assertion about the "unrealisticness" is irrelevant. In some circumstances, THINK Pascal does mask bugs; in particular, if the user fails to set up his current grafPort before drawing, THINK Pascal will draw into the Drawing window in the environment, and the built application will crash, because there is no drawing window. This is the only condition of which we're aware of different behavior between debug program and built application. I might also add that the "it works fine in the debugger but crashes as a built application" complaint is equally common for THINK C users, and indeed for programmers in general. It's hardly a reflection on the debugger. How many times have you tried to nail a bug which only happens some of the time? >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 One might argue that to view an entire record would tend to obscure the one or two fields you're interested in amongst the structure of the whole records. How useful is it to be able to see all elements of an HParamBlockRec, when all you're interested in is the ioActCount field? In Observe, you can type in "hpb.ioActCount", and there you have it. The THINK C approach to viewing structures does have its advantages, but so does the THINK Pascal approach. > 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! I question the historical accuracy of your statement, and I take exception to your assertion that THINK Pascal is "[an] 'introductory' product and not for the professional programmer" (to use your own words). THINK Pascal began life as THINK Pascal, and not as anything else. It was designed from the ground up to be fast, powerful, and easy to use. The designers did NOT say, "Let's take Mac Pascal and glue a compiler onto it and call it something else. The name has changed over the years, but the product remains the same. Also, while THINK Pascal does inherit many UI characteristics and some technology from Macintosh Pascal, LightsBug (the core of the source-level debugger) is not one of those elements. It first existed in form in version 1.0 of THINK Pascal, and over time it has been extended in order to fill the needs of our users. Also, THINK Pascal is most certainly suited to the needs of the professional developer. Its turnaround time and ease of use are generally accepted to be the best of the currently available Macintosh-based Pascal compilers, and the compactness and efficiency of the generated code is on a par with MPW Pascal - MPW is stronger in some areas, THINK Pascal is stronger in others; they both balance out. THINK Pascal is the only Pascal environment to support automatic dependency tracking and total integration of editor, compiler, linker, and debugger in a single environment. THINK Pascal comes with a fully-functional object class library for people who prefer to use one, and supports Apple Computer's standard class library. Finally, THINK Pascal is used to develop itself. To bootstrap a compiler requires a well-designed set of development tools, and THINK Pascal is an integral part of the development process. It is complemented by THINK C, MPW, and several special-purpose tools, all of which were developed with THINK C or THINK Pascal. Finally, I question your assertion that THINK C makes it easier to write applications than THINK Pascal. Each environment presents a distinct set of strengths and weaknesses. I consider some of THINK C's behavior to be less than desirable, but I would not generalize that to mean that THINK Pascal is a better environment to write applications. I believe that you've expressed a personal opinion, and that you might have done well to explicitly position it as such. Anyway, this thread has gotten far afield from the original poster's article, in which he opined that the THINK C debugger was unsuitable for debugging his applications, but he didn't elaborate. Nevertheless, I couldn't let this one go by. :-) R. Rich Siegel Symantec Languages Group Internet: siegel@endor.harvard.edu "...she's dressed in yellow, she says 'Hello, come sit next to me, you fine fellow..."