November 92 - Pointer-Counterpointer
Pointer-Counterpointer
Eric Berdhal and Jeff Alger
Eric,
For eight years now, MacApp has been the only game in town. Sure, there's
been Smalltalk V/Mac and the Think Class Library, but neither is a serious
product for large-scale applications. Suddenly, we're going to have new,
high-quality offerings from companies like Symantec, Taligent, Component
Software, Visix, Electron Mining (see elsewhere in this issue), and not least
Apple. There will be lots of cross-pollenation from technologies like X,
Windows, Common Lisp and its bouncing new baby, Dylan, and other
AI-derivatives. Where before we had strict parochialism, we will now have
routine cross-platform development.
What we're seeing is the emergence at long last of a competitive market
economy in class libraries for the Macintosh. Ironically, it will come about
roughly three years after the fall of central planning in eastern Europe, but
hey, better late than never. Those of us who have lived with MacApp over the
years (and no mistress could have been more loyal or more fickle!) are the
keepers of the lore and should pass that lore along to the new generation. So,
here goes.
Apple has invested too little to do the job right but just enough to screw up the
third-party market. One has to wonder whether a Taligent-sized effort within
Apple years ago wouldn't have obviated the need for Taligent as a separate
company. By changing compilers to suit MacApp Apple kept others constantly
off-balance in language tools. By providing simplistic tools like ViewEdit,
SourceBug, MPW, and MacBrowse free on ETO, but never really finishing
them, Apple has hampered third-party vendors and products - Jasik's
Debugger, AppMaker, Ad Lib, Object Master, to name just a few - that have
consistently been better products, but lacked one critical attribute in the
market: the Apple logo. Lurches in direction from version to version and even
beta to beta have made it impossible for independent companies to recapture
engineering costs. It has also discouraged people from writing books,
developing training courses, or providing complementary class libraries. On
reflection, I think Apple's resources would have been better used to set
standards, enable technologies through technical assistance and seed funding,
and provide a marketing umbrella for third-party products.
As far as technology is concerned, I agree with you that versions 1.x and 2.x
were quite well done, but that 3.x is basically a collection of features
masquerading as an application framework.
There were the expected number of misguesses for anything this complex.
Compatibility with Object Pascal, in hindsight, was more harmful than
helpful and looks a little silly now. Not using C++ version 3.x, pointer-based
objects or multiple inheritance also looks increasingly like a big mistake.
Backward compatibility with 2.x resulted in lots of redundancy but little
benefit.
There were good concepts backed by poor implementations. Behaviors,
adorners, and certain aspects of event dispatch missed the more general (and
simpler) principles of delegation and aggregation; they are also unevenly
applied. Dependency management never quite settled into a coherent
architecture and has been used in some positively bizarre ways. The 2.x view
architecture was due for an overhaul and didn't get it. I can't agree with your
praise of the dialog architecture, Eric. I'd like to see these areas rethought in
future frameworks.
There are glaring omissions: memory management, including garbage
collection; data structures; object persistence and distribution; automated
segmentation; data communications; and database support.
MacApp 3.x suffers from a lack of architectural coherence. Learning MacApp
is like walking into a house of mirrors. Eventually you learn your way
around, but it's disorienting and you can't trust your senses. Even within
MacApp there isn't a great deal of consistency, especially in the use of new
features like behaviors, adorners and dependency management. One gets the
impression that there just wasn't time to think things through.
On the other hand, there are some things done very well in 3.x: exception
handling, the overall approach to commands and events (though the
implementation is not well-factored), instantiate-by-name and other uses of
metainformation, support of System 7 features, printing (my favorite!),
streams, the menu architecture, and the mechanics of windoids and tear-off
menus. These should be studied seriously by any newcomer to the field.
Despite the problems, I don't blame the MacApp team itself, for they
accomplished a remarkable amount with limited resources. On balance, I'd
grant an A+ for effort but only C++ for the outcome and a generous D for
Apple management. The new kids on the block would be well-advised to study
the reasons.
Jeff
Friend Jeff,
I've been thinking over the conversations we've had about MacApp over the
years, and we have had some barn burners, haven't we? Now that Apple is
moving beyond MacApp, we have something new to consider: What can we learn
from MacApp and take with us to the future?
One thing I've always admired about MacApp is its vision and philosophy. I
think the first thing I liked about MacApp was that is was a decent factoring of
a Macintosh application. Even back in the days of MacApp 1.x, there were
interesting features aimed at being factors of a Mac App: a rudimentary
document structure, an encapsulation of a display, and some basic support for
utility objects like lists.
When MacApp turned 2.x, there was yet another factoring of a Mac App, one
that was significantly different and better. The document structure was still
not fantastic, but it did exist and allowed basic default functionality to be
easily accessed. The hierarchical view system modeled the way developers
want to display information fairly well. In many ways, the 2.x cycle brought
MacApp close to a quantum leap in technology, where software development
could truly leverage object technology.
Then came 3.x. Unfortunately, I think 3.x consists of a variety of features that
were grafted onto 2.x technology. MacApp deserved better and could have easily
been the unarguably superior development environment. As it is it's still head
and shoulders above the crowd, but the question remains: What can we learn
from MacApp? More importantly, what is MacApp? Once we have the answer
to that question, I think the rest will come easily.
I see MacApp as a collection of interesting features, a few frameworks, and a
couple architectures all thrown together in a package. In short order, here's
the way I view the MacApp world.
One of the oldest and most interesting architectures I see in MacApp is the
View architecture. Although it is essentially unchanged since 2.x, it is still a
fine piece of work. Views allow developers to display information to the user
in a rather rich format. Look at this, now I'm spewing Apple marketing
information at you.
Built on this architecture is what is possibly one of the best ideas to come
around, MacApp dialogs. After doing dialogs with MacApp, I can't see going back
to using the toolbox. MacApp actually makes it rather pleasant to deal with this
score. Well, I like it anyway.
Then there are adorners. These objects, really lightweight views, look like an
interesting experiment, but I'm not sure it was a success. I've always thought
that they were too light to be true lightweight views and too heavy to just
adorn a view. I'm also not thrilled that they require so much direct support
from the view system, almost like they were shoe horned into place.
Behaviors, yet another MacApp feature, have many of the same problems, but
I feel less strongly about them.
The other framework that is really cool is the command structure. How else do
you encapsulate the Macintosh undo metaphor? This is a textbook example of
how simple, obvious classes can solve what would otherwise be exceedingly
difficult problems. What MacApp has done is even more impressive, setting
the commands as the basic unit of work in an application.
Then there are systems and architectures that are expected to be found in a
mature object system. MacApp implements very nice access to the
metainformation available from Object Pascal. Dependency management and a
stream architecture is another one of those features you get used to seeing in
object based systems. MacApp's implementation of these isn't entirely world
class, but they are very usable even though they're not completely integrated
into the underlying MacApp frameworks.
Finally, MacApp has a lot of debugging and antibugging code. Another thing that
MacApp dealt with mostly head on is the admission that exception handling has
to be a part of the mainstream code of an application. The consequence is that
debugging code and failure handling permeates MacApp and MacApp based
applications, something noticeably absent elsewhere.
So, with all these pieces, we should be able to find something that we can take
with us, either in code, analysis, or lessons.
Stirring regards,
Eric