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.
If they focused on #2, #1 wouldn't be so much of an issue. Instead they hire on meaningless metrics and utter BS like what you have on your Facebook profile instead of your ability to do the job.
One of my friends who is an awesome salesman and was recommended by the person hiring for the job was not hired for the position by HR because he doesn't have his GED. The guy is super smart and doesn't have his GED because of some unfortunate circumstances regarding his classes being on the 2nd floor of the school and having broken both legs.
Now he's going and finishing up his GED in a couple weeks and will continue the search.
> doesn't have his GED because of some unfortunate circumstances regarding his classes being on the 2nd floor of the school and having broken both legs.
His school is exempt from the Americans with Disabilities Act?
"If they focused on #2, #1 wouldn't be so much of an issue."
You do not really believe this do you?
I am very sorry for your friend. Rigid interpretation of the rules can lead to some terrible decisions. However I do not think that requiring a GED increases the likelihood that the employee is going to be the cause of a lawsuit. Humans nature is an odd beast and the list of lawsuit inducing character flaws goes on for miles. If people were able to easily screen for these character flaws during the recruiting process elections would be so much easier...
I do agree with you that it's an over simplification, there is certainly a balance to be struck but I don't think the one that's currently struck is the best one.
I definitely think that there is significant room for improvement when it comes to hiring. However I think that significant progress towards #1 through preventative screening is next to impossible.
If they focused first on #2 - finding the right people for the job - where "right" meant the proper skill set for the job, that would go a long way to solving #1 - following the law on hiring practices. For if they are truly hiring on skill alone then they have already passed the biggest hurdle HR has in #1 - discriminatory hiring practices - because skill set does not look at sex or gender or race or age or any of that.
Like a guy giving career advice for engineers in Germany always says (I'm citing indirectly here, so there maybe is a certain spin to it): Nobody is blamed for following the "rules",so if HR doesn't get good people or any people at all they won't be blamed as long as they followed the rules. On the other they WILL get blamed if they hire the wrong or too troublesome people.
Maybe they think stalking prospective employees via facebook helps them somehow there...
> 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.
