7 ms·

What's the difference between writing OO code that depends on internal state and writing a pure function that expects an argument that is a data structure of a

What's the difference between writing OO code that depends on internal state and writing a pure function that expects an argument that is a data structure of a specific type (and thus has internal data that could be different)? Is the pure function no longer pure if the argument is a data structure thats complex and the values within the data structure dictate the outcome of the the function? Or is it a pure function because if you pass the same data structure with the same internal values the function will return the same value?

yarg 6y ago
It's the difference between c++ and c. He's not suggesting pure functional programming - and beyond a certain point the simplicity associated with functional programming will be completely negated by the complexity of the arguments. From my understanding of what he said, I doubt that he'd advocate for pure functional in circumstances of significant necessary complexity.
garethrowlands 6y ago
Passing a big structure to a function doesn't make that function impure. But passing a structure containing objects with impure methods does make the called function impure. Passing a big structure to a function is a bad idea in any paradigm because it's a big dependency. Instead, you should write the function to operate on the data that it needs and pass just that when you call it.
brundolf 6y ago
Purity is a question of mutability, nothing more. If the function mutates its arguments (or its closure, or its global environment), it is impure. Any useful program will of course need to do these things at some point, but there's a lot of logic that just goes from A -> B (or A, B, C -> D, or whatever), that doesn't need to concern itself with these things, and should be insulated from them. There's nothing inherently impure about taking large data structures as arguments, though it does make it trickier to enforce immutability in most languages (compared to primitive values). It's worth noting that it's entirely possible to write "pure methods". Unfortunately most languages don't really let you a) have mutable structures, and b) write enforced-immutable methods on them. Rust is the only one I know of: a method can take a &self instead of a &mut self, which prevents it from mutating self (recursively, which requires knowledge about ownership unless your language is 100% immutable like Haskell or Clojure, which is why this feature is so rare). What I tend to do in other languages like JavaScript, C#, or Python is to use property-getters as a convention that strongly suggests purity; unfortunately that's about the best you can do. In multi-paradigm languages the decision on whether to make something a pure "getter" method or a standalone function is mostly one of aesthetics. Standalone functions give you a bit more flexibility in use, but sometimes the foo.prop syntax is more readable.
- steveklabnik 6y ago
  Interior mutability allows you to mutate behind &self.
  - brundolf 6y ago
    Yeah true, though I think of that as a bit of a trap-door along the lines of unsafe { }. There's still a reasonable guarantee under "normal" circumstances.
carapace 6y ago
OOP is merely a way to arrange your code. There's no magic sauce, it's just topological distortion without deep semantic significance. In other words, there isn't really a difference. Maybe the code is easier to understand in the OOP style, maybe not, but that's in one's head.

yarg 6y ago

It's the difference between c++ and c. He's not suggesting pure functional programming - and beyond a certain point the simplicity associated with functional programming will be completely negated by the complexity of the arguments. From my understanding of what he said, I doubt that he'd advocate for pure functional in circumstances of significant necessary complexity.

garethrowlands 6y ago

Passing a big structure to a function doesn't make that function impure. But passing a structure containing objects with impure methods does make the called function impure. Passing a big structure to a function is a bad idea in any paradigm because it's a big dependency. Instead, you should write the function to operate on the data that it needs and pass just that when you call it.

brundolf 6y ago

Purity is a question of mutability, nothing more. If the function mutates its arguments (or its closure, or its global environment), it is impure. Any useful program will of course need to do these things at some point, but there's a lot of logic that just goes from A -> B (or A, B, C -> D, or whatever), that doesn't need to concern itself with these things, and should be insulated from them. There's nothing inherently impure about taking large data structures as arguments, though it does make it trickier to enforce immutability in most languages (compared to primitive values). It's worth noting that it's entirely possible to write "pure methods". Unfortunately most languages don't really let you a) have mutable structures, and b) write enforced-immutable methods on them. Rust is the only one I know of: a method can take a &self instead of a &mut self, which prevents it from mutating self (recursively, which requires knowledge about ownership unless your language is 100% immutable like Haskell or Clojure, which is why this feature is so rare). What I tend to do in other languages like JavaScript, C#, or Python is to use property-getters as a convention that strongly suggests purity; unfortunately that's about the best you can do. In multi-paradigm languages the decision on whether to make something a pure "getter" method or a standalone function is mostly one of aesthetics. Standalone functions give you a bit more flexibility in use, but sometimes the foo.prop syntax is more readable.

steveklabnik 6y ago
Interior mutability allows you to mutate behind &self.
- brundolf 6y ago
  Yeah true, though I think of that as a bit of a trap-door along the lines of unsafe { }. There's still a reasonable guarantee under "normal" circumstances.

carapace 6y ago

OOP is merely a way to arrange your code. There's no magic sauce, it's just topological distortion without deep semantic significance. In other words, there isn't really a difference. Maybe the code is easier to understand in the OOP style, maybe not, but that's in one's head.