Path: utzoo!attcan!uunet!samsung!usc!ucsd!ucbvax!husc6!endor!siegel
From: siegel@endor.harvard.edu (Rich Siegel)
Newsgroups: comp.sys.mac.programmer
Subject: Re: Reforming Mac Programming (longish, ~60 lines)
Message-ID: <2346@husc6.harvard.edu>
Date: 26 Mar 90 15:57:16 GMT
References: <13828@eagle.wesleyan.edu>
Sender: news@husc6.harvard.edu
Reply-To: siegel@endor.UUCP (Rich Siegel)
Organization: Symantec Language Products Group
Lines: 59

In article <13828@eagle.wesleyan.edu> bparsia@eagle.wesleyan.edu writes:
>Perhaps some of you with more experience with object-oriented programming (OOP)
>will comment.
>
>Someone mentioned in another post in another group (the post part of the "why
>can't Apple ][ users accept the mac" thread) that the bewildering variety of
>Macintoshs has lead to an unacceptable set of conditions one must check and
>take into account when programming. Color QuickDraw is one example of such a
>condition. I was wondering what could be done to simplfy programming on the Mac
>for everyone except the ROM and system programmers (sorry, someone has to
>suffer). Some things (like CQD) have to be taken care of by the appl.

	It's true that in some cases you must check for specific functionality,
but only if you're going to require that functionality in order for the
program to run. For example, I don't care whether Color Quickdraw exists
if I'm writing a compiler, and my text editor doesn't care what kind of
video cards the Mac II has in it. In the general case, a Mac program can 
get by with not checking for specific functionality and run on all Macs.

>For example, numeric coprocessors. THINK Pascal (along with most other packages
>I hope) has a 68881 compile option which generates optimized code for the
>coprocessor if you check it off. Now, why doesn't Apple just set up a standard
>numeric enviroment (i.e. SANE), included in the system or the ROM, written in
>blazingly fast and clever assembly language, and tailored to each machine. Thus
>the SANE in the SE ROM would just use the 68K to do the work, while the SANE in
>the II series would be optimized for the coprocessor. The upshot is: both have

	In fact, that's exactly the way it's done. SANE on the Mac II is
faster than SANE on a Portable (for example). However, SANE is tailored to
conform to the IEEE P784 spec for accuracy, and not so much for performance;
you do pay a little overhead for the trap dispatch, for the fact that
SANE only takes arguments by address on the stack, and for that extra
accuracy. Direct '881 calls are much faster than going through SANE, but
are occasionally less accurate.

>
>Now, take the idea a step further. What if Apple implemented a MacApp type
>class library and stuck *it* in the ROMS, optimized (of course) for the
>
>Cons: A hell of a lot of work for apple, but it would generate good software
>and sell machines.

	Another con: it would be nearly impossible to maintain and update.

R.



~~~~~~~~~~~~~~~
 Rich Siegel
 Staff Software Developer
 Symantec Corporation, Language Products Group
 Internet: siegel@endor.harvard.edu
 UUCP: ..harvard!endor!siegel

"When someone who makes four hundred and fifty dollars an hour wants to
tell you something for free, it's a good idea to listen."

~~~~~~~~~~~~~~~