Dec 93 Editorial
Volume Number: 9
Issue Number: 12
Column Tag: The Editor's Page
Please Be Apple, Not Microsoft! 
By Neil Ticktin, Editor-in-Chief
In the beginning, Apple was Apple - spunky, cocky, and innovative, but also
human, fun and right on the money! Then, Apple woke up one day and realized that
their market was being stolen by Microsoft and they sued. The courts (for some
reason beyond a normal person’s reality) said that Microsoft didn’t steal anything.
Apple looked around and said to itself “if Microsoft can take our ideas, we should take
theirs. After all, turnabout is fair play.” That might be well and good but things
have gone way too far.
There’s a saying in our industry: If you have a problem with your product, fix it
unless, of course, you are Microsoft - in which case, you just declare it a standard.
Microsoft is unable to produce an easy to use, powerful, relatively bug-free,
integrated environment. They produce “tools” with acronyms faster than Romper
Room went through the alphabet - DLLs, OLE, MFC, DPMI, NT, ODBC, LIM, WIN32,
DDE, etc. Everything that Microsoft produces touts that it “works together
seamlessly” but that’s a reality that only exists when you have an expensive
consultant set up your system (and then you aren’t allowed to touch a thing because
you’ll screw it up). If you talk to a Microsoft technical support representative,
they’ll tell you that they are now supporting over 1 million configurations of PCs -
what a nightmare.
But that’s not the worst of it for a developer. If you are a Windows programmer,
you’ll find a very large number of tools to help you. You’ll find that documentation is
measured in feet and APIs sprawl across your office. Cross platform developers will
tell you that of all their development platforms, Windows is the most difficult, takes
the longest and is the least stable. Just ask the Newton team developing tools for
Windows - they have twice as many resources as the Macintosh group, but are far
behind in their schedule.
What’s Apple doing?
And then we have Apple. Apple sees Microsoft’s incredible success and concludes
that since it can’t figure things out itself, it should do what Microsoft is doing. So
today, we have an operating system that can have many different configurations and a
barage of technologies. Granted, most of Apple’s names are easier to interpret than
Microsoft’s but they’re not that much better - AOCE, QuickTime, OpenDoc,
AppleScript, CommToolbox, QuickDraw GX, PowerTalk, Shared Library Manager, etc
Now, I’m not one to say that Apple should hold back, but it should look to integrate what
it is doing into a focused corporate direction.
At this point, you’re thinking “But Neil, what does this mean to me, a
developer.” Well I’ll tell you! As cool as technologies like AOCE are, the standing joke
is that AOCE has doubled the Macintosh API. GX will require you to modify the drawing
and printing portions of your code. Shared Library Manager will create new support
nightmares like you’ve never seen. OpenDoc will require a rewrite of your software.
And the list goes on
What’s the solution?
It would be naive to say that Apple should come up with a simple solution to all of
these problems. There is a lot of very cool technology out there - it just needs to be
presented in a “Macintosh way”. Apple has (until a year or so ago) done a pretty good
job of presenting these technologies to the end user in a Macintosh way, but they have
done an exceedingly poor job of “Macintoshing” the development cycle (can you say
MPW?).
For a long time, people have wished for the ultimate in programming tools.
They’ve listed things like speed, reusability, organization, GUI, etc There are people
that will tell you that in many ways, this product has been delivered already - it’s
called NextStep™. Now, we all know that NeXT is not the healthiest of companies, but
that’s because of other factors (i.e., their marketing and hardware).
On the Macintosh, we are fortunate to have tools like AppMaker, Marksman,
THINK Project Manager, etc (there are far too many to list here). But, what we need
is: integration from Apple simplicity in the API common ground between
technologies (i.e., how about one scripting language?) firm committment to stated
standards (i.e., have you ever felt screwed by committing to the CommToolbox?).
Bottom line, Apple needs to stop following Microsoft’s lead they’ll be second as
long as they continue this and instead they need to return to the Macintosh way at the
user level and for the first time, they need to “Macintosh” the development world.
If you agree (or disagree), write me and tell me your thoughts - page 2 has the
addresses.
Neil Ticktin, Editor-in-Chief