[foldr]

I second this. I think Haskell is a research programming language, and in a way I feel lucky that I first learned it way back in 2002, long before anyone seriously thought of using it for professional software development.

Haskell 98 is a pretty awesome programming language. It's not the best fit for every domain, but you can write concise readable code in it. The type system is just sophisticated enough to let you model your domain, but not so sophisticated that it becomes a distraction.

A lot of modern Haskell code has the unfortunate property that the types of the functions are harder to understand than their implementations. Type inference is much more valuable when it's the other way round. You know that [a] -> [a] is the right type for the 'reverse' function, so if you get a type error, you're sure that you made an error in your implementation. Conversely, many modern Haskell libraries give rise to extremely complex types, even when you're doing something mundane like making an SQL query. When you get a type error, it's then anyone's guess whether you misannotated a type somewhere or made an error in your implementation.

I personally feel that partial types systems are the way forward. Type the 80-90% of your code that's easy to type without a fancy type system. Dynamically type the rest and write some tests for it. Fancy types make you feel smart (and in all seriousness are a fascinating and important research topic), but their practical utility is limited IMO.

[ImprobableTruth]

I agree that gradual type systems are great, but man, I feel like the expressiveness of e.g. Typescript is fantastic even for 'normal' programming.

Something like fully typed forms (so that e.g. <Input type='text' path='address.street' /> only works if your form data has a { address : {street : string} } + branded types for more custom data fields) is absolutely magical and makes working with lots of highly complex forms a breeze. Tests just don't compare.