Today it’s hard to imagine how daunting the original Macintosh API was for programmers, especially compared to the complexity of the cocoa programming environment.  But most programmers were used to the extremely sparse world of the text terminal (glass TTY), in which they had to learn only how to read and write text on the terminal, and read and write data to files.  If you had a Commodore 64 or Apple II you might know something about bitmapped graphics, but learning to draw on the screen was basically about learning the hardware, not about operating a complicated set of software libraries.  Some programming languages had libraries with subroutines for communicating with terminals.  For example, in Pascal, there was writeln (which would write a line to the terminal) and readln (which would read). 

    Another thing that may seem odd is the popularity of the Pascal language.  Through the 1960’s and most of the 1970’s, FORTRAN IV was the most commonly used high level programming language, and was the language taught to scientists and engineers in school.  FORTRAN IV was not a stack-based language.  Subroutines saved their return addresses, local variables and parameters in statically allocated data structures called activation records, so FORTRAN IV code was non-reentrant, and recursive programming was not practical.  Even though much good work was (and continued to be) done with the language, modern programming thought had turned away from the FORTRAN design.  The new way of programming was embodied in the Algol-60 and Algol-68 specifications.  I say specifications, because these languages were designed without too much concern for implementation.  They were complex and powerful computer languages.  It was pretty hard to write a compiler that could handle all the complexities of programs written in the full form of the language.  It was also complicated for programmers.  Niklaus Wirth was a computer scientist at Stanford University working on languages and compilers.  After the Algol-60 specification was released, he became interested in simpler, easier to learn and easier to implement Algol-like languages.  He invented several such languages, including Pascal.  In 1970, Wirth produced a Pascal compiler written entirely in Pascal.  Pascal implementations started appearing in the late 1970’s, most notably the highly-portable UCSD Pascal system that was released in 1978. 

In 1979, Apple offered a Pascal system for the Apple II, and one was also offered for the ill-fated Apple III, released in 1980 as the successor of the Apple II. Pascal was the coolest language to know in the early 1980’s, and it became the official language of both the Lisa and the Macintosh.  Lisa software, including the operating system, were mostly written in Pascal, and the Lisa Programming Workshop was designed for Pascal programming.  The Macintosh operating system was largely written in assembly language (to optimize for memory space), but its functions were intended to be called from Pascal. 

    Maybe I should say something about BASIC.  BASIC was a popular language in the microcomputer world.  It was a FORTRAN-like language with the same problems as FORTRAN.  But it was interpreted, not compiled.  This sounds like a bad thing, because interpreters are slow.  But it was a good thing, because debugging was greatly enhanced in an interpreter.  You could single-step through a BASIC program to see where an error occurred.  Of course, (Microsoft) BASIC was famously used with the Apple II, and a version became available for the Mac in the summer following the January 1984 release of the Macintosh.  But it was useless.  It was an okay BASIC, but it treated the Macintosh like a terminal.  Nobody wanted to program the Macintosh that way.  About a year later, Microsoft produced a much better version 2 of Mac Basic.  But I don’t know who would have cared.  The Mac API was designed to be called from Pascal, and Inside Macintosh assumed that was the language you were using.  Things were hard enough when you used the language described in the documentation.

MacPascal

    MacPascal was an Apple product, but it wasn’t created by Apple.  It was really created by a Massachusetts company called THINK Technologies.  It wasn’t a Pascal compiler, like the one in the Lisa Workshop. You couldn’t make a real program with it, because... it was an interpreter.

When you started it, it gave you a text editing window (called Untitled) in which to write your program, a window called Drawing, and one called Text.  It auto-formatted the Pascal code you wrote in the code window, and used immediate changes in typeface to indicate an error if you wrote something that was not syntactically correct. Nowadays this is done using colors, but in the black and white world of the early Macintosh, it was done with type styles (bold, outline, etc). More subtle errors not caught this way could be found by picking Check from the Run menu, or by trying to execute your program.

The thumbs-down hand pointed to the line with the error.

Two other windows, one called Instant, and one called Observe, were available from the Windows menu.  In the Instant window, you could write any valid Pascal expression that made sense in the current context of the program, and it would execute.  In the Observe window, you could enter the name of variables and observe their values as they changed.  These things are all common in advanced programming environments today, but were amazing and unexpected in 1984.  I guess the Instant window is still a little advanced for most of today’s IDEs. 

    Because in MacPascal, your program was running within the context of another program (the interpreter), you did not have to create resources, initialize menus and windows, or use the Macintosh memory manager.  Most of the complexities of the Macintosh Toolbox were removed, at least at first.  You could still access those parts of the Toolbox, but you didn’t have to do it all at once.  You could learn one thing at a time.  In particular, MacPascal was a testbed for learning Quickdraw graphics.  Quickdraw procedures that draw on the screen, like LineTo and FrameRect, would immediately be directed to the Drawing window.  Likewise, the standard terminal text functions in Pascal (like writeln) would immediately put text in the Text window.  This meant that standard Pascal programs you might have found in a textbook on programming in Pascal would still work and do sensible things.  MacPascal was a set of training wheels, simultaneously for learning Pascal, and for learning the Macintosh API.  And it did this by applying user interface tricks nobody had ever seen before.

    One bad thing about MacPascal:  It was copy protected.  You couldn’t copy it to your hard disk.  You had to have the original floppy disk mounted.  This was fixed in version 2.

The Integrated Development Environment - Lightspeed Pascal

    As happens with all good teachers, the stuff MacPascal was teaching became obvious after a little while. Everybody wanted to make native Mac programs that could run outside an interpreter.  THINK Technologies introduced their first Pascal compiler, without Apple’s name on it, at MacWorld in Boston in August 1986.  Lightspeed Pascal introduced the rest of the features that we now associate with modern Integrated Development Environments.  A project file contained all the object code and preference information (everything but the source code and finished application) associated with the project.  Opening the project file would initialize Lightspeed Pascal with the information for that project, ready for more coding and compiling. It was reasonable to expect that there would be a price to be paid for this.  Without the interpreter, I would expect to still have syntax checking, but what about the Drawing and Text windows?  Amazingly, Lightspeed Pascal could take a MacPascal source file, and (after you created a project file for it) compile and execute it exactly like MacPascal. 

The Text and Drawing windows were still there.  In the compiled version of the program, those windows could still be used, so simple programs did not need to create their own windows.  And, the Instant and Observe windows were still there, and still worked the same as always.  Breakpoints were little stop signs in the left margin of the source code window.  None of the benefits of the interpreter were lost in the process of converting to a fully capable compiler, and there was the least possible change in the programmer’s user interface.  There was one new window, and it was an eye-opener.  It was called LightsBug.  This was an obvious reference to MacsBug, the object level debugger.  It showed the values of all the registers, and could provide a dump of the contents of arbitrary regions of the heap. 

THINK Pascal, Object Pascal, and THINK C

  THINK had to give up the name Lightspeed because of some trademark issue, and Lightspeed Pascal became THINK Pascal. The apogee of THINK Pascal was version 4, running in System 7.  It lost nothing in the process, and most of what it gained could be seen in the LightsBug window.

In addition to showing registers and the heap, it was an inspector for all local and global variables, could examine data structures, by their field names, and included a stack trace (in the upper left corner.  By this time (1992), Niklaus Wirth had collaborated with Apple in the creation of an object-oriented Pascal variant, called Object Pascal.  Apple developed a class library in this language, called MacApp, inspired by Smalltalk-80.  Without any real change to the user interface, THINK Pascal incorporated Object Pascal, and became a great environment for programming in MacApp.

    All things cool become uncool eventually, and once everybody knew Pascal well, it quit being the language we wanted to learn.  Now we wanted to program in C.  Pascal and C are very close relatives.  They are both simplified Algol-like languages.  They look different, but if you can write a Pascal compiler, you can write one for C.   THINK Pascal led to THINK C, which had almost all the same great features.  Apple also changed MacApp from Object Pascal to C++, and THINK C incorporated C++ and the new MacApp.  THINK was ultimately bought by Symantec, who continued the C++ product line for a while. The end came with the switch to PowerPC, when  Metrowerks Code Warrior outpaced Symantec C and won its market.

The Modern IDE

   MacPascal-THINK was the source of the modern development environment.  This was 1986.  The first usable version of Windows was still 9 years away.  DOS was effectively a text-only world, and DOS programming tools were crude stone-age things.  Unix programmers were writing their source code in vi and compiling it on the command line.   Hmm.  I guess a lot of them still do.  Much later, Windows and (some of the) unix world would adopt the same programmer’s user interface as THINK.

    The same way that the Macintosh invented the user interface for computer users, THINK Technologies invented the user interface for programmers.  The project file, source level debugger, variable browser, these are the user-illusion that programmers expect today. They are really the creation of the THINK programmers, Terry Lucas, Peter Maruhnic, Jon Hueras, Steven Stein, Wynn Newhouse, Rick Tompkins, and designers Andrew Singer, Mel Conway, and Jon Hueras.

-- BG (basalgangster@macGUI.com)