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 persons reality) said that Microsoft didnt 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.
Theres 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 thats a reality that only exists when you have an expensive consultant set up your system (and then you arent allowed to touch a thing because youll screw it up). If you talk to a Microsoft technical support representative, theyll tell you that they are now supporting over 1 million configurations of PCs - what a nightmare.
But thats not the worst of it for a developer. If you are a Windows programmer, youll find a very large number of tools to help you. Youll 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.
Whats Apple doing?
And then we have Apple. Apple sees Microsofts incredible success and concludes that since it cant 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 Apples names are easier to interpret than Microsofts but theyre not that much better - AOCE, QuickTime, OpenDoc, AppleScript, CommToolbox, QuickDraw GX, PowerTalk, Shared Library Manager, etc Now, Im 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, youre thinking But Neil, what does this mean to me, a developer. Well Ill 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 youve never seen. OpenDoc will require a rewrite of your software. And the list goes on
Whats 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. Theyve 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 - its called NextStep. Now, we all know that NeXT is not the healthiest of companies, but thats 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 Microsofts lead theyll 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