Before Haskell I felt like I was cargo-culting advice - "use private fields with getters & setters", "everything should have an interface", "avoid static methods", "avoid 'new' and use factories instead". I figured eventually one of these days these things would click.
With Haskell came new principles which had immediately obvious value - "is your function well-defined over all possible inputs?" and "does it always produce the same output given the same input?".
I later 'got' that first set of principles, but I mostly disagree with them.
My day job has always involved looking at exceptions and logs, figuring out "how something went wrong", and then trying to fix it. Guess which set of principles helps me make software that typically "just works".
It takes an idea[0] and runs with it as far as it goes. The best part is that when they got to obstacles like handling of IO, they didn't take the easy route and compromise the vision in favor of a pragmatic solution. Instead they went into unexplored territory and came back with monads, which proved an extremely fertile ground for more than IO.
Obviously, Haskell being an academic language helps here, since novel ideas lead to papers and boring old ideas don't.
[0]: That is statically typed lazy functional programming.
pure functional. no mutations. (state and i/o handled with inscrutable magic).
basically every code base out there could use more functional effort - simple data structures and simple functions that operate on these to return a brand new structure.
With Haskell came new principles which had immediately obvious value - "is your function well-defined over all possible inputs?" and "does it always produce the same output given the same input?".
I later 'got' that first set of principles, but I mostly disagree with them.
My day job has always involved looking at exceptions and logs, figuring out "how something went wrong", and then trying to fix it. Guess which set of principles helps me make software that typically "just works".