3 ms·
> But... most people who look into Haskell lose steam as soon as they realize they actually must understand functors, applicative functors, monoids, monads, and
by JadeNB 6y ago
> But... most people who look into Haskell lose steam as soon as they realize they actually must understand functors, applicative functors, monoids, monads, and (god forbid) lens-things like prisms, traversals, isos, etc. to do anything useful.
Why? Why does everyone think that you have to understand the mathematical underpinnings of Haskell to program in it, but not that you have to understand the assembler to which C compiles to program in it, or the internals of your car's engine to drive it?
Of course, in each of these cases, someone who has that knowledge will probably have some power available that will be denied to those who don't; but that doesn't mean you can't use it. The great thing about this mathematical knowledge is that it can be filled in on demand, and, unlike a lot of knowledge that you don't even know you don't have, when you realise you want to understand what these objects are, you've already got the terminology to look it up in research papers.
- marcosdumay 6y agoThose abstractions are like the steering wheels and pedals for Haskell, not like the car's engine.
- JadeNB 6y ago> Those abstractions are like the steering wheels and pedals for Haskell, not like the car's engine. Agreed, but you also don't have to understand anything about the mechanics of the steering wheels and pedals to drive a car, only about when to use which. Monads and other scary-sounding terminology are the same. People really do know these patterns from other programming languages, and attaching a name might be scary, but it doesn't make them intrinsically harder. On the contrary, it makes it easier for people who want to peer into the theoretical internals to do so—though no one has to do it.