[tech, soc just] On sexism, racism, polymorphism and virtual machines
As some of you may have heard, there was this Ruby (a programming language) conference, BritRuby, and it was cancelled because... well, actually, nobody knows really why it was cancelled, but it sure looks from the statement issued by the organizers like it was cancelled in a fit of pique after a couple of people (both white males, themselves, bless 'em) pointed out on twitter that this conference's speaker lineup was 100% white men. The rubysphere then blew up, in all the predictable ways.
The following bit of brilliance was emitted in the explosion. It comes from Avdi Grimm, at his blog Virtuous Code and is an excerpt from his post On BritRuby I am, or rather was, a speaker at British Ruby Conference 2013. If you were planning to attend, or if you follow many Rubyists on Twitter, you probably know that the conference has been cancelled. As one of the invited speakers, and as someone who briefly took part in the Twitter kerfuffle that eventually lead to its cancellation, I want to say a few things about the situation, and about what other conference organizers might learn from it.
But first, I want to talk about polymorphism and virtual machines.
In a dynamic OO language like ruby, when you send a message such as speaker.speak, you don’t have to know or care what kind of object “speaker” is. So long as it responds to #speak, it just works. To paraphrase the old song: Red or yellow, black or white, they are all ducks in the VM’s sight. All objects satisfying the right interface are equal.
Of course, things are never quite as simple as they appear. A VM that performs run-time optimization will eventually notice if speaker is an instance of the same class, 90% of the time. Say, for instance, the WhiteGuy class. In that case, the VM will optimize for the common case of calling WhiteGuy#speak. It might cache the code for WhiteGuy#speak at the speaker.speak call site. It might even arrange to have the CPU pre-load that code and start executing it in parallel with the check for whether speaker is actually a WhiteGuy. 90% of the time, it won’t have to throw out the result of the partially-completed computation, so it’s worth it. Of course, even the developer of the code will probably never notice that this optimization is going on, unless they deliberately examine the live VM with the help of diagnostic tools.
We might say that the VM develops an implicit bias for WhiteGuy objects over time. Human brains are susceptible to implicit bias as well. And while the diagnostic tools aren’t as well-developed, they do exist.
[...] One problem with this optimization is that it's out of date. [....]
The following bit of brilliance was emitted in the explosion. It comes from Avdi Grimm, at his blog Virtuous Code and is an excerpt from his post On BritRuby I am, or rather was, a speaker at British Ruby Conference 2013. If you were planning to attend, or if you follow many Rubyists on Twitter, you probably know that the conference has been cancelled. As one of the invited speakers, and as someone who briefly took part in the Twitter kerfuffle that eventually lead to its cancellation, I want to say a few things about the situation, and about what other conference organizers might learn from it.
But first, I want to talk about polymorphism and virtual machines.
In a dynamic OO language like ruby, when you send a message such as speaker.speak, you don’t have to know or care what kind of object “speaker” is. So long as it responds to #speak, it just works. To paraphrase the old song: Red or yellow, black or white, they are all ducks in the VM’s sight. All objects satisfying the right interface are equal.
Of course, things are never quite as simple as they appear. A VM that performs run-time optimization will eventually notice if speaker is an instance of the same class, 90% of the time. Say, for instance, the WhiteGuy class. In that case, the VM will optimize for the common case of calling WhiteGuy#speak. It might cache the code for WhiteGuy#speak at the speaker.speak call site. It might even arrange to have the CPU pre-load that code and start executing it in parallel with the check for whether speaker is actually a WhiteGuy. 90% of the time, it won’t have to throw out the result of the partially-completed computation, so it’s worth it. Of course, even the developer of the code will probably never notice that this optimization is going on, unless they deliberately examine the live VM with the help of diagnostic tools.
We might say that the VM develops an implicit bias for WhiteGuy objects over time. Human brains are susceptible to implicit bias as well. And while the diagnostic tools aren’t as well-developed, they do exist.
[...] One problem with this optimization is that it's out of date. [....]