NetNews Usenet Archive 1992 #31/NN_1992_31.iso/spool/comp/sys/mac/oop/misc/147

Text File | 1992-12-30 | 3.6 KB | 73 lines

Newsgroups: comp.sys.mac.oop.misc
Path: sparky!uunet!news.mentorg.com!scherzo!bcohen
From: [e-mail] (Speaker-to-Managers)
Subject: Re: Learning App Frameworks (was Re: THINK Class Library learning..)
Sender: [e-mail] (News User)
Message-ID: <[e-mail]>
Date: Wed, 30 Dec 1992 20:48:47 GMT
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
Nntp-Posting-Host: scherzo.mentorg.com
Organization: ElectroPolitical Engineering Enterprises
Keywords:
Followup-To:
Lines: 58

In article <[e-mail]>, [e-mail] (Bill Coleman) writes:
|> ...
|> Indeed. And, in the case of MacApp and the TCL, the developers of these
|> frameworks have only shipped half of the product. They have shipped the parts,
|> but when it comes to delivering the description -- what little they have
|> shipped is woefully inadequate.

*SIGH*, all too true.  I've started using TCL recently, after several years
of using InterViews in the Unix world, and two projects (for my day job) devoted to
created object frameworks for other people.  So I can say that I have
sinned as much as been sinned against in this respect: the first time I
tried delivering a framework the documentation was inadequate.  But I'm
learning.

|> ...
|> Part of the problem is the character of the implementation languages used
|> for these frameworks -- it isn't entirely the fault of the
|> developers.

And the culture which has arisen around the programming language:
there's an old tradition in old-line C shops of "there's nothing you
can't understand by reading the source code; the man pages are for
people with short memories."

|>
|> Until documentation and languages appear that are conducive to producing
|> concise frameworks, we'll have to continue to struggle along with wading
|> through the source code.
|>

And until there are generally available tools for easily producing and using
documentation (and no, I DON'T mean automatic man page generators!)
about programs, only the strongly motivated will produce or use it.
Problem with that is the users tend to be more motivated than the producers.

|> ...
|> Sounds like you are suggesting people build frameworks in Eiffel, which
|> has formal mechanisms for defining pre and post conditions for all routines.
|>
|> Too bad there isn't such an Eiffel implementation for the Mac.

Eiffel is one way, though I'm not advocating it strongly.  There are ways to
annotate existing languages like C++ with assertions, documentation, and
so on.  See, for instance, A++, or some of Doug Lea's papers on
annotated c++.  (Another *SIGH*: If Doug didn't habitually load himself
down with 2-3 full-time jobs, or if some intelligent software company
were to give him a big salary just to work on the annotation project, he
might have gotten it done by now, and all this angst would be academic).

It's really amazing how much you can do with a preprocessor in front of
a language translator.  Annotations are one example; the addition of
signatures to clean up the C++ type system (Vince Russo, et. al. at
Purdue), the old COOL template front-end which gave us C++ parameterized
types back in the 2.0 days, are others.
------------------------------------------------------------------------
Bruce Cohen, Mentor Graphics Corpooration | email: [e-mail]
8005 SW Boeckman Road                     | phone: [phone]
Wilsonville, OR 97070-7777                |