I’ve put thousands of hours into both Haskell and Ocaml, so I feel like I have a pretty good understanding of how both affect my development process. > I've pe

I’ve put thousands of hours into both Haskell and Ocaml, so I feel like I have a pretty good understanding of how both affect my development process. > I've personally never found Haskell's encoding of mutability or impurity into the type system to be of any real benefit. I find it completely indispensable for large codebases, especially codebases I didn’t write. > Most of the time your impurity is coming from logging, networking, or interacting with files or a db; in which case, it's entirely obvious what's going on. Maybe you’re a genius or something, but to me (and most people) it’s not “entirely obvious what’s going on” when large codebases use impure side-effectful semantics in a way that’s not clear from the types. > Other times, you have a pure function that's implementation is unpure, which is also obvious on what's going on. Once again, it is not at all obvious. And a very large fraction of the time, that “pure function with an impure implementation” isn’t actually so pure after all, and either leaks mutable semantics or behaves badly (e.g. if used in a multithreaded way). Haskell actually does have a real solution for this in the form of the ST monad. You can write impure things and prove (using the type system) that they have pure semantics. I’m not aware of any other language offering this. > In any case, if you're programming in good FP-style all Haskell is providing is a bunch of headaches around finding the write way to make all your type annotations match up Not only are type annotations optional (and usually trivial), but you can get the compiler to write them for you interactively e.g. with holes. In any case, this is never a problem in practice for “business logic” code. I’ve only really seen this come up e.g. when writing lenses by hand (i.e. rarely). > it's kind of a annoying experience when you're just trying to get something done. The point where the cognitive overhead introduced by Haskell’s type system is worth the payoff compared to, say, Python, is about 1-200 lines in my experience. > But if you're already an experienced FP programmer, less restrictive languages are better. The only “improvement” that you’ve cited so far is that “less restrictive languages” let the programmer be architecturally lazy, which I don’t think is really an improvement. > It would be really cool if other languages had a "pure" annotation or keyword that signified the function has a pure interface. If this were preferable, then Haskell programmers could just write everything in IO and selectively factor things out into pure functions. The fact that no one does this is, I think, telling.