Hacker News new | past | comments | ask | show | jobs | submit login

This doesn’t help you understand why you should do functional programming.

It just helps you understand the nature of what functional programming actually is. Too many people think it’s just immutability, anonymous functions, map, reduce and filter.

Understanding why you should do functional programming is orthogonal to understanding what it is.

Even if I tell you functional programming is more modular and referentially transparent and lacks state. None of these things truly register until you have done both imperative programming and Haskell programming for a non trivial amount of time.

Also error handling is orthogonal to functional programming. Yes I know it’s clever how Haskell does it but it’s independent to functional programming… and even so.. explaining maybe monads or any other error monad just makes things less understandable.






My usual statement on monads is "like any abstraction, it makes sense when you need it"

If you write a lot of go code and think "this error management (!= nil anybody?) is a drag, there has to be a better way! The truth is: go largely looks like how cpp is written at Google, EXCEPT in Google cpp you get to use macros like RETURN_IF_ERROR which handles the ubiquitous StatusOr class.

Is this StatusOr a monad? I'm failing to recall what the monad functions look like internally, but I suspect it's trivial to make it one (I mean, it probably is! And if it's not it would be trivial to make it one)

Do you need to understand monads to see why they're useful here? I don't think so! And so even if you don't know how to build the microwave, you know how to use it.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: