Haskell encourages you to think upfront about the shape of your data, because you have to design the types upfront and your constraints are checked at compile t

Haskell encourages you to think upfront about the shape of your data, because you have to design the types upfront and your constraints are checked at compile time. You can build a level of reliability and quality into your software that's hard to achieve (not impossible, but rare without great programmers) with a dynamically typed language. There's a certain imprecision that you see with mediocre programmers. They don't know how things work, and get used to fooling around with a certain squishiness that's tolerated on large object-oriented projects as long as there's one good programmer ("architect") in the batch to clean up messes. That's good enough to get by in the business world, but not if you really want to understand what you're doing and call yourself a true programmer. Haskell forces you to build from the ground up, and a nice consequence of this is that, for any type, you can inspect its pieces and get down to the bottom. Functions will have easy-to-find type signatures and, sometimes, you can get a good sense of what the function does from its signature. In fact, in Haskell, the type system can be used to make assertions about functions like "this function doesn't have any side effects" and it's trivial to do so. In the long term, Haskell's heavy use of immutable data structures confers some major performance advantages as well. Is it the right language for every purpose? No, but it's very good for many, and it's a source of great ideas that have percolated into other languages, like Clojure and Rust. Additionally, it will force you to think rigorously about your data and what is happening to it.