A Life of Software Development : Object-Oriented Programming and MacApp

1987-1991

When we decided to program an Accounting Package on the Macintosh, we started to look into the development tools that Apple offered on the Mac. The main development activity in the company was still going on with Turbo Pascal on PCs and many new modules were being developed. Seeing that the development group was doing fine, I brought together a small group to work on the Mac platform.

A new paradigm in software development had started those days and was named Object-Oriented Programming (OOP).

Think Pascal was one of the good development environments you could use on the Mac. If you wanted to be on the safe side, you could use Apple's Macintosh Programming Workshop (MPW), since it would be adapted quickly to changes in the Macintosh OS.

Think Pascal was more user-friendly, as compared to the command-line-based MPW, and it was also much cheaper, since MPW targeted professional, rather than hobbyist, users.

Both Pascal languages were also object-oriented in the line of Object Pascal.

Think also had a C compiler called Think C, but it was essentially a precursor of C++ with the basic object-orientation concepts such as (single) inheritance.
Think technologies were later on bought by Symantec and the products were renamed to Symantec Pascal and Symantec C. Symantec could not adapt the transition of the Mac from the Motorola 68000 family of processors to the PowerPC chip developed by Apple and IBM. It lost its market share to the competitor Metrowerks and their development environment CodeWarrior.

Before all this happened, we had started to look into MPW Pascal and was trying to find out more about object-oriented programming. None of us had worked with the original object-oriented language, namely Smalltalk. After developing for many years using Structured Programming, this idea of objects and sending messages to objects was quite new for all of us. By introducing constructs called Classes in the code, we were re-defining the responsibility of control in the software by distributing the responsibility between these classes. Basically a class was a programming construct that kept both data structures and the logic to deal with these data structures in the same entity. When the programming logic was confined to an entity like this, it would usually be easier to debug. Objects were instances of a class that all shared the same features (data and logic) inherited from the class.

The logic or functionality embedded in a class would be open to the outside or within a class through methods. A method was essentially like a subroutine belonging to an object of a certain class and was invoked through a message. The message could have parameters (just like a subroutine) but would only be sent to objects belonging to class which defined the method.

If object-orientation was just limited to a redistribution of responsibilities, it would not have been so interesting. The interesting part came when you used the concept of inheritance and re-use. It was possible to take a class and create a variant of it by using most of its code, but modifying it to display a different behavior when required. This variant was called a sub-class and was a way to minimize the total code development by re-using the code for shared behavior.

Another difficult concept to understand was the concept of polymorphism. This involved the prospect of having the same function do different things in objects that are related but belong to different classes. So, if you sent the message to different objects, the behavior could be different.

After understanding the basic principles of OOP, I noticed the difficulty of using this in the current visual environment of the Macintosh. Most of the objects you would have to deal with in a visual environment were Graphical User Interface (GUI) objects and these had to have a close association with the internal Operating System functions. Most of the OOP books used classes which were quite abstract and generic, but it was difficult to apply this in a GUI like the Mac OS GUI. Here, the concept of Application Frameworks came into the picture. Basically, Application Frameworks gave you the necessary classes to deal with the GUI or other aspects of the Operating System such as the File System, peripherals and so on.

Apple had created an Application Framework called MacApp that helped developers deal with the complexities of GUI-based development. It really made life easier, since you just had to pass the right messages to the right objects and GUI actions or OS actions just followed.

To get a good hold of MacApp, I and a colleague of mine went on a one-week MacApp course to the European Headquarters of Apple Computer in Paris. The instructor (a Frenchman of Polish origin) was really good in OOP concepts and MacApp, and did a lot of hands-on. I was pretty impressed by Apple's HQ, which was very modern and had a lot of automation for its time.

Everything in MacApp was derived from a top-level class called TObject. Since you could use events (called Apple Events) to communicate between applications and from an application to the OS, an important class you used frequently was TEvent. Everything that represented a command to be executed would be encapsulated in a class derived from TCommand. Documents would be represented by sub-classes of the TDocument class. Every GUI or Operating System element would be derived from one of the top classes.

I did my Mac development using a Mac Classic, then switching to a Mac SE. However, it was clear soon that there was not so much of a local accounting software market for the Mac, since the market was already dominated by several accounting packages for the PC and Macs were in the decline.

During our brief adventure with the Mac platform, I had decided that I did not really enjoy developing accounting and similar financial software and made up my mind to leave the company and continue my academic career. This move also signalled my return to the Mac development environment, since academic environment gave me some freedom to work on any platform that I wanted, although most of the university network consisted of PCs.

I went back to the university as an assistant and completed my PhD thesis (still working on the PC, of course, and with Turbo Pascal). In the meantime I had become the de-facto manager of the department labs, which had some PCs, a few Unix workstations and a few Macs.

After the Thesis dissertation, I was offered an Assistant Professorship. Once I joined the faculty, I asked for a Macintosh to use personally. If I'm not mistaken, I had got a Macintosh IIci. IN a few years I would update this and get a Macintosh Centris 650, a "very fast" computer which had a 25 MHz processor!

Most people were using PCs or Macs, and they were also using these personal computers to connect to the university mainframe or various Unix workstations in the different departments. The IT infrastructure of the university in those days can best be described as "chaotic", since every department was managing their own subnetwork in their labs, and the best they could hope was to provide some entry points to their networks and also provide Bitnet mail support (for those of you who are not familiar with Bitnet, it was the precursor to the academic Internet and existed from 1981 to 1996, then disappeared into obscurity).

One of the courses I would teach would be Principles of Programming, and I would have to teach Pascal. I started to develop detailed course notes, especially emphasizing the use of data structures optimally and also relying on course projects to give students a practical insight into programming. Since most of the students had a PC or used a PC lab, I had to continue my lectures based on a PC. However, this did not prevent me to do my own research on Macs.

I had continued to get more and more familiar with the MacApp framework. In the meantime, Apple had released the 3.0 version of MacApp implemented in C++. This was a good opportunity to get into C++. I had had very little exposure to C, working with object-oriented Pascal most of the time. In a sense this was good, since I would not bring any "bad habits" that would be typical of C programmers. I also enjoyed the pure object-orientation and strong typing of C++, since these were rather weak in Object Pascal implementations. MacApp would be my main development environment in the near future, but some of my career moves would bring some surprises to my software development adventure.

(Microsoft incorporated a lot of the MacApp concepts in their Microsoft Foundation Classes library later on, and application frameworks became a regular feature of software development environments. Coincidentally Microsoft classes would use a C in the name, similar to the T used by MacApp classes as a prefix).