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
