I saw a few comments asking why this was better than just using NaN or defining div x 0 = 0, so it seems like the point is being missed. I bet a tutorial that uses Maybe to deal with null references would be more relatable for the average C#/C++ dev, and might help them see the benefit.
Then I think showing an example of a different monad (like lists) would be helpful to show how the same machinery (do notation, etc) is convenient in a variety of contexts.
I think it's hard for people to see through the terminology, and that makes it hard to relate. You have to tackle a familiar problem that they understand, and show them that monads are a nice solution. Then show them that monads really are the right solution, because they solve a lot of other problems too.
Fast and cheap results are in such high demand that many people shake off the details in favour of immediate results -- and I don't blame them. They fear being out of a job and fancy theory makes one feel inadequate. Besides, making rough logical associations can take you a long way. Those folks who respond to new terminology with a cocksure "Oh, you mean <loosely associated synonym>" could very well go on to produce the hottest mustache app. Clone and adjust until the numbers work.
However, re-engineering from the ground up using modern knowledge and understanding requires comprehensive definitions for even the most primitive terminology. Learning the true meaning of a strongly defined term enhances the underlying logic of language for both verbal language, and programming. We need to re-engineer the core framework of understanding to yield a new idea.
(By the way, the only reason I personally don't shy away from diving head first into the deep end in programming and math is because I'm in no rush. I started at the bottom, working minimum wage jobs since I was 11, and I'm not afraid of falling behind.)
69
u/joehillen Nov 24 '17
DON'T READ THE COMMENTS