> Supposedly, Apple put in a bid at the last minute with the state and won the school contract, and they had a virtual monopoly in the public schools in Minnesota.
Dale LaFrenz, who was helping administer MECC, states [1] that Apple won the bid because they filed the only compliant bid. The board was leaning towards TRS-80, but Radio Shack didn't want to bother with the state's bureaucratic bid process.
Although ACM Queue's audience is practitioners, author submissions to Queue are invite-only. CACM's new Practice section encourages submissions from outside academia.
By "pixel accurate", do you mean the user interface or the rendering? Is she able to leverage the HTML 2D Canvas API or does she have to go lower level than that?
The DoD DTIC service has a couple of reports that cover the Harbor Pilot Simulation, but I haven't found any reports written by E&S. The Computer History Museum has some records from Evans and Sutherland, but I don't think any of them cover the language.
Ross Anderson's _Security Engineering_ has a chapter on physical security. Given the poor quality of security at most art galleries, one might expect more art to be stolen. However, it seems that it is often too difficult to sell.
The author of TECO, Dan Murphy, wrote an article about its history for the IEEE Annals of the History of Computing. A PDF copy of the article is available here: https://opost.com/tenex/anhc-31-4-anec.pdf
Alas, it does not discuss the gap buffer.
The book The Craft of Text Editing claims the gap buffer technique was first used by TECO (http://www.finseth.com/craft/#c6.6), although this claim is given no support.
Dramatically, the Dartmouth experiment in teaching BASIC to all undergraduates could be profitable. Although they didn't use PDPs (they used a GE-265), it was the same time period. You have two visionaries, Kemeny and Kurtz, trying to bring a computer to every student and every faculty member. Kemeny's background allows appearances from Feynman, von Neumann, Alonzo Church, and Einstein. With the work happening in college, and being educational rather than pure research, students can be integral members of the plot and a couple working together to understand this new language and the concepts of time-sharing can lead naturally to romance.
Self-promotion: If you're interested in the MUSIC-V language (the software the catalogue uses) or the hardware, I created a video on the subject a few months ago: https://rumble.com/v153i3p-dawn-of-computer-music.html
One resource to try is SIGCIS (https://www.sigcis.org/); it's a professional group of computing historians and a number of retired practitioners.
However, historians don't tend to care about specific technology features, so I suspect you may need to treat this more as a journalistic effort than a historical effort -- emphasis on interviews, press releases, user manuals to build up a timeline.
Definition-wise, PLATO is an interesting case and is a useful test of whatever definition you choose to use. PLATO was a multi-site, multi-user education platform, but featured messaging, chat, and multi-user games. You can access a running PLATO system (https://www.irata.online/) and there are a few books that detail the development and user experience.
Akka has two types of actors: typed and untyped. Typed actors allow the compiler to type check messages, while untyped (or classic actors) perform runtime checking. This also means references to actors can be typed, so if you have multiple implementations of actors that implement the same protocol, you can substitute between the different actors and verify the protocol at compile time.
I had played with Erlang before using Scala/Akka, so untyped actors were a familiar experience. My team decided to use typed actors going forward after an Akka version update since that seems to be the strategic direction of Akka (and it does help to have the compiler complain if we try sending a message that the actor doesn't understand).
We use them both implicitly (underlying Akka Streams) and explicitly (both classic untyped actors and typed actors).
For the explicit actors, we use them to model state machines around I/O (e.g. stateful protocols). I've found that the application area is fairly niche, as many patterns of async work are clearer through queues, futures, or streams. The use of actors is insulated from the rest of the application code through interfaces that use futures or streams. But, internally, if you have to manage complex state where events can occur at any time and a mail-box like/internal queue is sufficient, then they tend to be easy to understand... once the initial ramp-up period is over.
Additionally, I've found them to require very little maintenance as developers tend to get to 100% _flow_ test coverage without a lot of difficulty.
My former employer did coding assessments for roles of that type, although the expectations were very different than for a software development role. For these kinds of roles, the coding test was on the level of fizzbuzz, is a string a palindrome, or a fairly routine scripting task.
Dale LaFrenz, who was helping administer MECC, states [1] that Apple won the bid because they filed the only compliant bid. The board was leaning towards TRS-80, but Radio Shack didn't want to bother with the state's bureaucratic bid process.
[1] https://conservancy.umn.edu/items/7f6d8e9e-0560-43e0-9050-3a...