3 ms·

Functional and object-oriented aren't two ends of a spectrum, they're orthogonal. Code can be both. To program in a functional style means no more or less than

Functional and object-oriented aren't two ends of a spectrum, they're orthogonal. Code can be both. To program in a functional style means no more or less than to construct your program by composing referentially transparent functions (that is, functions that have no side effects, and whose output is deterministic based on the inputs -- in other words: the mathematical notion of a function). The solutions that are marked as functional in the post fulfill this criterium, so it's correct to call them functional solutions. Whether your functions are written in method notation or not is not relevant to determining whether the program is written in a functional style.

jstimpfle 4y ago
OOP is not method notation. There's more to it (and arguably the notation part isn't required), and indeed you can't have both that and FP. OOP is the opposite of "referentially transparent".
- sideeffffect 4y ago
  Then it really depends what exactly you mean by OOP. Some people use the OOP features for modularity and structuring of the codebase, without any side effects/unmanaged mutation. Often they don't call it "OOP" then, but rather "a module system". But there isn't any theoretical distinction. For example, I do _both_ Pure Functional Programming _and_ OOP (in the "module system" way) in Scala daily. And it works very nice IMHO, I encourage everybody to give it a try. Use traits as interfaces for logical pieces of your business logic. Implement them in (case) classes which receive interfaces to other pieces of logic in their class constructor. Use a so called "Functional Effect System" like Cats Effect or ZIO to avoid raw side effects. And that's it, enjoy and profit.
  - jstimpfle 4y ago
    It's impossible to get people to agree on what OOP is exactly, but almost everyone agrees that hiding/isolating mutable state (inside objects) is an essential part of it. Just google "what are objects in programming".
    - sideeffffect 4y ago
      Totally agree that these paradigms are badly defined. See my other comment where I explain it more https://news.ycombinator.com/item?id=34217547 https://news.ycombinator.com/item?id=34217547 My point here was that all "OOP" languages (that I know) allow you, with all their "OOP feautres", to work with objects which actually don't contain any mutable state. I'll let you be the judge whether it is still "OOP", but I know from experience that it's very practical for Software Engineering.
Annatar 4y ago
[dead]
kaba0 4y ago
This is a pet peeve of mine, but referential transparency really doesn’t mean what FP people use it for. They use it as a fancy name for the same thing as pureness. Referential transparency is a syntactic thing and most languages without macros are referentially transparent — see this answer: https://stackoverflow.com/questions/210835/what-is-referential-transparency https://stackoverflow.com/questions/210835/what-is-referenti...
- ookdatnog 4y ago
  When I talk about referential transparency in the context of FP, it's honestly of no consequence to me what the history of the term in philosophy is (mind you, I still find it interesting -- I didn't know this and it was nice learning about it -- but it doesn't significantly change my understanding of the term in the context of FP). Technical terms can be overloaded, I don't think this is either surprising or problematic. Astrophysicists classify carbon as a metal; they're not wrong, it's just a peculiarity of the field that's almost always clear from context. In the context of FP, the term "referential transparency" means that variables can be replaced with their definitions, and vice versa, without changing the semantics of the program. The term coincides with pureness, but IMO it emphasizes something different. "Pureness" is a negative definition, it the property of there not being any side effects. "Referential transparency" to me indicates what you can do with that purity: it allows you to reason algebraically about your program. > most languages without macros are referentially transparent I don't think so. In most languages, you cannot syntactically replace a variable with its definition and expect the semantics of your program to remain unchanged. For instance, in Python, given the following shared prefix: state = 0 def f(): nonlocal state state += 1 return state x = f() The programs x + x and f() + f() do not yield the same result, which is what you'd expect if referential transparency holds.

jstimpfle 4y ago

OOP is not method notation. There's more to it (and arguably the notation part isn't required), and indeed you can't have both that and FP. OOP is the opposite of "referentially transparent".

sideeffffect 4y ago
Then it really depends what exactly you mean by OOP. Some people use the OOP features for modularity and structuring of the codebase, without any side effects/unmanaged mutation. Often they don't call it "OOP" then, but rather "a module system". But there isn't any theoretical distinction. For example, I do _both_ Pure Functional Programming _and_ OOP (in the "module system" way) in Scala daily. And it works very nice IMHO, I encourage everybody to give it a try. Use traits as interfaces for logical pieces of your business logic. Implement them in (case) classes which receive interfaces to other pieces of logic in their class constructor. Use a so called "Functional Effect System" like Cats Effect or ZIO to avoid raw side effects. And that's it, enjoy and profit.
- jstimpfle 4y ago
  It's impossible to get people to agree on what OOP is exactly, but almost everyone agrees that hiding/isolating mutable state (inside objects) is an essential part of it. Just google "what are objects in programming".
  - sideeffffect 4y ago
    Totally agree that these paradigms are badly defined. See my other comment where I explain it more https://news.ycombinator.com/item?id=34217547 https://news.ycombinator.com/item?id=34217547 My point here was that all "OOP" languages (that I know) allow you, with all their "OOP feautres", to work with objects which actually don't contain any mutable state. I'll let you be the judge whether it is still "OOP", but I know from experience that it's very practical for Software Engineering.

Annatar 4y ago

[dead]

kaba0 4y ago

This is a pet peeve of mine, but referential transparency really doesn’t mean what FP people use it for. They use it as a fancy name for the same thing as pureness. Referential transparency is a syntactic thing and most languages without macros are referentially transparent — see this answer: https://stackoverflow.com/questions/210835/what-is-referential-transparency https://stackoverflow.com/questions/210835/what-is-referenti...

ookdatnog 4y ago
When I talk about referential transparency in the context of FP, it's honestly of no consequence to me what the history of the term in philosophy is (mind you, I still find it interesting -- I didn't know this and it was nice learning about it -- but it doesn't significantly change my understanding of the term in the context of FP). Technical terms can be overloaded, I don't think this is either surprising or problematic. Astrophysicists classify carbon as a metal; they're not wrong, it's just a peculiarity of the field that's almost always clear from context. In the context of FP, the term "referential transparency" means that variables can be replaced with their definitions, and vice versa, without changing the semantics of the program. The term coincides with pureness, but IMO it emphasizes something different. "Pureness" is a negative definition, it the property of there not being any side effects. "Referential transparency" to me indicates what you can do with that purity: it allows you to reason algebraically about your program. > most languages without macros are referentially transparent I don't think so. In most languages, you cannot syntactically replace a variable with its definition and expect the semantics of your program to remain unchanged. For instance, in Python, given the following shared prefix: state = 0 def f(): nonlocal state state += 1 return state x = f() The programs x + x and f() + f() do not yield the same result, which is what you'd expect if referential transparency holds.