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.)
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.)
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.
Think about it. 30 years from now, Windows OS source code will feel like that, we'll download its zip in seconds and browse it. It'll feel miniscule. Linux too. Everything will feel so small after the AI Revolution of 2049, which will increase our code writing speed orders of magnitude, will write instant code for a device driver for a hardware by probing its input/output models based on your expectations from the device, even if the device doesn't support it, such as using a printer to measure ambient temperature by observing fluctuations in the ink capacity sensor. It'll figure that out on its own. Printers will have ceased to exist by then, of course, because of the great AI war against HP due to their cruel experiments on printers over decades to make them fail at unexpected times in order to maximize profits.
We'll never be able to comprehend how the humans of 2022 were able to do anything with computers at all.
The future is dark
Assuming Apple would have adopted a Roman hexadecimal system for their numbering scheme.
The next generation will look at me with their AI tools and wonder how I built anything with primitive internet searches and StackOverflow.
My usual monthly bill for dial-up access to the three services (mostly CompuServe) was around $300, close to $800/month in today's dollars.
Charles listed me in the acknowledgements for the first edition of Programming Windows as "the indefatigable Michael Geary." That was kind of fun.
internet access is a massive distraction, instead you used documentation that was pretty good. It meant you needed a bit more of a base in place before you started--you had to buy a copy of the developer SDK/tookkit for whatever you were working on--but you had so many fewer distractions after that.
(not that it played a large role, but inter network communications between companies was pretty standard during the time that Microsoft was writing Windows, starting with microsoft!ucbvax!decvax etc. type addressing, and soon .com/.edu was added)
This all means that you often got stuck on a problem for days, only to eventually 'invent' a clever solution that's also been invented by thousands of other programmers ;)
In addition to those TechNet CDs, we established some rapport via CompuServe or phone with specific Microsoft support people. Occasionally they would fix a bug we reported and send us rebuilt libs, or send us an internal Microsoft tool to try. That was a different era, obviously with a much smaller population of developers with less exposure to those who would support them.
I have forgotten how to do a lot of stuff I knew how to do back then... but does it really matter, when I can look it up in a few minutes? I'm not sure.
Before that it was the Borland C++ manual set.
> publish benchmarking results about the Apple Software or your use of it
Damn, there goes my Apple Lisa vs Amiga comparison video! I was going to get so many YouTube views! Meh, maybe I'll make it anyway. So sue me!
> the Apple Software may not be exported or re-exported (a) into any U.S. embargoed countries
I'm sure keeping Iran from getting this valuable software from 1983, which runs on a completely dead CPU architecture that Linux doesn't even support anymore, is very important!
(But seriously, as a license geek, and not a lawyer, the wording of this license is really interesting. It seems to have completely different disclaimers than you usually see in open-source licenses...)
Hey, take that back! 68k/ColdFire ISA is actually pretty well supported these days by compilers. Better than it was a few years ago. There are 68k backends for both GCC (again) and LLVM (maybe not as active).
It's probably the best supported "retro" architecture at this point.
Rest of your points are valid though ;-)
The 68k is hardly dead; Linux support isn't a viability indicator of an architecture. It was dropped from Linux because there are no 68k systems powerful enough to run it and it's modern userspace, so it was a waste of development and debugging time. But the architecture is thriving in embedded and custom device spaces and fully supported by GCC and LLVM.
Probably took 5 years just to get through all the lawyers at Apple, and this is what we ended up with.
Remember, the default answer to almost any question poised to a lawyer is "No."
:-(
My uncle took receipt of a Lisa in the 80s but didn't have much use for it, so he gave it to our family. Lisa was my first computer. I used to use LisaDraw as a very primitive city builder: rectangles with circles to represent cars; boxes for buildings. I'd use the arrow keys to move things around. I can remember seeing the Lisa redraw pixels, top to bottom, as I pressed the keys.
By the time I moved on to my first Mac (Performa 638CD with SoftFPU installed), I learned more about Apple and understood the Lisa to be a failure in the market, but it will always hold a special place. I assume this is Pascal and I can't really follow it very well, but it's quite a special thing to read the inline comments written by engineers who paved the way for me and inspired me.
Writing this many, many years later on a 16" MacBook Pro with M1 Max.
Oooh you just reminded me that I used to do the same a decade later on my dad's Macintosh. Can kids have fun with super basic toys on computers these days? Or are they too used to seeing more advanced things on screens to even be interested?
I still think the best gift you can give to a young child is a big cardboard box.
Looks like Turbo/Borland Pascal but I'm not sure that it existed in that time or/and was ported to 6502.
Apple’s Lisa Pascal developments began from scratch for Apple when it licensed in 1981 a Motorola 68000 native code Pascal compiler from Silicon Valley Software in California. This compiler was based upon the older P4 compiler from Niklaus Wirth of ETH in Switzerland and consisted of two general passes. Pass 1 produced I-Code, a low-level representation of the high-level Pascal constructs. Pass 2, the code generator, converted the I-Codes to optimized 68000 object code. Apple even considered early in the Lisa’s development using a custom Apple processor which would execute P-Code directly, but the expense of developing such a chip was too much for Apple’s accountants and this project was dropped.
Turbo Pascal came much later, and Borland would adopt UCSD units in Turbo Pascal 4, and Apple's Object Pascal on Turbo Pascal 5.5, then its OOP capabilities grew from there based on what was happening on C++, influenced by Borland's work on their C++ compilers.
Turbo Pascal didn't exist yet. The leading Pascal of the early-1980s era was UCSD Pascal [1] but it used a cross-platform bytecode approach which wasn't very fast and wouldn't have been suitable for the Lisa.
I suspect Apple built their own 68k Pascal compiler? But I'm sure someone on HN knows the actual facts.
In early 1982, the Lisa software team was trying to buckle down for the big push to ship the software within the next six months. Some of the managers decided that it would be a good idea to track the progress of each individual engineer in terms of the amount of code that they wrote from week to week. They devised a form that each engineer was required to submit every Friday, which included a field for the number of lines of code that were written that week.
Bill Atkinson, the author of Quickdraw and the main user interface designer, who was by far the most important Lisa implementer, thought that lines of code was a silly measure of software productivity. He thought his goal was to write as small and fast a program as possible, and that the lines of code metric only encouraged writing sloppy, bloated, broken code.
He recently was working on optimizing Quickdraw's region calculation machinery, and had completely rewritten the region engine using a simpler, more general algorithm which, after some tweaking, made region operations almost six times faster. As a by-product, the rewrite also saved around 2,000 lines of code.
He was just putting the finishing touches on the optimization when it was time to fill out the management form for the first time. When he got to the lines of code part, he thought about it for a second, and then wrote in the number: -2000.
I'm not sure how the managers reacted to that, but I do know that after a couple more weeks, they stopped asking Bill to fill out the form, and he gladly complied.
https://www.folklore.org/StoryView.py?project=Macintosh&stor...
The Parc didn't do its graphics that way at all, and Atkinson (and Apple) got a lot of patents on his region code. That code is also why the Mac's graphics performance was so much better than everyone else's (until discrete GPUs came out). It's that fast.
Apple's software guys were really good back in the day. Their software-based floating point stuff (SANE) was faster and more accurate than Intel's hardware FP stuff for a long time.
<https://news.ycombinator.com/item?id=2285569>
Submitted several times to HN since then. Most recently:
>{ RoundRect Routines }
>FTFA: a majority of personal computer users interacted with their machines via command-line interfaces...in which users had to type arcane commands to control their computers.
ARCANE!?!? you say!?!?!
https://en.wiktionary.org/wiki/arcane
arcane:
1. Understood by only a few.
2. (by extension) Obscure, mysterious.
3. Requiring secret or mysterious knowledge to understand.
4. Extremely old (e.g. interpretation or knowledge), and possibly irrelevant.
The serious point I'm trying to make is, young and up-and-coming programmers who are learning textual programming languages (more or less the definition of a computer programmer at present) should not be scared off from learning command lines. They're very powerful, and not that obscure or hard. Unix had/has a feature that can be confusing, which is the command line is first processed according to the rules of the shell, and then it is reprocessed according to the rules of the app you are invoking, making command lines be a subtle mix of several languages at a time (by analogy, a bit like html+javascript+css). You need to learn how this works, despite being confusing it is the innovation necessary for unlocking the power of shells.
Also, many people in those days never consulted the docs and just memorized commands without understanding them so they probably felt arcane.
your point about those who copypasta-ed command incantations is reasonable, but they did get them from people who knew how to write them and conditions (like situational pathnames or dangerousness of side effects) are sufficiently variable to limit the scope of this style's applicability
Curiously, it doesn't credit authors in the headers as I've seen in sources from the same period.
I also wonder how much of the core OS code made it into Macintosh System 1.
Also, nice styling here: http://revontulet.org/2023/01/19/lisadesk.png. They didn't have to do ASCII art in the comments but they did!
That site blocks my ISP.
Wasn't the original Lisa source code famously lost by Apple?
I seem to recall hearing or reading that Apple apparently lost the original GM source code for core Lisa software, because the backup tapes were corrupted or unreadable; fortunately a contractor had taken home and retained a profile drive with an alpha version of the source code, but the final/GM version was lost to the sands of time.
(As always, backups are only good if you can actually read them and restore from them.)
However, if the CHM source code is in fact 3.1 GM (as it seems like it might be?) perhaps this story is inaccurate, or perhaps it was recovered somehow. It would be interesting to see if the source code is complete and an entire working Lisa environment could be built from it.
It would be interesting to hear from someone with firsthand knowledge.
In recent decades different languages have introduced interesting patterns, interesting notations. Swift seems to have adopted about all of them.
I have been told by teammates that I don't write "Swifty" Swift code, instead writing something more like an "Objective-Swift" style.
Oh, and they say that like it's a bad thing.
Depending on what they mean by this, I agree that it can be a bad thing.
Years ago, in the days when Swift was still pretty green (around 2.x or 3.x) I knew someone who liked to try to write "Objective-C in Swift" — that is, they'd try to ignore the type system and optionality entirely, with lots of forced casts, forced unwraps, shipping data around in [String:Any] dictionaries, etc… constant fighting with the compiler that made SourceKit very unhappy and crashy and the app we were working on more crash-prone than it would've been had it been written in Objective-C.
On the other hand, if it's just a more verbose style that favors clarity and avoids e.g. unnamed closure arguments and breaks more out into well named variables and functions, I don't see anything wrong with that at all and in fact have been leaning further in that direction as time goes on.
(Yes I know you can lie but my point is they are asking for this)
The Mac originated as a cut-down Lisa.
It's not some ironic competitor. It was a later machine, built on the back of lessons learned from the Lisa's failure.
A lot of desirable stuff was lost: multitasking, app development in a high-level language (and a type-safe one at that!), expansion slots etc.
And less desirable stuff: the template-oriented template and creator paradigm. Radical, innovative, but confusing. The Mac went with a much simpler, more conventional, documents-and-apps model, in the traditional CP/M and DOS style.
Like it would be a perfect fit for a bland old boho styled apartment.
Oh those grandpas. We evolved. Now everything is black: computer cases, power supplies, motherboards, keykoards, mouses, RAM modules, even the GUI^w UX. /s
I still remember the layout ca. 1979-83 like it was yesterday - on the right side when you walked in was a separate room with some kind of P-Code machine which was the "business mini". The Lisa and later the Mac were set up on a table on the right, and the Apple][ in the back. In the center were the Kaypro, and some other CP/M machines, and the Commodore Pets (the OG chicket keyboard version and the green-screen one w/the real keyboard) (incl. some IEE-488? accessories), the Sol II, and then the gfx show-offs (making my TRS-80 jealous), the CompuColor II and Exidy Sorcerer. The other wall had the printers - the Anderson-Jacobson daisywheel printer, an adapter w/solenoids to turn your Selectric typewriter into a printer, a few 9-pin matrix printes like the IDS Paper Tiger (right before the Epson MX-80 took over)
Good times. Sigh...
I would die to see the original sources of Norton Commander 3.0 written by John Socha. They say, he used "an ortodox" (back in the day) approach of C and assembler mashup, which not many programmers used that time, and "real programmers" always wrote in assembler :-)
Had today's date bookmarked, and was browsing around your twitter etc earlier looking to see if this had happened.
Can't wait to look inside.
Released under APPLE ACADEMIC LICENSE AGREEMENT
Lisa OS Software version 3.1
grep -ri fuck . ./Lisa_Source/Lisa_Toolkit/TK Sources 4/LIBUT-UUNIVTEXT2.TEXT.unix.txt: HALT; {Die rather than fuck up} grep: ./Lisa_Source/Lisa_Toolkit/TK Sources 4/LIBUT-UUNIVTEXT2.TEXT: binary file matches grep: ./Lisa_Source/Lisa_Toolkit/TK3/TK-ALERT.OBJ: binary file matches ./Lisa_Source/LISA_OS/APIN/APIN-OFFICE.TEXT.unix.txt: fucked up if he bails out or doesn't ever select a disk} ./Lisa_Source/LISA_OS/LIBS/LIBDB/libdb-SCANCODE.TEXT.unix.txt: valid position, thus we don't fuck with pscantable^[scanid]^ until ./Lisa_Source/LISA_OS/LIBS/LIBDB/libdb-SCANCODE.TEXT.unix.txt: valid position, thus we don't fuck with pscantable^[scanid]^ until ./Lisa_Source/LISA_OS/LIBS/LIBDB/libdb-SCANCODE.TEXT.unix.txt: valid position, thus we don't fuck with pscantable^[scanid]^ until ./Lisa_Source/LISA_OS/LIBS/LIBDB/libdb-LMSCAN.TEXT.unix.txt: badCheckPoint = 3424; { check point info is fucked }{##} ./Lisa_Source/LISA_OS/Linkmaps and Misc. 3.0/TKALERT.TEXT.unix.txt: if not fcheckhz(hz,i) then writeln('heap big fuckup 1'); ./Lisa_Source/LISA_OS/Linkmaps and Misc. 3.0/TKALERT.TEXT.unix.txt: if not fcheckhz(hz,i) then writeln('heap big fuckup 2');
"You may not and you agree not to: ...publish benchmarking results about the Apple Software or your use of it"
Perhaps 40 years later Apple is still embarassed about the performance of the Lisa?
So, maybe somebody here can emulate a Lisa and run Geekbench :)
