The #1 job of HR is to make sure they don't get their asses sued or fined for violating hiring and employment law. The #2 job is to help hire and retain good people. What raganwald's fictional letter shows is that inspecting private Facebook posts means that both job functions are compromised far more than helped. It's the kind of argument that gets the attention of people who may not be moved by ethical arguments.
> There can be no limitations of any kind in terms of expressing to the machine, precisely how the machine should behave.
I hear what you're saying but you're overselling C here. Straight up ANSI C has a lot of limitations in telling the machine what to do. Even the various proprietary extensions have limitations right up until you stop writing anything that looks a little bit like C, e.g. you start using "asm" style intrinsics that let you do assembly inline.
Really old? E comes from the mid to late 90's. In Tiobe's current top 20 only C# and Go are newer than that.
While E seems to be deadish, many of its core ideas around object capability security (ocaps) live on. Others have mention Caja, an attempt to bolt ocaps onto JS, but see also Gilad Bracha's current experiments with a Smalltalk variant called Newspeak which is entirely built around ocaps.
Another interesting take on ocaps is Joe-E, which is basically a verifier that allows a subset of Java. If some Java source passes Joe-E then that source is capability secure.
Another interesting aspect of E, vats, is conceptually not too different from actor style concurrency as exemplified by Erlang, except that where one Erlang actor(process) conceptually is one "object," an E vat may hold many objects. Note: Erlang predates E by quite a bit, and the actor model predates Erlang by even more; I just thought it worth mentioning as one way to think about vats.
In fact, Erlang is itself very nearly an ocaps system. Nearly because actors can mostly only talk to other actors after they receive (or spawn) a PID, thus untrusted actors can be limited in capability by not sending them dangerous PIDs. But not quite because some dangerous primitives (like IO) are globally available. It would be straightforward to produce an Erlang-ish actor based language that was ocaps secure.
> Haskell and Scala are closest in that they're strongly, statically typed with Hindley-Milner type inference
> Haskell has the most sophisticated type system--by far, I think it's fair to say
HM is a type system first, and that means is a logic system. HM is a logic that is deliberately kept relatively weak in order to allow full inference. Scala is not HM and never has been - it's much, much more sophisticated and so Scala uses a form of type inference not based on HM. Haskell '98 is HM plus a tiny bit (and yes that tiny bit does mean that the occasional type annotation is required). GHC Haskell is HM plus a ton more and so there are a lot more GHC Haskell programs that need some type annotation. The people behind GHC Haskell have done a good job of carefully adding type system features that don't totally break the model, though, so you rarely have to annotate much unless you love playing in advanced type land.
I would hesitate before saying GHC Haskell is more sophisticated "by far". It's not at all obvious that that is so. I'd want a type theorist to spend some time with the two core logics to determine which one subsumes what parts of the other before making that call.