4 ms·
Yes, in Haskell monadic functions are strictly speaking still pure functions, but it's the set of mutations performed by the package of runtime + your code that
by smallnamespace 10y ago
Yes, in Haskell monadic functions are strictly speaking still pure functions, but it's the set of mutations performed by the package of runtime + your code that matters.
Do-notation shows that there's a trivial mapping between monadic code and imperative code. For all practical intents and purposes, things happening in the IO Monad are not 'functional', because your mental model needs to consider the mutations they represent.
What functional programming encourages you to do (as opposed to OOP) is segregate the pure aspects of your program, under the theory that pure code is easier to write, maintain, and test.
- catnaroek 10y agoEffect segregation (a more appropriate term than “purity”) is a matter of using types, and has nothing to do with functional vs. OOP.
- smallnamespace 10y agoThe type system has a huge impact on how easily you can do effect segregation. Haskell has a type system that enforces effect segregation for you. Java doesn't. Classic OOP encourages modeling your problem as a collection of inherently stateful objects, making effect segregation more difficult. Of course, you can write in a functional style in Java, or an imperative OOP style in Haskell, but the language isn't going to help you as much.
- catnaroek 10y agoThere's no law of nature preventing you or anyone else from designing an object-oriented language that enforces effect segregation.
- smallnamespace 10y agoEven if such a programming language existed, does using both paradigms in the same program mesh very well?
- catnaroek 10y agoEffect segregation isn't a “paradigm”: it's just having the right type structure to classify programs according to their possible effects. And, sure, it's compatible with object-orientation. Why wouldn't it be? You just slap an effect annotation (explicit or inferred) onto every method signature. Pure object-orientation is a bad idea for other reasons (e.g., the binary method problem), but “inability to control effects” is totally bullshit.
- smallnamespace 10y agoOf course you can design a type system that has objects and also segregates effects. The question is whether that would be particularly helpful for structuring a program if you're trying to write explicitly in the OOP paradigm. Functional programming is a paradigm, and it emphasizes the segregation of effects. OOP traditionally does not.
- catnaroek 10y agoYou're conflating paradigms (program design philosophies) with language features (program design tools): (0) Functional programming is a paradigm that encourages expressing computation as expression evaluation, and discourages relying on more computational effects than are necessary to obtain a desired result. (1) Object-oriented programming is a paradigm that discourages directly manipulating data structures from different parts of a program. Objects expose operations that act on a data structure hidden from the rest of the program. (2) Effect segregation is a feature of some programming languages, notably Haskell and its descendants. An effect system classifies computations according to their possible effects, just like a type system classifies computations according to their possible results. You wouldn't call static typing a paradigm, right?
- smallnamespace 10y agoYou're right, effect segregation is not a paradigm per se. The fact still stands that it's closely aligned with the functional programming paradigm, and not OOP. Programing paradigms and language features are closely related: certain features make certain paradigms easier, and paradigms spur the development of particular features.