3 ms·
Oh, gotta be super snappy on a Mac mini G4! Yeah, when a coworker and I showed my wife the first OS X preview, she was alarmed at how long it took to shut down
by JKCalhoun 11mo ago
Oh, gotta be super snappy on a Mac mini G4!
Yeah, when a coworker and I showed my wife the first OS X preview, she was alarmed at how long it took to shut down (I mean System 7 shut down like you just kicked the cord out). "You'll have to find something else to like about it," was my coworker's response.
And to be sure, there was/is a lot to like about OS X.
But, probably because of the lack of a kernel, etc., System 7 sits somewhere in that nether/middle region on our personal computer journey. It's rich library of functions (the Toolbox) set it apart from machines before it that might have instead had a handful of ASSM routines you could "CALL" in BASIC to switch display modes, clear the screen, etc. But, as Amiga owners often reminded the Mac community in the day, no "true" preemptive multitasking…
I should say too, regarding programming, these days your ability to write safe, threaded code is probably the highest virtue to strive for, hardest to perfect — at least for me (so hard to wrap my head around). It seems to separate the hacks (in the negative sense) from the programming gods. I think wistfully of those simpler times when managing memory well, handling error returned from the system API gracefully were the only hurdles.
"You can’t simply add a lock here, because this function can be called while the lock is already held. Taking the same lock again would cause a deadlock…"
"The way you've implemented semaphores can still allow a potential race condition. No, I have no idea how we can test that scenario, with the unit tests it may still only happen once in a million runs—or only on certain hardware…"
(Since I have retired I confess my memory of those hair-pulling days are getting fuzzier—thankfully.)
- spockz 11mo agoThere are plenty of ways to multi threaded code these days. From actors to coroutines on the programmatic interface level to using green threads directly in go or Java. There is very little reason to resort using locks, mutexes, or semaphores outside of frameworks designed to make multi threading easier or very specific high performance code. (Where in the latter case it could be argued that multi threaded probably adds unreasonable latency and context switching.)
- mietek 11mo agoWhoever is downvoting you for speaking the truth should go stand in a corner. Or try maining BeOS for a while, to experience first-hand what happens when application programmers are forced to use threads and locks.
- mietek 11mo agoThreads and locks are fundamentally the wrong abstraction for most scenarios. This is explained in complementary ways in two of the finest technical books ever written, Joe Armstrong's "Programming Erlang" and Simon Marlow's "Parallel and Concurrent Programming in Haskell". I highly recommend both. Thank you for many fond memories of playing Glider and Pararena.