Russ Brenner of Avalon started the August meeting by asking for a volunteer to take notes. I failed to step back quickly enough, so you'll have to bear with my sodden prose throughout these minutes. David Neubert of The Christian Science Monitor was equally slow on his feet and will be handling the organizational details of our chapter. For the near future we'll continue to meet at Component Software's offices in Lexington. Watch MacApp3Tech$ for more details. If you're not on the MacApp3Tech$ mailing list, give your AppleLink address to Russ (AppleLink: AVALON) or me so we can keep you informed separately.
Meetings are held on the last Tuesday of the month.
Stoney Ballard, head of Component Software, wowed this group of skeptical New Englanders with a demonstration that ran past 10 pm. If you haven't seen the July issue of FrameWorks, get yourself a copy and read Jeff Alger's article on the Component Workshop (CW) and its implementation of C++. This is not your father's CFront. It's a fast and powerful development environment that will change your approach to software. Do you want to change? Well, that doesn't matter, now, does it? MacApp is dead, so you'll have to change, and besides, it's an election year and change is in the air.
From Component Software, the winds of change seem to whirl around Stoney Ballard. He's an OOP evangelist, every bit as ardent as Jeff Alger.1 Stoney 's emphasis on the OOP paradigm pervades every aspect of this revolutionary product. He and his group have taken C++ where no (Unix) compiler has gone before, but there is a religious aspect to this pilgrimage. Everything is an object, and fundamental language elements like structs and typedefs aren't yet supported.2 If you are dealing with elements of the environment that speak in terms of data structures, like the Mac OS, you must be prepared to write libraries of subroutines to access these structures. Like SmallTalk, it's a world of objects that's intolerant of anything else.
At this point, I've consigned my electronic mailbox to the slings and arrows of outraged OOPers. I feel that it's necessary, however, to balance their enthusiasm for this fledgling system (which I share in many, many ways) with the realities of development. But let's talk for a moment on the side of enthusiasm before we get back to reality.
CW is fast. We're talking orders of magnitude. Fifteen seconds to make a change compared to fifteen minutes with MPW. That's a qualitative difference. For this alone, I would spend several months converting to CW. But we're not done singing it's praises.
It eliminates the necessity for handles without causing memory fragmentation. It does this with its own memory manager and throws in garbage collection so you don't have to worry about freeing objects. (Ever crash in a destructor trying to delete someone else's object?) It figures out which functions are monomorphic, so all functions can be virtual without loss of efficiency. It supports multiple inheritance. It holds all your source code in a database and applies that simultaneous knowledge to help you every way it can. It supports the Macintosh and will shortly support Windows and Windows/NT.
It's truly a great product. When you consider that all this is done with C++ as the front-end language3 it's a miracle (perhaps there's more to this evangelism than I thought).
Back to reality. It's not shipping yet. For all its flaws, our beloved MacApp sports a laundry list of shipping applications, some of which are making very good money. CW is new and we all know the definition of a pioneer.4 Of course, our alternative is to sign up as pioneers for Bedrock.
More reality. CW is really a superset of C++. Some of its capabilities force you to write nearly every line of code slightly differently. Since it automatically supports the envelope/letter idiom5, you write each reference to an object more simply (as an object rather than as a dereference of a pointer). CW translates the reference through an automatically created "envelope" object. The bottom line is that your application won't compile properly in any other C++ environment. So CW had better be real good, since you'll be stuck with it.
On the other hand, I feel pretty stuck with MacApp. It's memory management philosophy (and the Mac's) has made porting to other platforms a pretty miserable experience. Since CW is not limiting itself to C++ or to flat ASCII source files, it can be enhanced in many different ways that aren't available to the Borlands or the Apples of the world.
If CW turns out to be half what it seems to be and Bedrock turns out to be no more than I'm expecting, I'll probably convert to CW. And I'll pray I don't have to convert again.
It's unfortunate that Doug's product is going to be described through the eyes of a novice to OOA (analysis) and OOD (design). Doug was slinging the names of popular methodologies that ObjectModeler supports, names like Coad/Yourdon, Booch, and Rumbaugh. Doug is well spoken and seems to have an impressive knowledge of the good and bad points of these methodologies, but I don't know enough to judge. We were shown a product that lets you diagram your analysis and design in any of the supported methodologies, from overall sketches of requirements down to the pseudo code of how each function will work. He can even import pseudo code directly from your software to keep your design current.
Doug' emphasized several points. First, he believes programmers must look at a project from both the analysis and the design perspectives. The problem, he says, is that most methodologies emphasize either OOA or OOD. A tool oriented around one methodology will inevitably slight either analysis or design, resulting in software that either doesn't properly meet your client's needs or is difficult to build. He supports his argument with statistics (from a Boeing study) that show how combining the points of view of OOA and OOD results in better projects. The statistics were impressive, despite the little faith I have in statistics.
But then he made what I think was his most important point: it doesn't matter which methodology you choose-the primary benefit is to force the thought process of OOA/OOD. In other words, the more you think about your problem before you rush in to solve it, the better your solution will be. ObjectModeler and one or two of your favorite methodologies provide a structured environment that forces you to wring out your ideas before you sling out your code.
And what about ObjectModeler? I'm afraid you'll need to wait for a more qualified reviewer. The press release says it's been shipping since early this year and will cost "under a thousand". ObjectModeler integrates with nine other multi-user Iconix CASE modules that all operate off of a single repository.
We all asked whether ObjectModeler supports Solution Based Modeling, a topic near to the hearts of MacApp'ers. Doug replied that SBM is relatively new and doesn't yet have much of a following, but his tool set is flexible-he added Rumbaugh support in a month-so perhaps Jeff Alger should get in touch with Doug.
Since we were meeting in Component Software's offices, the meeting itself touched off the possibility of Iconix design tools integrating directly with Component Workshop. Analysis and design could be integrated directly with development, following the software throughout its lifecycle. Now, wouldn't that be a novel concept! In a way, it's only been recently that tools like AppleEvents have made that sort of vendor cooperation possible, as evidenced by Loic Vandereyken's object-based editor integrating so well with Steve Jasik's incremental linker.
If you're in the Boston area, remember to mark the last Tuesday of the month on your calendar. If you're not on our mailing list, link me and I'll add your name. n
Footnotes
