Soft spoken people selfhosting down-to-earth videos without asking me to like, subscribe and send my left b*llock to Facegoogle is everything I want from the 2020's. Bonus points for old Macs.
There's a ton of ways it could be done. Looks like a camera pointed right at a monitor, and a webcam recording him. You can have various display sources and picture in picture looking stuff using an app called OBS ( https://obsproject.com/ ) which also allows you to stream everything, if you feel compelled.
He talks in the intro video also linked there that he's trying to get a better set up to directly connect into the screen but for now has to deal with looking through the screen on his phone recording the Mac.
With the many examples I see of very skilled programmers using retro tools for their personal projects, I wonder if it goes the other way too -- are there examples of highly capable programmers choosing bleeding-edge tools for personal projects? What does that look like?
> I see of very skilled programmers using retro tools for their personal projects
Interesting observation, and something I hadn't really though about. For my own stuff I increasingly pick older technologies, not really retro, like jcs does here. Personally I think I've just grown tired of the modern "stuff", it's way to complex for me to find it relaxing to write a few lines of code for the fun of it. I wonder if that's true in a boarder sense for others working in IT.
I've watched a few of these videos, where jcs just hacks away on his old Mac and I'm extremely impressed with what's actually possible on these old machine. I do think the compile times would drive me insane, but others might see it as a nice little break.
My coworkers think I'm insane, but I do my side projects in C because I find it so much more relaxing and satisfying than what I do at work (Angular and C#). They can't understand why I find C relaxing because they find it terrifying. I just find it so much simpler to work with functions, structs and pointers rather than abstraction chains ten layers deep.
Granted, I'm using it on homemade game engines, which are very amenable to the simple type of code C allows you to write. I wouldn't want to write an HTTP server in it. But for what I build, I find using C to be the equivalent of woodworking, compared to the Ikea furniture I put together at work.
The PC of that era was such an unpredictable mess of components, you couldn't even assume a specific sound card was present. VGA 256-color modes didn't even have square pixels unless you went Mode-X which was rather annoying to program for.
I think there are far better retro hardware choices to relive writing native programs for. Stuff you'll actually be able to ensure will run successfully with full graphics and sound capabilities on every instance of the thing. C64, Amiga, etc. There's a reason the x86 PC severely lagged behind in the demoscene for ages, it was just miserable hardware to support.
I recently became involved in the P2 community, the new propeller microcontroller from parallax (which just hit rev C). There's some very talented people there doing interesting things with it.
Some of them have been programming it before it was even proper silicon, when it was being developed via FPGA. Lots of really in-the-weeds discussions on machine code and cycle timings and such. Worth diving in if you like seeing "how the sausage is made."
Offers will vary, but, if impromptu answers carry any weight, then off the top of my Sunday afternoon head, this is the first reference that percolates to the surface.
I had a computer programming class in high school, we got to pick our compiler out of a box of old software. For some reason it's what I chose, and spent the first day installing it from floppy disks.
I am pretty sure the machine I used was a Macintosh LC III, already obsolete by the time I got my hands on it. But the other computers were Pentium 100's running Windows and I had a PC at home, so that wouldn't have been any fun.
I later found out it became Symantec C, but I really only used Codewarrior for the rest of my Mac classic endeavors.
It was a great product and was the first widely available c compiler for the Macintosh. I purchased it (LightspeedC) for my Macintosh II for $100 in something like 1987. I was coming from Xerox office systems division to grad school and felt it was as good as our Xerox IDEs.
Languages like Apple Pascal had too much of a banana Republic dictatorship underpinning (due to Nicklaus Wirth/European fascism) and didn't allow much freedom of expression. It's why Apple had to add so many extensions just to make Pascal usable and so many people moved to Think C. With a 3-second turnaround compiler and a decent IDE it was a great system.
Is this how commercial Mac software of the era was generally written? (I have no Apple experience) Or is this a more hobbyist/consumer-oriented IDE/editor workflow?
It's painful to watch, coming from a 486 PC era background using Borland Turbo C/C++.
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.
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:
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...)
