September 92 - Fun with Fred and Barney
Fun with Fred and Barney
Steve Mann and MACAPP3TECH$
Gee, with a name like Bedrock would we be talking about a TFred class, a TWilma class,
etc.?
- Kirk Austin, ILM
Since the last FrameWorks went to press, there has been a lot of AppleLink traffic
discussing Bedrock. The most heated discussion so far took place on the
MACAPP2TECH$ and MACAPP3TECH$ AppleLink group addresses. In addition, there is
an ongoing discussion in the AppleLink Developer Support bulletin board (Developer
Support: Developer Talk: Macintosh Development Tool Discussion: MacApp Discussion
Folder) about the viability of MacApp3.
We thought it might be appropriate to include some of this electronic activity for those
MADA members that don't have access to AppleLink or don't belong to the
MACAPP2TECH$ or MACAPP3TECH$ group addresses. These messages, presented in
chronological order, are all culled from those two group addresses,
A few recurring themes stand out in this series of links:
• Bedrock source code availability-Many MacApp developers think it's
essential that the Bedrock class library source code be available.
• MacApp 3.X support from Apple-There is concern that MacApp 3.X will
not be upgraded to fix known bugs, that there will never be even a MacApp
3.1, and that current MacApp developers are essentially being stranded with
an orphaned technology.
• Porting MacApp applications to Bedrock-Developers want to know just
how useful their MacApp knowledge will be for Bedrock, and what tools will be
available if it is possible (unlikely) to port MacApp code to Bedrock.
• The Yet-Another-OOF (Object-Oriented Framework) Syndrome - First it
was MacApp 2.0, then 3.0, now Bedrock, all in relatively quick
succession-when will it stop? How does Pink fit into this sequence?
• How strong is Symantec and Apple's commitment to MacApp developers
and the timely delivery of information to those developers?
On that last theme, Symantec has a telephone number (408/446-8931) you can call
to apply to join the Bedrock early developer program. If you leave an appropriate
message, they'll send you an application. Included with the application questionnaire
is a copy of the Bedrock press release, a Bedrock white paper, and a overview of the
development tools market. Symantec is collecting names and basic qualifications for
those people they hope to anoint as early developers.
Gordon Apple at Advanced Communications Engineering (one of our FrameWorks
authors this month) found the telephone number on Compuserve. As one of the links in
this collection indicates, Symantec has an active forum on Compuserve, none on
AppleLink. This focuses the last item in the list above a bit more-what is Symantec's
commitment to MacApp developers?
Symantec clearly wants to penetrate the PC development tools market. They also have
their own developer group for Think Class Library users. Sources at Symantec have
essentially said that selling Bedrock to MacApp developers is like preaching to the
already converted. All of this suggests that on the priority list, MacApp developers are
perhaps third or fourth on Symantec's list of preferred partners, which is
unfortunate. Perhaps they forgot that religious wars are bound to fail if the zealots
lose their zeal.
So far we've seen a lot of advance marketing and hype, but very few specifics. Most of
the MADA members I've talk to are skeptical about Bedrock. Until Symantec and Apple
provide developers with answers to some of the questions posed in these links, that's
not going to change. In the mean time, this collection of links, courtesy of MADA
members, may give you some insights into some of the choices that you may be facing
in the future.
Item 0747760 24-June-92 09:02PDT
From: D5858 Industrial Light & Magic, Lenci,PRT
Sub: Re: Bedrock 'n stuff
Gee, with a name like Bedrock would we be talking about a TFred class, a
TWilma class, etc.?
Kirk Austin, ILM
Item 0747762 24-June-92 09:04PDT
From: D3943 West Publishing, Dean Stambaugh,PRT
Sub: Bedrock Packaging
It seems to me that the break from MacApp & TCL provides an opportunity to
market the source separately from the libraries. There are surely many
programmers, both professional and amateur, who never need to refer to
MacApp's source. (Just as there are many of us who make a living from our
ability to navigate the backwaters of MacApp.)
I would like to see Apple/Symantec sell a basic package (no source) for
something like the current price of Think C/TCL. This could get a lot more
programmers on the O.P. bus (probably a "good thing") particularly on the
Windows side.
A separate source package on CD-ROM could sell for (say) $250. It would be
available only to registered owners of the library version and only direct
from Apple or Symantec.
And of course there's the combo box with both parts at a small discount.
I think the most important thing is to find ways to make this stuff available to
the largest possible number of people. So, Apple Marketing Folks - let
Symantec set the price.
Bill Colsher
SKAMP Computer Services
Item 0852241 24-June-92 09:33PDT
From: CAERE.WADE Caere, Wade Eilrich,PRT
Sub: Bedrock source is necessary
We would never have been able to ship our two products (OmniPage
Professional and OmniPage Direct) if we had not had the source to MacApp.
MacApp contained so many bugs, that without the ability to correct the
problems in the source we would STILL not have those products on the market.
When a program, like MacApp, becomes the basis for application generation it
is imperative that the application developer be able modify/customize the
source for their own needs. There still are bugs in 3.0 final that we reported
in 3.0b2...
Without source I cannot justify the use of a product like Bedrock as a
foundation for our product family. It is much more important to me to be able
to release bug-free applications on time than it is to have a common UI code
base and be unable to get an application through our QA cycle.
Wade Eilrich
Manager of Macintosh Projects
Caere Corp.
Item 7501080 24-June-92 10:09PDT
From: ALGER Alger, Jeff,VCA
Sub: Re: Bedrock source is necessary
Yabadabadoooooo!
There is a curious paradox in the debate over source. Let's assume, for the
sake of argument, that the product works flawlessly in all its versions, or that
Symantec's support is sooooo great that it doesn't matter, since they'll fix it in
a flash anyway. The whole area of QA for class libraries is a quagmire of
conflicting strategies and utopian visions. And let's assume for the sake of
argument that the documentation is picture-perfect and kept perfectly up to
date. It won't happen - witness the forthcoming "quick reference" for
MacApp, which documents a fraction of the whole in 600 pages - but let's just
assume that it can and will happen. Now, do _we_ still need source? Is it still
in the _vendor's_ best interest to release the source?
Polymorphism is the cornerstone of code reuse in OOP, and to take advantage of
it a well-factored object-oriented designed decomposes methods into, ideally,
one to ten lines of source per method. So in one sense, it doesn't matter: if the
documentation is really good, it doesn't take a rocket scientist to figure out
what the source must look like. And if you can't guess at it, anyone who ever
took a course in assembler language can drop into a debugger and know for
sure.
One then has to question the worth of the documentation in the first place to the
extent that it reproduces the algorithms of the code. (At this level of
granularity, let's not get caught in silly semantics: usage protocols imply
algorithms at some point.) C++ is nice and succinct. Ever try translating
simple for loop logic into equivalent English (or whatever)? Natural
languages are anything but succinct. Why turn what to a programmer is a
precise expression, code, into something imprecise written by a technical
writer who doesn't code or, worse, a coder who doesn't write? It mushrooms
and distortion is always introduced. And that's before you start making
changes over the life of the product.
Another observation: stolen OOP code doesn't go far. Classes, for all of our
bellowing about reuse, tend to be pretty well tied to the class library they
come from. Furthermore, the only people who can really take advantage of
stolen source are other big companies whose lawyers will jump up and down
and scream at the thievery. So it doesn't strike me as in a vendor's interest to
tie up source, since the source is likely to be reused only within that vendor's
product, anyway. There are exceptions, chiefly in low-level stuff like code
generators and real-time kernels that represent heady investments in
discarding other alternatives, but most OOP code is just straightforward
implementation of stuff that is in the manual. In fact, one could argue that
really great OOP documentation just makes it _easier_ for someone to pirate
by reverse engineering to the same interface, rather than browsing
copyrighted code.
So, in summary: It doesn't strike me as in the programmer's interest to see
documentation only, since that is always more verbose than the equivalent code
and far less precise. It doesn't strike me as in the vendor's best interest to not
release source, since it means a heavier burden of QA and support, a heavier -
perhaps impossible - burden of documentation, discouraging innovation from
the user community that can lead to better future versions, and frightening
away people with mission-critical projects that have to be controllable, in the
worst case, from within.
Regards,
Jeff Alger
Item 4777348 24-June-92 13:20PDT
From: DIGIMATCH 3M, Ran Bedekar,PRT
Sub: Frameworks and the Toolbox
It seems like a good time to resurrect a topic from the WWDC, namely what
priority is Apple placing on supporting new features in their object
framework.
For example, Quicktime, in its initial form, is not entirely compatible with
MacApp. If, as Apple says, object frameworks (i.e., MacApp) are the
recommended way to write Macintosh apps, the object oriented interface
should be as important as the Pascal interface for Inside Macintosh. At the
WWDC there was a lot of finger pointing. The MacApp team said the groups
extending the toolbox should guarantee compatibility with MacApp. The other
groups normally said the MacApp team should do it. I came away with the
impression that there was no real corporate commitment to timely support
new toolbox features in their object framework. To be fair, the MacApp team