jwstarr

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...

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.

For this article, I deliberately kept the scope limited because it was getting rather long.

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.

Programming topics with an emphasis on computing history

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.

https://doc.akka.io/docs/akka/current/typed/from-classic.htm...

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).

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.