I believe the point is that he was fired because he spent a full day coming up with a complex solution to a trivial problem and that when he eventually did arrive at a solution, it was impossible for everyone else to understand and verify.
And the fact that it being a monoid is actually irrelevant to the solution. It is a lattice with an artificially created lower bound [1], which does induce a monoid structure via its join operation, but by thinking about it as a monoid, you abstract out the one relevant property (ordering!) that you actually care about.
[1] Assuming that there aren't any duplicate elements, in which case it technically isn't either a lattice or a monoid, unless you consider equivalence classes modulo attribute equality.
"Well", Harry said, "If you are asked to add
two employees, return the guy who is older. But
if both of them are the same age, then return the
guy who has been with the company the longest.
But if both guys have been working for us for the
same number of years, then return the guy with the
lowest salary. But if they both earn the same as
well, then just randomly pick one over the other"
I didn't think that was very hard to understand or verify.
Since my point obviously flew straight over your head: the problem is not whether we understand monoids, or even that "Harry" used monoids to solve the problem, but that he's using completely inappropriate terminology to try to explain his solution to non-technical people.
Actually, he's using completely appropriate terminology. Your mathematical education is just sufficiently limited that you don't know that. Rather than getting angry, you'd think your reaction would be to absorb the new information.
To me, your complaint is like someone saying it's inappropriate terminology to discuss time complexity in big-Oh notation, because we're programmers, not mathematicians.
I apologize for the condescension. I just think these are concepts worth knowing and that they shouldn't be looked down on so much. A lot of people are never going to learn this stuff if they dismiss it so quickly. And that holds back not just themselves but anybody they work with who does understand this stuff.
One of my favorite quotes about software development is that the hardest part of it is not being clever. The flip side, though, is that even the simplest things can seem clever to those who don't have the same breadth of knowledge. In this case, Harry had a solution that seemed clever, but really wasn't that crazy at all. None of his colleagues understood it, but they should have, because it was actually extremely simple.
What's ludicrous about Harry's account isn't his solution or his notion of "adding" employees. It's that he understood these concepts and still took a day to put it together (or that he completely glossed over the more obvious approaches). He wasn't productive at all.
Anyway, as for the terminology, it's just a common name for an associative binary operation on a set with an identity element. If you've never seen it used in this way, I agree that it can seem bizarre, but the more you think about it the more you'll realize it is in line with a generalization of the sort of addition you do on integers.
Haha, poor choice of words there. When he says "adding", he really means "apply a binary operation A • B, which returns A if ....".
The key point is: Once you can define a binary operation which is associative, and an identity element I for which A • I = A, you can consider using monoids.
Well, lets say you have 3 elements (1,2,3) with 2 being 0. So since 2 is 0, 1+2=1=2+1, 2+2=2, 3+2=3=2+3. With me so far ? So what's 1+3 ? Well, it cannot be 1 because you could then cancel the 1's and 3 would become 0, but 3 isn't 0, its 2, because we just said so. 1+3 is obviously not 3, because by the same reasoning of cancellation, you'd end up with 1 equals 0, which it ain't cause 2 is 0. So by the weird magic of Niels Abel, 1+3 must indeed be 2. Because it just can't be anything else, yeah ? You only have 3 elements to play with, and 1+3 better be one of those. Similarly, you can work it out that 1+1=3, 3+1=2 and 3+3 =1. That completes your Cayley table and you can collect your paycheck and go home to wife and kids, because with 3 elements your Cayley has 9 slots. But when you have 10,001 employees, your Cayley will have 100 million slots. Unless you have a rule to fill those slots, you won't be able to fill the Cayley. "Adding employees" is simply a rule to fill the Cayley. HTH :)
This is where scala and C++ differ. In C++, if you overload operator+ to do something, the typical response is "what does that even mean???". In scala, when you write a function called plus that returns one of its arguments, the response is "oh, of course, that's a really cool great idea."
That part is actually a good layman's explanation of how the monoid here works. But then he goes on to talk about seeding a catamorphism with an identity employee.
I was going to call your comment ridiculous but then I reread and saw that he actually did spend an entire day on it. Wow. Removing the trivial if chain you only have five lines! And it's not doing anything crazy, just a fold.
Let me put it this way: If I was the boss and Harry had spent the day learning about functional programming then okay sure whatever. But if he knew all the concepts he was using and spent the entire day just to pick one then there is a serious problem.
Exactly. If you're getting paid $60 an hour, you just wasted $500. Someone who knows SQL (or in this case Scala) could do this problem in seconds. "didn't give a rat's ass about efficiency." is a bit redundant - you're running the query once and you're getting paid by the hour.
That being said, the manager asking a math major to do an information science task seems a tad incompetent.
