Comment by pengaru | Hacker News Reader

Comment by pengaru | Hacker News Reader

Parent Full thread

Just the editor features, compiler errors/feedback, and general pace of development/iteration.

I want to assume that the actual professional developers or programmers working at Apple creating the system probably weren't using this kind of workflow. It's just so awfully slow and serialized, the whole single compilation error shown at a time in a GUI popup for every build strikes me as the IDE going far out of its way to not overwhelm the programmer with walls of scary error text at great expense to iteration speed. Especially considering how long the builds take. That would make sense if the tooling was intended for hobbyists/beginners, trying to make programming more approachable than efficient.

Ron Gilbert has described developing Maniac Mansion for the C64 using UNIX editors and cross-toolchains run on DEC machines, never actually writing any software using a C64. I wonder if the video is more representative of what end-users were suffering through to write small programs, and not what the professionals or Apple devs experienced.

Think C was definitely used to make commercial software. Apple developers probably used "Macintosh Programmer's Workshop", which is more like a command line. Whether it gave more feedback I can't really say. But again, this is not comparable to an early 90's 486 system at all. This is an 8 MHz machine that maxes out at 4MB RAM.

The big constraint on IDEs in the first few years of Macs, including this system, is the screen size. 512x342 pixels is not a lot. In the early 90's people most developers would have had something more like a desktop Mac with more real estate, so the editors evolved fairly quickly. But the first version of Photoshop was written on this exact machine (Mac Plus) according to Wikipedia.

I've never heard of anyone cross-compiling end-user software from Unix, except for pre-1984 system bring-up. In the first year or so, I think you needed a Lisa to code for the Mac, but it became self-hosting quite quickly. Mac applications until OS X need a bunch of Mac-specific stuff that lives in the file's so-called "resource fork", and the final artifact (application file) can therefore only exist on the Macintosh file system.

Think Pascal — superior to Think C’s IDE by all accounts — was also used to ship commercial Mac software. It would be interesting to see a video like this done with Think Pascal.

By circa 1990, it became clear that C was the future of Mac app development, though. IIRC, one of the big selling points of CodeWarrior when it arrived was that it had a Pascal compiler that would compile to native PowerPC code, so existing apps didn’t need to be rewritten completely in C.

Which apparently had brilliant error messages:

https://mipmip.org/tidbits/compiler-errors.html

"a typedef name was a complete surprise to me at this point in your program"

That brings back memories! Loved MPW C.

Keep in mind that the Mac Plus CPU was something like an 8 MHz 68000. I don’t think a 486 was ever clocked that low?

Apple used MPW internally for Mac development by ≈1986, as others have noted. MPW was a Unix-like environment. However, the MPW toolchain was much slower to compile and link.

In any case, by the 486 era, a serious developer would have wanted to run a 68030-based Mac at minimum, which would have been a similar experience to this video, but much faster and often on a larger screen.

MPW was certainly Unix-inspired, but its multitasking was seriously deficient compared to a real Unix. Its runtime environment couldn't run more than one binary executable ("tool") at a time — not even using `system()` — so MPW's Make couldn't actually run anything, but merely printed out the commands. Only the user and MPW Shell scripts could execute other programs.

I wrote about this at length in part two of this article on MacRelix:

https://www.metamage.com/text/relix/origins.html

It was a deliberate design choice for Lightspeed C (the original name of THINK C) to not perform error recovery in the parser, and thus to stop compilation on the first syntax error. This made the compiler both smaller (important when running on a machine with 512K RAM) and faster (since the logic needed to implement error recovery simply didn't exist).

Early Macintosh development (before Apple's Macintosh Programmer's Workshop) was done on a Lisa running a version of the UCSD Pascal environment. It was a big deal when Lightspeed C and its competitors (in both Pascal and C) made it feasible to develop software directly on a Mac, though of course there were tradeoffs due to limitations of the early Mac hardware. (Now, with the recent release of Swift Playgrounds 4, which allows apps to be developed and submitted to the App Store on an iPad, we've come full circle...)

I have never understood the decision to abandon the name "Lightspeed C". The same folks also missed the opportunity to ship "Blaze Pascal". :-)

Reply on news.ycombinator.com