Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!cornell!uw-beaver!fluke!mce
From: mce@tc.fluke.COM (Brian McElhinney)
Newsgroups: comp.sys.mac.programmer
Subject: MacApp (was Re: 32-bit OS)
Message-ID: <10612@fluke.COM>
Date: 23 Aug 89 22:43:42 GMT
References: <22321@andante.UUCP> <1989Aug19.221033.2241@geology.wisc.edu> <8352@hoptoad.uucp> <34184@apple.Apple.COM> <8365@hoptoad.uucp> <10505@claris.com>
Sender: news@tc.fluke.COM
Organization: Guild of the Software Defenestrators
Lines: 27

In article <10505@claris.com> peirce@claris.com (Michael Peirce) writes:
>But, but, but..  MacApp *is* catching on.  Look around.  There are lots
>of NEW software projects using MacApp (people revving old stuff doesn't
>count). 

You overlook one of the best kinds of software development: evolutionary.  A
person, or project team, with "old stuff" has a lot of learning and experience
invested in code that can be re-used for "NEW software".  Still, I would argue
that the benefits of an object oriented language would most often out weigh
re-using older code.

I thought MacApp might be manna from heaven when it first came out.  It was
certainly what the 1984 hype claimed the Toolbox to be.  Experience with MPW
(slow) and the MPW linker (slow *and* buggy) quickly changed my mind.

It will be interesting to see if the THINK C 4.0 class library catches on.  It
is very much like MacApp (to the point where the dynamic array class is also
called a list; where did this meme come from?).  The style of "object
orientedness" is also very similar to Object Pascal, too much so, perhaps.
Pascal can have locally scoped procedures that have access to the parents local
variables, which makes the CList/TList DoForEach-type operation fairly natural.
C doesn't support such a "wild" concept and so you end up introducing
"extraneous" globals.  It works, but it, well, *feels* wrong...
 
 
Brian McElhinney
mce@tc.fluke.com