3 ms·

I'm sorry, I don't see the problem. You can encapsulate away the state behind an opaque type so that it can be only accessed by functions that you have defined.

I'm sorry, I don't see the problem. You can encapsulate away the state behind an opaque type so that it can be only accessed by functions that you have defined. Whether this is a good choice is up to the programmer, but it's common practice in haskell to use domain-specific types wherever it makes sense. For UIs and such, in addition to monads there are more powerful abstractions, but at no point is it necessary to leak information to the client. The common UI toolkits tend to have some impedance mismatch with FP because they've been designed with OOP in mind, but this is not the fault of FP. Of course, in FP it often doesn't even make sense to encapsulate everything. Why hide useful data when it's guaranteed that any user will not be able to misuse it? Haskell provides tools for abstraction that are IMO vastly superior to anything I've seen in an OOP language. If anything, you're more likely to have leaky abstractions and failed encapsulation in Java or C++ compared to Haskell, simply because of mutable state, closed classes, and limited expressiveness of the type system.

seanmcdirmid 14y ago
Ah, they just didn't design their UI libraries right? I hate this argument, because its easily proven true (someone just has to design a "right" library) and impossible to prove false (the "right" library could exist, it just hasn't been built yet). The problem with Haskell, which isn't a problem in an impure FP like Clojure, is that you can't define objects at all (in the sense that objects completely encapsulate state). Yes, you can do a lot of nice combinator tricks, but these only work well for well understood problems, and so FP practitioners spend most of their time trying to understand problems very well so that they are amenable to their elegant abstractions. Whereas if I just use an OOP language (or a pragmatic FP language), I just solve the problem in a hacky way without needing to completely understand its essence (which, for me at least, only comes after I've solved the problem N times in N different ways!). Closed classes suck, but not all OOP languages restrict you to closed classes. Scala does very well here, and traits are wonderfully expressive.

seanmcdirmid 14y ago

Ah, they just didn't design their UI libraries right? I hate this argument, because its easily proven true (someone just has to design a "right" library) and impossible to prove false (the "right" library could exist, it just hasn't been built yet). The problem with Haskell, which isn't a problem in an impure FP like Clojure, is that you can't define objects at all (in the sense that objects completely encapsulate state). Yes, you can do a lot of nice combinator tricks, but these only work well for well understood problems, and so FP practitioners spend most of their time trying to understand problems very well so that they are amenable to their elegant abstractions. Whereas if I just use an OOP language (or a pragmatic FP language), I just solve the problem in a hacky way without needing to completely understand its essence (which, for me at least, only comes after I've solved the problem N times in N different ways!). Closed classes suck, but not all OOP languages restrict you to closed classes. Scala does very well here, and traits are wonderfully expressive.