Some programs achieve perfection by simplicity.  They have only the features they need to do some essential job.  If its design is good, learning a program like that should be quick.  But some other programs are whole worlds unto themselves, and fully mastering them takes a long time, or sometimes is never complete.  I like simplicity, but the Mac programs I love the most have all been giant complex things.  They are:  Mathematica, Adobe Illustrator, and the Macintosh Programming Workshop. 

    MPW was introduced in September, 1986, about the same time as the introduction of the Mac Plus, which was the first Mac to have enough memory to accommodate it.  It was a product of Apple’s recognition that the Lisa would not suffice as the development platform for professional Mac development, even at Apple.  In many ways, it was an elaboration of the Lisa Workshop, and it’s resemblance to the Lisa Workshop went beyond the name.  But it also reflected the esteem that most professional programmers had for the unix style of programming. It was obviously an homage to the unix environment.  The unix programming philosophy at that time was focused on workflow.  Unix tools were programs with effectively no user interface, that were invoked by typing their names in a terminal.  They typically received their data from files, and wrote the outcome to a file.  They were chained together by scripts, that moved data files through a sequence of tools.  Compiling a program was the archetypal unix task, and programmers were (I guess still are) the biggest fans of unix. 

    At that time, I was programming mostly in C using Consulair Mac C.  I also had a copy of Lightspeed Pascal, and had started a programming project using that environment.  Mac C was a simple, elegant system.  Separate simple programs were used for editing, compiling, linking, resource compilation, and a batch facility allowed them to be automated.  In a way, it was the Macintosh equivalent of a unix shell.  Instead of building programs by typing a command, it was done by selecting a menu item, but otherwise it was the same.  Mac C had no source level debugger.  I used TMON, which was a great object level debugger.  Lightspeed Pascal seemed revolutionary to me.  One program did everything, and all the information about a programming job was kept in a single database.  Source files or libraries were added to a project using the Standard File Dialog.  The debugger and editor were the same program.  Stepping through a program was done in the same editor you used to write it.  I wasn’t completely sure I wanted to go completely over to such an opaque system, but I was pretty sure I didn’t need a terminal emulation window with a unix-type shell.  In 1987 I was looking to give up Mac C, because the Consulair system did not generate code for the 68881 floating point processor, and I was getting a Mac II to use at work. 

    Looking back, I wonder why I didn’t just do everything using Lightspeed (later THINK) Pascal.  The truth is that I just wanted to program in C.  Not for any good reason. I just thought C was what was happening next.  I had already learned Pascal, and I wanted to program in C.  Lightspeed C was released about the same time as MPW.  I thought I might go with that instead of MPW.  A friend got Lightspeed C and I tried it for a little while.  I was disappointed with it.  It didn’t seem to me to be the C equivalent of Lightspeed Pascal.  It lacked a writeln window (I guess for C it would be called a printf window), and I thought the debugger wasn’t as good.  Maybe I would have changed my mind if I’d used it more, but I decided to get MPW, without trying it at all.  As it turned out, MPW also had no printf window, and it didn’t matter at all.  And both programs were expensive.  Because Apple (much) later offered MPW as a free download, it is sometimes forgotten how expensive it was.  I don’t remember what it cost exactly at the time I bought it, but I have an APDA catalog from much later (mid-1990’s) that lists THINK C at $255.00, and MPW system with C compiler and at $350.00.  APDA was the Apple catalog store for programmers.  It was the only source for MPW, and they sold lots of third party programming tools but usually you could find those things for less elsewhere.

The  MPW Shell

    The connection to unix was acknowledged in the name, MPW Shell. Using a command line shell should have seemed to me like a step backwards, but I didn’t even see the command line interface.  What I saw was a text editor.  It was the best text editor I’d ever seen.  It could handle giant files without slowing down.  It could split a window, so you could look at two different parts of the same file at the same time.  And it had the very best search and replace facility I’d ever seen or heard of.  Actually, I still don’t have an editor that can compare to it for search and replace (and yes, I do use BBEdit).  When I saw the command line interpreter, I also didn’t see unix.  I saw Smalltalk-80.  Smalltalk had a window called System Workspace, in which there were a number of useful Smalltalk commands, and you could add your own just by typing it in, because the System Workspace was a regular text window.  But if you typed a line of Smalltalk code in the window, selected it, and selected print it from the yellow-button menu, it would execute the code and write the result of the calculation immediately after the selection.  The result would stay there as a reminder until you erased it to redo the command.  Just like Smalltalk-80, MPW started by opening a window called Worksheet, that had a bunch of useful commands in it.  You could select one of them, and execute it by punching Enter, or shift-Return.  The result was written in the same window, just below the executed code.  If you are used to a unix shell, this may look familiar, but there are several key differences.  First, there is no terminal window.  The commands are written into text editor windows.  The Worksheet is a text editor window exactly like any other, except that it’s alway there; it can’t be closed. MPW commands can be typed into any window and executed. Any number of commands can be typed as lines of text and executed as a group.  The output of the command becomes text in a text editor window, not just scrolled up text in a terminal window.  Editing text, executing scripts, collecting the output of commands into text files... all are done in a single type of window and integrated together.  This symmetric design was typical Apple.

MPW Tools

   A lot of tools came with MPW.  Practically every kind of tool you could think of was there.  The most obvious and critical were the compilers, assembler and linker.  C and

Pascal came with MPW, along with a good 68000 assembler.  Also important was the resource compiler, Rez, and it’s inverse, DeRez.  Rez was like RMaker, in that it took a text description of resources and compiled them into resources that could be added to the resource fork of a program.  The Rez language wasn’t the same as the resource description language used by RMaker, but it was similar and easy to learn.  DeRez was also great.  It took an existing resource file and decompiled it into the Rez text source.  So you could make resources any way you wanted to, and DeRez would turn them into an MPW source file.  ResEdit was the easiest and best way to make most resources.  Later I used Resourcerer.  In all cases, I could incorporate them into my project using DeRez, and store them as human-readable text files. Rez would restore them to resources during a build.

    A lot of other tools were not directly related to programming.  Some did typical unix tasks like listing the files in a directory, comparing two files for differences, or searching for text in a file or set of files. In addition to executing tools, unix shells generally have their own set of built-in commands.  This was also true of MPW.  It’s built-in commands were especially suited to text processing tasks, like search and replace based on regular expressions.  MPW text processing was live, in the sense that you could watch a script in one window operate on text in another.  Furthermore, MPW regular expression processing was much richer than the unix equivalent.  It had a more powerful set of expressions.  It also made use of the extended character set of the Mac.  Unix shells imbue some ordinary characters with special meaning in regular expressions.  For example, the dollar sign $ represents the end of a line.  In MPW, the corresponding symbol is the infinity character ∞ (option-6).  There was less need to use the escape character ∂ (option-d) to indicate that a special character should be taken literally.  MPW regular expressions could be used in a regular search and replace dialog box, as well as executed as scripts.  This made MPW by far the most useful text processing tool I’ve ever seen, even now in OS X, with all the unix tools I could ever want. 

The Mac Advantage

    The most compelling thing about MPW was in stuff that nobody had ever seen before, either in Smalltalk-80 or unix.  There were tools that could create a new menu.  It would be inserted into the menubar and work like a regular Mac menu.  When the menu choice was selected, it would execute a script.  Other tools could put up dialog or alert boxes (even the Standard File Dialog) and return the choice made by the user.  In this MPW might be thought of as a predecessor of Automator or Applescript Studio.  The most amazing thing was Commando.  This facility created a dialog box to help users create correct commands to evoke tools.  It was the right way to type a command if you were a new user to that tool.  For complex tools, like a compiler or linker with many options, the resulting dialog would walk you through all the options, explain what each did, and create a command line that could be immediately executed, or saved as text to be used later (perhaps as a line in a script).  Making commando dialog boxes was easy, so if you wrote a tool yourself, you could easily create a commando dialog for it.  It was also easy to rearrange the layout of an existing commando dialog box, or to customize it.  Commando was also available on Apple’s own version of unix, A/UX.  I sure wish I had that for the command shell on OS X.

Automating the Build Process

    At compile time, the compiler needs to be told where include files can be found, and at link time, the linker has to be told where to find the libraries and object files.  These can either be implicit (i.e. fixed in a particular place in the file system) or made explicit by environment variables.  In MPW, like the Consulair C system, there are a set of environment variables that tells the system where to look for all that stuff. 

In MPW these are set in a couple of files containing scripts that execute when MPW starts up.  The places where everything is kept can therefore be customized as much as you want.  The default arrangement was a good one however, and it kept everything where it was when MPW was first installed. 

Building a program was controlled by a Makefile.  Makefiles were a little complicated, but there was an amazing commando-like tool, called CreateMake that guided the user in creating a good Makefile. 

Just One Program

    MPW was a single program.  On the Mac at that time, that meant it could do only one thing at a time.  Unlike a unix shell, there was no way in MPW to send a command off to be executed and have the shell return to await another command.  Likewise, you couldn’t get one script going in one window, and then start another script in a different window.  Because of the similarity to the unix shell, this shortcoming was pretty obvious.  Late in the life of MPW, it came with a cool second program, ToolServer.  Toolserver was an isolated MPW interpreter, without a user interface.  It could host MPW tools, and could be launched from MPW, or by an Applescript, or by  AppleEvents created by any program.  If passed a script, it could execute that as a separate program (in System 7), and could execute in parallel with MPW. 

Compiling and Debugging

    One of the strengths of the Think Technologies Lightspeed products was their debuggers.  In MPW, build-time errors were addressed in MPW, whereas run-time errors were handled by a separate debugger.  MPW compiler errors are legendary for their humor. 

Error messages were added to the Line command and a line number, so that you could execute the error message and it would take you to your source code and highlight the line containing the error.  This elegant solution encapsulates both the modularity and the integration that was the style of MPW.

    The debugger that initially came with MPW (starting in 1989) was called SADE.  It was a separate program, but was similar to MPW in appearance and in underlying mechanism.  It also was a text editor and command interpreter.  It read symbols files created by MPW, and provided control over execution of the program that easily matches anything in use then or today.  In addition, the debugger had outstanding facilities for watching variables.  Its scripting capability meant that you could attach a script to a breakpoint or watchpoint that would write out the values of some variables and immediate continue.  This kind of control over the debugger is rare today, although available to XCode users via gdb.  SADE was incredible when you got good at it, but like MPW it was a big program with lots of features.  It could be intimidating at first, and it took a while before you felt really at home with it.  Eventually, Apple created two simpler but less capable debuggers for MPW, SourceBug and the PowerPC Debugger.  Because of the modular nature of MPW, it was possible to take your choice of debuggers.

    One last thing to mention about MPW was its expandability.  It was easy to write an MPW tool, and because they were similar to unix tools, it was easy to port programs from unix to MPW.  This held for compilers as well as simple tools, and so there were a host of compilers available for MPW, for a lot of different languages.  Toward the end, Apple distributed third party programs with MPW for C and C++.  Because MPW used a uniform and well-documented object file format, programs could be made from pieces written in any language, and linked together.  MPW went into decline during the late 1990’s apparently because Apple programmers decided they preferred the MetroWerks CodeWarrior IDE.  CodeWarrior was a successor to THINK C, and was based on the design principles pioneered by THINK.  It was great, and this kind of environment was the way of the future, but it was just a programming environment.  MPW was much more than that, and we will probably never see it’s like again.

-- BG (basalgangster@macGUI.com)