Even worse, those Macs were not powerful enough to run a software development environment. Developers needed to use a Lisa with a hard drive (a very expensive system) to cross-compile source code into a Mac app, which you’d then save to a floppy which you could run on a Mac.
It wasn’t until the Plus came out (and the HD20 hard drive) that the Mac platform became powerful enough to run its own developer tools.
People expect to cross-compile code for embedded devices, including phones, tablet, watches and streamboxes. But not for desktop computers.
The competing IBM PC/MS-DOS systems all included a BASIC interpreter, and compilers for more powerful languages were available. In 1987, I got my first PC from my college (8 MHz 8088, 512K RAM, dual 360K floppies, CGA graphic, monochrome monitor), and the software package from the university included compilers for Pascal (Turbo Pascal v3) and Microsoft FORTRAN - both of which worked on that dual-floppy system. (The FORTRAN compile required a few disk swaps during the build process, since I didn’t have a hard drive, but it worked).
But now I’m curious about how people developed major commercial apps on the computers of the early 80’s. Did people develop Apple II (or Commodore 64) software on the target platforms? Or did they cross-compile them using other more powerful computers?
Late in the Apple II’s life, when ProDOS and Apple Pascal were available, and hard drives were available (if expensive), it would certainly be possible to develop major apps on the target platform and I’m sure apps like AppleWorks were developed that way.
But what about before that? Were all those games and productivity apps sold at that time developed on an Apple II+? I honestly don’t know - at the time, all the software I wrote was pretty simple and was written in AppleSoft BASIC.
Developed by Rupert Lissner,[4] the original AppleWorks is one of the first integrated office suites for personal computers, featuring a word processor, spreadsheet, and database merged into a single program. It was released in 1984 as a demonstration product for the new 128k models of the Apple II line.
In 1982, Apple published Lissner’s Quick File, a database program that closely resembled what would become the AppleWorks database module, on both the Apple III and Apple II. Apple favored Apple Pascal at the time, so Lissner initially wrote Quick File in that language at Apple’s request. Lissner preferred coding in assembly language, however, and soon rewrote Quick File in assembly on his Apple III and, by summer of 1983, he had added word processor and spreadsheet modules as well.
This was the case with Microsoft Word through V5 as well – my understanding is that a lot of that version of Word was 68K assembly language, and the unpopular Word V6 was their attempt both to combine Windows and Mac development and to get the whole thing into a higher level language/development environment. (The 68K assembly ran quite well in emulation on the PPC, but running emulated assembly is in no way a sound long-term application development strategy.)
My memory is that Apple II and Commodore 64 work was generally done on the platforms themselves, and that serious software development was largely in 6502 assembly language (with a much more limited concept of a “software development environment” than was required once developers needed to have a GUI, windowing, menus, and so on). I think Z80-based CP/M systems were also generally programmed in assembly language.
An exception among the computers of that era was the TI-99/4A – some programming could be done on the computer itself, but significant development required a TI-990 minicomputer.
This is not too surprising. I would expect most non-trivial apps to be written in assembly, simply because compilers at the time couldn’t produce code as optimized as what they produce today and standard libraries consume a lot of RAM - too much to be practical for small systems.
But even writing code in assembly may be difficult to do on-device. You need to edit (floppy) disks full of text files containing the assembly source. Then you need to assemble it to disk files. Then exit the development environment and load/run the app (possibly needing a reboot).
I would assume that professional developers at the time did this with two computers (one to assemble/build the app and one to run it). But that can still be a slow process.
This makes a lot of sense to me. The Apple III was more powerful, ran SOS (a predecessor to ProDOS) and probably had more robust development tools.
Also not surprising, given what I understand about the 99/4A. At the time, I was curious about what it would take to write software for it. If you didn’t want to write your programs using its ROM BASIC, you needed to buy its expansion chassis, a P-Code interpreter card, a floppy drive and the Pascal development environment software. Which bumped the price of the system from something quite affordable to one of the most expensive personal systems sold at the time.
And I’m sure no commercial software used that system, because most software was shipped on ROM cartridge or on floppy, and (as far as I know) did not require the P-Code card.
Update: It looks like there was almost no third-party commercial software at all. Mostly because of corporate policies that appear to be deliberately hostile to developers. See TI-99/4A - Wikipedia
Having done both assembly coding (on a pdp11/20) and object oriented programming in objective C and Swift, in many ways I have found assembly to be much more straightforward. There were a moderate number of op codes and addressing modes to be learnt but the machines I coded on had a kind of logic which escapes me when using object oriented code.
Of course the programs were much simpler in the old days. In addition it would be hard to take advantage of modern processors which benefit from out of order code.
I did a bit of assembly programming over the years and IMO, the comfort level is directly related to the platform’s CPU architecture.
Big iron systems (IBM s/360 and DEC VAX) were a pleasure to code in assembly. There were so many advanced instructions that it was almost (but not quite) as comfortable as writing code in a language like C. Which doesn’t surprise me that much because (if I remember my history), C was originally designed to closely align with the DEC PDP instruction set.
On micros, I had no problem writing assembly for the Motorola 6809 (on a TRS-80 CoCo), but I got spoiled by its robust instruction set (pretty much an 8-bit version of the 68000 instruction set), so when I tried to learn 6502 (for an Apple II), I decided I didn’t want to bother trying to code down to that level.
Later on, however, when RISC became popular, the idea of hand-writing assembly code just became painful. These chips were (and still are) designed for compilers and part of that involves removing instructions that compilers don’t typically use, which are unfortunately, often instructions that are very useful when hand-writing assembly code.
But I never had a problem with object oriented programming. Maybe because I learned it when it was still relatively new, starting with Borland’s OO extensions to Pascal. I also dabbled with Actor (I won a copy of it at a trade show), but really took a liking to C++ (starting with it from before it was an ISO standard), and I continue to use it extensively today.
I went through Apple’s tutorials for Objective C and Swift. I like them, but since my work doesn’t involve developing apps for Apple platforms, I never got around to doing anything interesting with them (and at this point in my life, I have very little desire to develop software in my spare time after doing it for 8-10 hours a day for my employer ).
I was very impressed with the 6809 when it was released. It was nice that it was in the inexpensive color computer which ran OS9, a variant of Unix if I remember right.
I got my start programming a pdp8/s computer I discovered in surplus in the physics dept. while I was a grad student. I wrote all my programs in short 1 page routines and then punched them out in an ASR33 teletype. I entered the code in the switches. It was extremely enjoyable.
I fell in love with the pdp11 architecture when it was announced and of course was very partial to the 68k when the 16 bit micros came out (and I developed a lifelong dislike for x86 - you can imagine my euphoria when Apple switched to ARM which I am currently learning to program in asm).
My final foray into assembler was coding for the Moto 56001 DSP in the surplus ‘040 NeXtstations which ran my experiments before I retired. The DSP was very confusing to program since data were “signals” with the binary point on the left which meant that moving an 8 bit quantity into a larger register resulted in it being left-justified. A constant source of errors.
OS-9 was the high-end OS available for CoCo systems with 64K or more and a floppy drive. But since I had neither, I didn’t use it. (I used a 16K CoCo 1, Extended BASIC and ROM cartridge editor/assembler/debugger, using cassette tapes for storage).
There were not a lot of inexpensive developer tools on any platform at the time. On the PC platform, Borland’s Turbo languages (Pascal, C and later C++) were the most affordable, but as a college student at the time, I’m really glad I qualified for educational discounts. But Microsoft’s and Intel’s compilers (which were better products) cost a lot more.
On the Mac platform, the THINK compilers were common, mostly because they were far more user friendly than Apple’s MPW environment. And anybody could buy THINK, while only paid-up members of Apple’s developer program could get MPW. When the PowerPC platform came out, Metrowerks’ Code Warrior pretty much stole the market from THINK, being objectively better in almost every respect.
Actually, shortly before the end of the PPC era, IBM made its C and Fortran compilers available free to the Mac community. I found the Fortran code ran significantly faster than gcc (using f2c), sometimes by a factor of nearly 2.
MacForth came out in early 1984, and was excellent. It got into nearly every nook and cranny of the OS and disk structure, and had its own assembler, compiler, text editor and tools. I remember that there was a fair amount of commercial software written in it, but that’s where my memory gives up.
Absoft’s Fortran for the Mac came out in early 1985, and was also excellent. It included some of the wonderful VAX extensions, which lets us port some of our smaller VAX data analysis to our macs. That was a lot slower in principle, but it often finished sooner because it didn’t have to share processor time. Unfortunately, MS bought it (leased it?) and ruined it, but Absoft eventually got it back and made it great again though the price became too high for me to get it. Sadly they went out of business in 2022.
I did a fair amount of programming in assembly code, both back in Ye Olde Days (in college I wrote VMS assembly code for the Vax – good way to learn, as the Vax architecture was very clean and well-thought out IMO), and then later in 2000s, writing mixed C/assembly embedded firmware for instruments/appliances that used cheaper and less powerful Motorola processors.
The best rule-of-thumb I have for assembly programming is this: coding best practices are extremely valuable for higher-level and OO languages, but they are critical for assembly programming. Quality commenting particularly stands out: you’re going to end up doing some tricky stuff, and you definitely want to explain why you did for those who come later (and this includes you, when you come back to it 6 months later).
As to OO nostalgia, I have a fondness for Simula 67 back in the 70s; it was a hop, skip and a jump from Pascal, but had all sorts of great OO (and non-OO) features that few (if any) other languages had at the time; and the compilers ran on Digital PDP platforms.
There was a fellow named Hal Hardenberg around ‘81 to ‘85 who wrote a newsletter called DTACK Grounded about souping up 68000 CPUs by grounding the DTACK pin, which forced synchronous memory access rather than the slower handshaking normally used (DTACK means Data Transfer Acknowledged).
He once called the language C “stylized pdp-11 assembly language”. The better architectures (emphatically NOT X86) like the VAX, 360, pdp-11, 68k, PPC, National 32032, etc. were indeed very much like programming in a high level language. In my initial forays into ARM assembler, it is in this class though with a slightly steeper learning curve due to the (clever) combination a number of operations into a single instruction.
heh! back in 1984/5 my boss bought two macs and expected me to write code on it with macforth. loved losing all my work when the box locked up and rebooted. repeatedly. macforth, however, was a hoot.
Ah yes, Forth! That brings back memories. There was also MOPS, and PowerMOPS from Mike Hore. A quick google shows that Mops still lives, and is even being ported to ARM! I thought it was gone for good.
When I got my first Mac in 1984, I had been doing MC68000 development on a Motorola EXORcisor board for some time. The 68000 chip had a hand-etched serial number (409, IIRC). I used the EXORcisor to assemble code for the 128K Mac. I ported over my personal Forth dialect so I could do on-board programming, working from a stack of xerographed sheets of documentation from Apple, soon replaced by the “phone book” developer docs.
I wrote an awful lot of code on the Macintosh 512 before the Plus came out. I worked for one of the national labs and we were automating a factory. The control and server computers were DEC MicroVAX II computers and all of the workstations were 512K Macintoshes. This was before Appletalk and all of the communication was over serial lines. There were multiple C development environments available from third parties (but not from Apple–you’re right about the Lisa requirement there).
I used a PDP-8 also, but only for a one semester course in college. I learned a tremendous amount about computers though; prior to that I only knew FORTRAN-IV, submitting decks of punch cards to the computer center.
).