Testing code required copying it onto a floppy disk and popping it into a Mac. We probably would have been a lot more productive if any of us had ever heard the words "unit test". (We were a young team, everyone in their early 20s or even late teens.)
I was born in time to experience the internet when it was a lot more fun and experimental, which I definitely am grateful for. I hope there are more "moments" like this in the future, though I can't help but feel they're mostly over when it comes to computers and technology. Things just can't stay scrappy and experimental forever.
I think the moments are out there still; you just have to seek them out. I wouldn't say working on Apple ][, Lisa, early Mac or other early PC efforts were as obvious and groundbreaking as they seem now. I think about a lot of parallel efforts going on at the time that I wish I could go back in a time machine to work on: Symbolics Workstations, early Wavefront/Alias software, Self, Smalltalk, Dylan and other languages that didn't become mainstream.
There is so much out there that isn't over in computers and technology. It might be helpful to think about things that seem impossible, crazy and totally economically unviable. Sometimes we can let finding markets, solving scaleable problems and generating 10x returns for our investors cloud our vision.
We did move to Mac-based development after not too long. I have zero memory of why/how that happened, but I'm sure it was clear even at the time that the Mac was the more sustainable long-term platform (also the Lisas were insanely expensive). Still, for a while there it was a real stretch to squeeze a reasonable dev environment into Mac hardware. I remember – and this feels insane as I'm typing it, but it happened – at some point we actually paid someone to fab an add-on circuit board that we somehow glommed into our Macs (these were probably 512KB or 1MB models, I can't remember) that doubled the RAM size. The additional RAM couldn't be used for normal applications, it somehow manifested as a RAM drive. We had one RAM drive in the add-on memory, a second RAM drive partitioned from the standard motherboard memory, and the rest of the standard memory was used to run dev tools and/or the application under test. Putting all of the source code into a RAM drive was necessary to make the development experience tolerable (I can't remember whether the concern was source code navigation, build times, or both... EDIT now that I think about it, it might have been the object code rather than the source code that needed to be on the RAM drive; or perhaps both).
Different times...
Only towards the end of the 1980s were hard drives inexpensive enough to become commonplace. My first 65 MB drive cost $949 (ca 1989), and that is why we were using floppies and RAM drives instead. The RAM drives did survive reboots and crashes most of the time, which helped quite a bit as you may imagine.
And in fact, fun people have gotten GEM/GEMDOS to boot and run again on Lisa emulators and real Lisas.
Computer archeology.
In a Lisa emulator running Lisa Workshop, Apple's UCSD Pascal/Clascal-based development system for the Lisa.
Technically you could potentially port Pascal and/or Object Pascal code to another platform like Delphi, but any low-level or hardware specific code would have to be rewritten.
Fortunately the binary images are available on the internet and you can run them in a Lisa emulator.
(I used to use a Lisa to write Mac programs. In the early days Macs didn't have enough RAM to run the Pascal compiler.)
Yes the original UCSD Pascal only did P-Code, however a few implementations supported AOT as well like the Constellation OS from Corvus Systems.
The nice bit is that once you implement a bytecode interpreter, everything just runs. It may be slower than native code, but no new code generators or compilers are required.
https://en.wikipedia.org/wiki/Burroughs_Large_Systems
Mostly safe systems programming language, no Assembly, all Assembly like operations are available via compiler intrisics, UNSAFE code blocks, admin clearance required for modules tainted with use of unsafe code.
All of this in 1961.
The Mac version of QuickDraw is here: https://computerhistory.org/blog/macpaint-and-quickdraw-sour...
Now that both are "open", it would be interesting to compare the two and see how they differ.
Here is one: https://lisa.sunder.net/, and on github: https://github.com/rayarachelian/lisaem
Apple was also a precursor in using safer systems languages for OS development.
Even when MPW later replaced Object Pascal, the major frameworks were based in C++, not C.
And C wasn't chosen because Apple had made an organizational bet on Pascal years earlier with the Apple II. C in the early 80's was still a niche "new vogue" kind of thing from academia[1]. Apple's roots were older, they didn't get the Unix bug until decades later.
[1] c.f. Sun Microsystems, founded by Stanford and Berkeley geeks, launching its very different 68k products concurrently.
They never got the UNIX bug really, even with the reverse acquisition from NeXT, or the way A/UX was implemented, Steve Jobs opinion on traditional UNIXes is well known in the Apple community as there some infos on his USENIX session, and NeXTSTEP brainstorming sessions.
https://www.usenix.org/blog/vault-steve-jobs-keynotes-1987-u...
Here are some references,
Chris MacAskill did a full overview of what he had to do to convince Job, it was even commented here,
https://news.ycombinator.com/item?id=17420674
Now gone from the Internet,
https://allaboutstevejobs.com/blog/2018-07-11-chris-macaskil...
However it is saved on the Wayback machine,
https://web.archive.org/web/20180628214613/https://www.cake....
=> "They said a Unix weenie was code for software engineers who hated what we were doing to Unix (the operating system we licensed)—putting a graphical user interface on it to dumb it down for grandmothers. They heckled Steve about his efforts to destroy it. His nightmare would be to speak to a crowd of them."
There is also the interview with UNIX Today!
https://www.tech-insider.org/unix/research/1991/11.html
=> "You know, take SGI's new machines-they have 8-bit color frame buffers in them, you can't even put up a bunch of beautiful color photographs without having one of them look good. The rest of them look blah because you can't do it in 8 bits. You know what I'm talking about. So most computers haven't even gotten past the stage where you could put up a bunch of color photographs, much less other types of media, or moving, dynamic media. And I think that that's an advantage that we'll continue to keep. "
=> "We're bringing Unix to the commercial market where what they care about is designing, creating and deploying mission-critical custom apps alongside those in a multitasking environment. They want to be able to use a suite of productivity apps that are compatible in the data formats with all the ones they use in the PCs. And that's where we have an offering that Motif has nothing to compete with and Sun has very little to compete with. But if you take us into the traditional scientific and engineering marketplace, we are a pretty powerful and very cost-effective Unix box. And to address X, we do run X on our product very well. There are two: one X product, soon to be two, that you can buy from third parties that run X-Window right alongside their Next Step windows, and they're quite good. So we don't have anything against X for what it was designed for, but X has not made the crossover into the commercial marketplace. "
Plenty of other similar remarks on the interview.
And some interesting NeXT footage,