3 ms·

What source code files you happen to put declarations and definitions in has nothing to do with functional purity. Think of it this way: An array append funct

What source code files you happen to put declarations and definitions in has nothing to do with functional purity. Think of it this way: An array append function which adds an element to the input array is not purely functional. An array append function which returns a new array with the new element appended is purely functional. The same function applied to the same input will always return the same value, and won't cause that to break for any other functions. Of course, this makes things such as IO tricky and yo ideally want to minimize and isolate the places where this happens on a lower level. Haskell solves this with monads, which we have seen is a big hurdle for many developers. I personally think Idris's effect system[0] is a lot easier to deal with, but would be curious to see other approaches. [0]: http://docs.idris-lang.org/en/latest/effects/index.html http://docs.idris-lang.org/en/latest/effects/index.html

cryptica 7y ago
>> An array append function which returns a new array with the new element appended is purely functional. >> The same function applied to the same input will always return the same value, and won't cause that to break for any other functions. I think this is the essence of why a lot of developers use functional programming but I think that in this case functional programming is not a solution to the real problem which is an architectural problem. If the relationship between different components in your system is clear and hierarchichal, you should never need to keep the same data/array in two places. You can come up with simple abstractions so that you only ever have one source of truth for each kind of state. That means you can read it anywhere but only write to it in one place. I think that functional programming cannot solve this root problem, you will just end up with different symptoms. For example, instead of mutating a single array in unexpected ways, in FP, if you have multiple sources of truth, you might end up with multiple conflicting copies of the same data. Same root problem and it's just as difficult to identify and debug as in OOP, just different symptom.

cryptica 7y ago

>> An array append function which returns a new array with the new element appended is purely functional. >> The same function applied to the same input will always return the same value, and won't cause that to break for any other functions. I think this is the essence of why a lot of developers use functional programming but I think that in this case functional programming is not a solution to the real problem which is an architectural problem. If the relationship between different components in your system is clear and hierarchichal, you should never need to keep the same data/array in two places. You can come up with simple abstractions so that you only ever have one source of truth for each kind of state. That means you can read it anywhere but only write to it in one place. I think that functional programming cannot solve this root problem, you will just end up with different symptoms. For example, instead of mutating a single array in unexpected ways, in FP, if you have multiple sources of truth, you might end up with multiple conflicting copies of the same data. Same root problem and it's just as difficult to identify and debug as in OOP, just different symptom.