Wednesday, September 07, 2016

The Cult of "Diversity" and the Tale of a Conference Meltdown

   I don't really know what's going on with this, but I offer it up anyway (via /r/socialjusticeinaction).  The stuff about trying to figure out whether or not the keynote speaker committed politically incorrect "microaggressions" is bizarre in the extreme. One of the accusations was based on the fact that he once gave a talk titled "Monads and Gonads." Sounds really stupid, since there's no way in hell there's any reason to talk about those two things together other than that they rhyme and 'gonads' is a somewhat funny word. But damn, the witch-hunt that ensued...totally psycho. Rather than pointing out that it's fairly dumb junior-high humor, he was summarily booted from the converence. And don't miss the reference to "people of diversity"...
   This stuff is insane. People are allowing a lunatic political cult to control their lives. The combination of stupidity and cowardice is nauseating.

3 Comments:

Blogger The Mystic said...

So, regarding he subject matter here, his title "Monads and Gonads" is, I can confirm for you, in fact, stupid. He reinforces the stupidity a few times in the talk saying things like "If you have the huevos..." then you can do "x" where "x" is something he thinks he's wittily figured out despite the failure to do so on behalf of others.

Frankly, the talk isn't the great, and I'm not the only one who noticed that around the IT world. I don't do a lot of functional programming because, frankly, it's not very practical in most of the cases I encounter (e.g. automating system administration activities). However, functional programming has its advantages in big, complex applications where coordinating simultaneous application behavior and preventing failures is important.

The most important thing to recognize, however, in my opinion, is that neither functional nor imperative programming styles are often outright incapable of doing what the other can do. This is really largely a debate about easing the design process and preventing unexpected application behavior.

That said, the general debate about functional versus, say, imperative programming is about what you'd expect from the IT world; nerds on the functional side like to act as though they are simply rationally superior because their code behavior is easier to predict and understand "mathematically" whereas imperative code often relies on what are known as "side effects" (modifications to the state of the application, such as changes to a parameter that is used by later operations) which, functional programming dogmatists allege, cause "mathematically nonsensical" results.

This guy giving the talk (incorrectly) uses these same terms. There's nothing mathematically nonsensical about referring to variables that have been changed in the course of the application's operation, right? That does, in fact, make sense. What he means to say is that he doesn't like it when he calls a function in his code and, because of a change made elsewhere to a variable lying elsewhere in that code, his function breaks.

One can see how this is reasonably annoying, but really, the idea that functional programming is rationally superior because it prevents that from occurring breaks down when you see just how difficult it is to write functions that don't ever refer to application state. For instance, in his talk, he talks about removing any and all references to the "date" function in JavaScript because that function is "mathematically nonsensical" (sigh) since it generates a different value each time it is invoked in an identical manner.

Functional programmers do not like functions which, when called with the same parameters, generate different values. They do not like this, generally, for the reason I explain above.

But, then you run into the problem of having applications which don't even know wtf time it is. You have even worse problems with applications that can't read from disks (what if that disk content changes!?).

So, the creation of monads is conducted to provide functions in functional programming with the ability to perform operations which typically rely on application state information (shunned by functional programmers). It's totally uncomplicated, and is basically just chaining mathematical operations together to provide dynamic output for a function.

10:19 AM  
Blogger The Mystic said...

I don't know what value that explanation has to you, but I thought I'd do some brief IT ranting because this guy is basically acting like a stereotypical, arrogant, angry IT nerd. The short of this rant is: SJWs are taking a fairly legitimate target to task for the wrong reasons, as they are wont to do.

And it's all over a stupid debate between angry nerds eager to express their dominance over one another. The truth is that functional and imperative programming have their virtues, they are more or less convenient given the use case, and that's all there is to it.

EOF.

10:19 AM  
Blogger Winston Smith said...

Thanks, I'm actually glad to find out this stuff.

10:55 PM  

Post a Comment

Subscribe to Post Comments [Atom]

<< Home