The Sordid Truth

By Kirk Chase, Editor, MacTutor

The Sordid Truth About Apple Why Don’t Those Idiots Ever Do Anything Right?

Dave Wilson

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 nonspecialists 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--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

Symantec Upgrade For TML Users

Kirk Chase

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.