5 ms·
no program can be purely functional Pure functional programming means building up a machine. This machine will eventually be executed by the runtime system (at
by seagreen 10y ago
no program can be purely functional
Pure functional programming means building up a machine. This machine will eventually be executed by the runtime system (at which point IO will happen) but from the programmer's perspective a program can still be purely functional.
By this I mean that a function that takes an Int and outputs an Int will have type `Int -> Int`, and a function that takes an Int, does logging, and outputs an Int will have type `Int -> IO Int`. Both are purely functional -- they're pure transformations from an Int to some other thing. For the first function that other thing is another Int, for the second that other thing is an action that can be performed by the machine which will return an Int.
So from the perspective that matters to us a developers programs can be purely functional.
(This becomes even more useful with something like PureScript's granular effect tracking https://github.com/purescript/purescript/wiki/Differences-from-Haskell#io-vs-eff https://github.com/purescript/purescript/wiki/Differences-fr...)
- smallnamespace 10y agoYes, 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.