Dec 90 Letters
Volume Number: 6
Issue Number: 12
Column Tag: Letters
The Sordid Truth
By Kirk Chase, Editor, MacTutor
The Sordid Truth About Apple Why Don’t Those Idiots Ever Do Anything
Right?
Dave Wilson
Personal Concepts
Palo Alto, CA 94306
MacTutor has been running a lot of articles about programming with objects
lately, covering everything from MacApp. the THINK Class Library, and other goodies.
This coverage is great, since it reflects the rapidly growing interest in object
programming on the Mac, and on any other platform that requires us to support a
graphical user interface.
I found the two-part series entitled “MacOops!” by Dr. Christian Stratowa in
August and Sept ’90 to be particularly interesting. The good doctor has done a really
nice piece of work in developing a small applications framework in THINK Pascal. He
also added some spice to the article with some personal comments about Apple
Computer in general and MacApp specifically. I think a response to some of those
comments is in order.
We are all entitled to our opinions, so what follows are mine, based on my
experiences teaching Mac programming since 1984. During that time, I have written
Mac applications using only the Toolbox, and also using MacApp. I have taught hundreds
of developers to use THINK C, THINK Pascal, MPW Object Pascal, and MPW C++. I
also have taught Smalltalk-80 for ParcPlace Systems, and have written small
programs on the NeXT computer using NextStep and it’s Interface Builder.
The following paragraphs start with quotes from Dr. Stratowa’s September
article in italics, followed by my comments in a plain style.
“Apple is giving notice to Macintosh developers that OOP will become the only
way to write Mac software. I really hope this statement does not mean that in the
future Apple will force programmers to use MacApp. Although I don’t have MacApp yet,
from what I have seen in the different article published in MacTutor, I have the feeling
that I won’t like it.”
“Freedom to the programmers to adopt their own programming style and to use
the language of their choice.”
“It seems clear to me that object-oriented programming will be the software
approach of the future.”
“The way of the future seems to lie more GAOOP - graphic assisted
object-oriented programming, a way outlined in Steve Job’s NextStep
Comment: Apple has not threatened to force you to use MacApp, but they have
indicated that there will be a time when you will have to use OOP. That is because of
exactly what the Dr. stated in his third comment above. What is odd is the Dr’s feeling
that Apple is jamming something down his throat, while at the same time speaking
fondly of NextStep on the NeXT computer. Perhaps he does not realize that to write GUI
applications for the NeXT machine, you are required to use NextStep with Objective-C.
In other words, while Apple currently allow you choices, Next does not. How can you
compliment Next for already doing what Apple has said they will do in the future.
Since the Dr. likes NextStep, but does not like MacApp, perhaps a comparison is
in order. A good object-oriented development system consists of the following parts:
After writing programs using both MacApp and NextStep, they appear to me to be
very similar in concept and intent. I think that NextStep’s system looks nicer and is
more integrated, while MacApp is richer and more well-developed, with a much wider
range of programming tools. And MacApp allows you to work in either C or Pascal,
while NextStep has no place for Pascal programmers to hide.
“Maybe Smalltalk will finally get the attention it deserves, although for some
strange reason Apple has never promoted it officially. Using Smalltalk, scientists at
Canon’s European research center have recently developed a visual programming
language, called VPL, which enables non specialists to manipulate images on a computer
screen. I have the feeling that Apple is losing more and more ground.”
Comments: Apple also developed a visual programming language using Smalltalk.
It is called Fabrik, and was shown at the 1988 OOPSLA conference in San Diego. I
suspect that it may never be released as a product because Smalltalk is difficult to use
to develop small, stand-alone applications. What Apple has done is bring Smalltalk
programming tools like the code browsers and object inspectors to MacApp, so they are
at least learning from the ideas in the great Smalltalk programming environment.
As far as supporting (unsophisticated) end-user programming, Apple’s
HyperCard has been the most significant product in this area on any platform.
Third-party Mac products like Prototyper, AppMaker, LabView, Extend, and even
ProGraph also provide great support for various kinds of visual programming.
“How can a company ... still design its hardware without at least one
graphics processor?”
Comment: Apple does provide a graphics card with a hardware accelerator. I
suspect it is optional because normal Mac color graphics performance is pretty good
without it. I notices that MPW scrolls so fast on a Mac IIci that I often scroll past the
line I want to look at.
“Forget the Mac, join the NeXT!”
Comment: The NeXT computer is very nicely designed, and is fun to use. However
its poor performance and lack of software has severely limited its market. The trade
magazines estimate that only 8,500 machines have been sold, compared to the Mac’s
few million installed base. New NeXT models were introduced in Mid-September that
are more appealing, but I would not bet the whole ranch on NeXT’s uphill battle against
Apple on the low end, and Sun on the high end.
“However, MacApp... is limited to the Mac only.”
Comments: I too wish that implementations of MacApp existed in the DOS and UNIX
worlds. As it is, you could not have a MacApp running for Windows 3.0 development,
since Microsoft does not provide C++ for Windows developers, and Borland’s Turbo
C++ cannot make Windows applications. I suspect that both Microsoft and Borland will
provide applications frameworks somewhat like MacApp within the next year or so. As
usual, the DOS world is playing catch up with the Macintosh world. The CommonView
system is probably the closest thing to MacApp in the DOS world, but it is not nearly as
sophisticated.
What many developers would like is one all-purpose development system that has
compile-time options to generate code for Mac, Windows, and UNIX. There are systems
like that. One is called XVT, but by trying to be everything to everybody, it does not
provide the best possible support for anyone. It is not nearly as well-suited as MacApp
for created serious Mac applications. Another very portable system is Smalltalk-80
(now known as Objectworks for Smalltalk-80). A Smalltalk-80 program is portable
across most popular platforms, but uses a generic (non-Macintosh) user interface to
achieve that portability. Smalltalk-V has an (almost) correct Mac user interface, but
requires changes as you move from Mac to DOS, and like most Smalltalks, it usually
cannot provide small, fast applications.
All in all, Dr. Stratowa seems to approve of object programming, but feels that
Apple is doing a poor job of providing hardware and development systems. I think he is
right in that they could do much better, but he is wrong in feeling that the world has
left them behind. Apple still provides a better personal computing experience for
end-users that the competition. Furthermore, MacApp using either THINK Pascal or
MPW provides a richer, more productive software development environment than you
will find on competing computers. As products like Aldus’ PhotoShop, Softview’s
FormsView, and Farallon’s MediaTracks have shown, if you want to write great
Macintosh software, you can use MacApp to do it.
The above is, of course, only one more opinion. I assume MacTutor will receive
more heated opinions on a regular basis. I do hope you base your opinions on your own
personal experiences with these products, however - don’t just believe what other
people (including me) tell you.
Language Systems FORTRAN Validated by U.S.
Language Systems Corp.
Herndon, VA
Herndon, VA--October 4, 1990--Language Systems Corp. announced today that
the company’s FORTRAN compiler has been formally validated by an agency of the U.S.
Government, providing users assurance that the compiler gives accurate results.
FORTRAN is the programming language used most frequently by scientists and
engineers.
Language Systems FORTRAN version 2.1 was issued a Certificate of Validation by
the National Computer Systems Laboratory, National Institute of Standards and
Technology (NIST). NIST, formerly known as the National Bureau of Standards, is the
U.S. Government agency in charge of testing products for compliance with established
standards.
“Language Systems has always believed that the most important criterion for
evaluating a FORTRAN compiler should be correctness of answers,” explained Rich
Norling, chairman of Language Systems. “Getting correct answers from a particular
FORTRAN program depends on three basic steps: (1) choosing an appropriate
algorithm, (2) expressing the algorithm correctly in FORTRAN, and (3) having a
compiler convert the FORTRAN into machine instructions without mistakes. The
formal validation confirms that Language Systems FORTRAN version 2.1 produces
programs that correctly implement the FORTRAN 77 programming language.”
The lengthy validation process consisted of 3588 tests and took approximately 8
hours to complete on a Macintosh IIfx. The FORTRAN Compiler Validation System was
used to certify that Language Systems FORTRAN version 2.1 conforms to the ANSI
FORTRAN 77 Standard. A copy of the Validation Summary Report is available from
Language Systems or NIST.
The Language Systems compiler is the leading FORTRAN compiler on the
Macintosh, and runs in versions 2.0.2 and later of the Macintosh Programmer’s
Workshop (MPW) Development Environment. The compiler also contains many
enhancements, which were fully tested by Language Systems’ own suite of over 4,000
tests. A variety of supporting products are available from third parties, including
well-known math libraries from IMSL and NAG.
Language Systems FORTRAN version 2.1 bundled with MPW 3.1 retails for
$495; the company has sent upgrades free of charge to registered owners of FORTRAN
version 2.0.
Rich Norling
Language Systems Corp.
441 Carlisle Dr.
Herndon, VA 22070
Telephone: 703-478-0181
Fax: 703-689-9593
AppleLink: D0354
Symantec Upgrade For TML Users
Kirk Chase
MacTutor
A press release just crossed my desk, and I thought I would make mention of it.
Symantec, in conjunction with TML Systems, is offering an upgrade for TML customers
to THINK Pascal 3.0 for $99. Symantec is also offering Just Enough Pascal for $45 to
TML customers. This offer came on the heals of TML’s announcement of their
discontinuation of their TML Pascal product line. The offer is good until the end of
1990; so if you’re interested, you better take advantage of it quickly. Contact Terri
Sammonds at (408) 725-2752 or Deanne Berry at (408) 725-2759.
On a personal note, I am sorry to see TML discontinue their Pascal line. I
suppose that TML could not put the resources into their Pascal to the degree that
Symantec or Apple could and were therefore forced to follow more profitable avenues.
It is sad to see another development tool disappear. I feel that there are already too few
tools for Mac developers to see another depart.
Still, I feel that we are in a Golden Age of Software Development. Although there
are few tools now, there are increasingly more and more tools for the developer.
Products like MacApp, AppMaker, Prototyper, Serius, FaceIt, Invention Software’s
extenders, and so much more are taking off. And there is a real need out there.
Development work is only going to become more and more difficult with the ever
increasing flood of hardware and software out there. This is taken exponentially when
cross-development becomes more and more a necessity. And now even a “small” tool
developer can make coding enjoyable. Take PopUpFuncs by SciComp Software, that
utility and others like it can make coding more enjoyable. Bulletin boards are getting
more and more snippets of code. There is rarely a need to work with stone knives and
bear skins to bring something to market. It makes me feel better that, in software
development, we have gone from the Stone Age to the Golden Age. Now if someone would
come up with a way to keep your breakpoints and variables displayed between
debugging sessions in THINK C, the THINK C debugger might not be so infuriating to
use.