7 ms·

I think the best reason to study FP is to get out of the OOP mindset. But ideally in the real world you don't go crazy with either. Objects are excellent for

I think the best reason to study FP is to get out of the OOP mindset. But ideally in the real world you don't go crazy with either. Objects are excellent for data but OOP is a mess for control flow. Immutability is great but everything-is-recursion is not. And so on. When performance comes up all of this goes out of the window, maybe. But I'm talking about good defaults for correct, readable programs.

jrvarela56 4y ago
| Objects are excellent for data Check out DOP https://blog.klipse.tech/dop/2022/06/22/principles-of-dop.html https://blog.klipse.tech/dop/2022/06/22/principles-of-dop.ht... and Rich Hikey's critique of OOP (~'objects are custom languages on top of data'; they force you to learn specific semantics to manipulate plain data structures and make it tough to reuse your code).
- vkou 4y ago
  The semantics of objects are pretty straightforward, but the assurances that they provide on top of your data is their main value add in this context. Yes, things like protobufs, or equivalents thereof provide you with a list of auto-generated low-level assurances, but there are often bits of non-trivial business logic about data modification/reading that cannot be easily expressed outside of a object implementation in a Turing-complete language. They also clearly express a concept of, and when used correctly, boundaries for data ownership, which for non-ephemeral data can be important.
- dkarl 4y ago
  > Objects are excellent for data Objects are great for modeling data as long as you still think of it as data, and you can write good data processing programs using OO language constructs. OOP as an approach to programming gets it backwards, though. OOP encourages you to think of the objects as primary and the data representing them (on the wire, in a datastore) as a secondary, inferior manifestation. This is the opposite of true. The software's value is created by its handling of data on the wire, reading data from other systems and writing data to other systems. OOP objects provide no value except by reading and writing data. If you start believing that the objects provide the value and the data exists to support the objects, as OOP encourages, then you start to suffer from all kinds of delusions.
  - lostcolony 4y ago
    Once you start thinking that way, you start wondering why Objects, rather than (from Java) records, or (from most every other language) structs/tuples. That is, why bundle functions with the data and encapsulate it as a new type that ties them together? It invites the very thing you're saying not to do; if you want to think of it as just data...then make it just data. Nouns only; no verbs. Even if you have a verb as data, treat it as a noun (i.e., a higher order function). It's all translatable; you can break an object into functions and data, and create an object bundling functions and data, but, as you say, it's about how you think...and objects do not encourage you to think about the underlying data, but about the abstraction. And abstractions are leaky, don't translate well into new domains, and are much harder to communicate (both at an API level and between humans) than data.
- jcelerier 4y ago
  > (~'objects are custom languages on top of data'; how is that a bad thing - that's literally the point of the activity of programming, creating domain-specific sublanguages to manipulate data in a way that is readable by domain experts of this specific data
  - jrvarela56 4y ago
    The argument is that this default forces you into creating DSLs for basic data manipulation (it's all [] and {} in the end). You end up with 'custom' logic with custom naming that increases the overhead of using your codebase. That's a long way of saying your code is less reusable. In DOP/FP land, you create functions to manipulate basic data types and your domain-specific knowledge ends up encoded as basic data types (say you want validations on a model, you'd encode those as a {} and create functions to validate vanilla []/{}).
oxff 4y ago
> Objects are excellent for data They are not. If your data is in objects, you have already demoted data as a first class member of your language (ie. Java)
bitL 4y ago
Immutability is slow, so if you are somebody squeezing the maximum FLOPS out of a CPU, you might want to stay away (sorry, 1.3x slowdown in your best case is not acceptable, and "leave it out to the compiler" is not a valid argument). It's like with project management - the iron triangle of speed, quality, price, pick two. With each programming paradigm you pick a different set of attributes that might or might not be the best for what you need and they enable you on one thing and constrain you on another thing.
- duped 4y ago
  Immutability is an API not an implementation. Immutable code often outperforms mutable, it depends on the use case.
  - bitL 4y ago
    There is often some "redefinition of terms" going on with dedicated functional programming folks in order to assert their claims as you just demonstrated. There was some benchmark where mutable Java was shown to be around 30x faster than immutable OCaml and the discussion went to something like "no, no, that's a wrong comparison, compare it with immutable vs mutable OCaml, that is then just 2x slower! And the next compiler revision will remove it! 100% sure about it!" etc. Why can't other modes of thinking coexist with your view? FP is OK, so is OOP, so is imperative, low-level machine code, "loop programs" (see Dennis Ritchie dissertation), logic programming etc. I like them all but hate it when somebody tries to push me one way telling me all other ways are wrong.
    - mrkeen 4y ago
      Awesome, I'd love to read it!
    - freedomben 4y ago
      > Why can't other modes of thinking coexist with your view? FP is OK, so is OOP, so is imperative, low-level machine code, "loop programs" (see Dennis Ritchie dissertation), logic programming etc. I like them all but hate it when somebody tries to push me one way telling me all other ways are wrong. Why do you think GP is saying or doing that? I think you've put a lot of words into their mouth that aren't there, and then got yourself worked up about it, enough to accuse them of ignorance and small-mindedness (at best). I see absolutely nothing in their comment that even weighs in favor of FP, let alone saying other modes of thinking can't coexist. For all we know GP is a rabid OOP fan but sees the value in immutability (which FP certainly does not have a monopoly on).
cpursley 4y ago
Just don't make the mistake of studying FP first... I can't seem to wrap my head around OOP. There's too many concepts in OOP. In FP it's just data and functions for transforming that data.
- bitL 4y ago
  Can you explain monads to a 5-year old? Can you explain objects?
  - mdcds 4y ago
    I heard following explanation of monads somewhere online: "monads allow us to write imperative code in the functional setting. e.i. chain computations". But that explanation wouldn't make sense to a 5-year-old
  - solomonb 4y ago
    I don't think that is a fair comparison. Monad is a typeclass so it would be like explaining some specific Java Interface (and all the context for Interfaces) to a 5 year old. The Haskell (since you brought up Monads) equivalent to explaining Objects would be like explaining Records or Sum types, which would be very easy to explain and don't require talking about inheritance like Objects would.
  - freedomben 4y ago
    I don't know if you're being serious or not, but you can learn a ton of FP without having to understand monads. Also asking to explain "objects" is too ambiguous. an "object" in json is very simple. OOP on the other hand involves a mountain of different concepts, design patterns, best practices, etc. I would guess GP is referring to that stuff.
    - LudwigNagasena 4y ago
      You can learn a ton of OOP without having to dive into a mountain of different concepts too.
jstx1 4y ago
I mean there's other options too. Go for example is mostly imperative(?) - it doesn't encourage heavy OOP or pure functional programming. Rust has more functional features but it's still neither purely functional nor heavily OOP. Julia isn't OO at all but it doesn't emphasize FP either. Those are just three languages that are all (1) modern, (2) generally well received, (3) neither OO nor heavily functional and (4) still very different from each other.
guelo 4y ago
One of the bigger advantages of OOP that I rarely see discussed is the natural namespacing that you get. In other paradigms you end up polluting the global namespace more easily, harming autocompletion and discoverability.
- pharmakom 4y ago
  Most FP languages have modules so not sure where this idea comes from.
rr888 4y ago
> OOP is a mess for control flow. I used to think this until my new project where everything is functional, everything is reactive, everything is a lambda. Each function is very simple but the whole thing is impossible to trace.
- pllbnk 4y ago
  I have seen this before, but I think the problem is the code, not the paradigm. If you bend your mind a little and think of stateless functions as a chain of (OOP) method calls, function arguments as class instances and namespaces those functions as classes themselves, then there is little reason to think that it should be impossible to trace, given equal familiarity with the tooling.
- freedomben 4y ago
  I've seen functional code like that as well, and it's truly awful. If all FP was that way I'd avoid touching it with a 1,000 foot pole. Most of the time though it's a developer who writes bad code no matter which language/paradigm they're in, but FP does give them tools to make it even more unreadable
pdpi 4y ago
Funnily enough, I disagree — I find that the overwhelming majority of problems with OOP come precisely from trying to use it with data. The only thing it’s good for is precisely control flow at the macro level.
- eatonphil 4y ago
  We'll just have to agree to stay away from each other's code. :)
kalekold 4y ago
> I think the best reason to study FP is to get out of the OOP mindset. > Objects are excellent for data but OOP is a mess for control flow. http://nomad.uk.net/articles/developers-who-hate-on-oop-don't-know-how-to-use-it.html http://nomad.uk.net/articles/developers-who-hate-on-oop-don'...
- cardanome 4y ago
  > If OOP is causing complexity in your program it's either the wrong tool for the job or you are using it poorly. No. The whole point about OOP is that it increases complexity. It uses higher levels of abstraction to organize the program. Sure you might end up with a program that is possibly easier to understand and maintain and maybe even shorter but always more complex than the strict procedural equivalent. Simply cause you increased the levels of abstractions one needs to go through to understand the program. That is, of course, not OOP specific. Introducing any form of abstraction introduces extra complexity. If you use the abstraction right, the problem becomes easier to handle but you always pay a cost. Though the have a point with > If you have used OOP well and the program still turns out more complicated than if it was written in a procedural style then you may as well use procedural code. The art of software engineering is finding a level of abstraction that is appropriate for the complexity of the problem that is to be solved. Don't over-engineer but also don't under-engineer your software.
kephasp 4y ago
> Immutability is great but everything-is-recursion is not. Why oppose a real pattern and a imaginary one?

jrvarela56 4y ago

| Objects are excellent for data Check out DOP https://blog.klipse.tech/dop/2022/06/22/principles-of-dop.html https://blog.klipse.tech/dop/2022/06/22/principles-of-dop.ht... and Rich Hikey's critique of OOP (~'objects are custom languages on top of data'; they force you to learn specific semantics to manipulate plain data structures and make it tough to reuse your code).

vkou 4y ago
The semantics of objects are pretty straightforward, but the assurances that they provide on top of your data is their main value add in this context. Yes, things like protobufs, or equivalents thereof provide you with a list of auto-generated low-level assurances, but there are often bits of non-trivial business logic about data modification/reading that cannot be easily expressed outside of a object implementation in a Turing-complete language. They also clearly express a concept of, and when used correctly, boundaries for data ownership, which for non-ephemeral data can be important.
dkarl 4y ago
> Objects are excellent for data Objects are great for modeling data as long as you still think of it as data, and you can write good data processing programs using OO language constructs. OOP as an approach to programming gets it backwards, though. OOP encourages you to think of the objects as primary and the data representing them (on the wire, in a datastore) as a secondary, inferior manifestation. This is the opposite of true. The software's value is created by its handling of data on the wire, reading data from other systems and writing data to other systems. OOP objects provide no value except by reading and writing data. If you start believing that the objects provide the value and the data exists to support the objects, as OOP encourages, then you start to suffer from all kinds of delusions.
- lostcolony 4y ago
  Once you start thinking that way, you start wondering why Objects, rather than (from Java) records, or (from most every other language) structs/tuples. That is, why bundle functions with the data and encapsulate it as a new type that ties them together? It invites the very thing you're saying not to do; if you want to think of it as just data...then make it just data. Nouns only; no verbs. Even if you have a verb as data, treat it as a noun (i.e., a higher order function). It's all translatable; you can break an object into functions and data, and create an object bundling functions and data, but, as you say, it's about how you think...and objects do not encourage you to think about the underlying data, but about the abstraction. And abstractions are leaky, don't translate well into new domains, and are much harder to communicate (both at an API level and between humans) than data.
jcelerier 4y ago
> (~'objects are custom languages on top of data'; how is that a bad thing - that's literally the point of the activity of programming, creating domain-specific sublanguages to manipulate data in a way that is readable by domain experts of this specific data
- jrvarela56 4y ago
  The argument is that this default forces you into creating DSLs for basic data manipulation (it's all [] and {} in the end). You end up with 'custom' logic with custom naming that increases the overhead of using your codebase. That's a long way of saying your code is less reusable. In DOP/FP land, you create functions to manipulate basic data types and your domain-specific knowledge ends up encoded as basic data types (say you want validations on a model, you'd encode those as a {} and create functions to validate vanilla []/{}).

oxff 4y ago

> Objects are excellent for data They are not. If your data is in objects, you have already demoted data as a first class member of your language (ie. Java)

bitL 4y ago

Immutability is slow, so if you are somebody squeezing the maximum FLOPS out of a CPU, you might want to stay away (sorry, 1.3x slowdown in your best case is not acceptable, and "leave it out to the compiler" is not a valid argument). It's like with project management - the iron triangle of speed, quality, price, pick two. With each programming paradigm you pick a different set of attributes that might or might not be the best for what you need and they enable you on one thing and constrain you on another thing.

duped 4y ago
Immutability is an API not an implementation. Immutable code often outperforms mutable, it depends on the use case.
- bitL 4y ago
  There is often some "redefinition of terms" going on with dedicated functional programming folks in order to assert their claims as you just demonstrated. There was some benchmark where mutable Java was shown to be around 30x faster than immutable OCaml and the discussion went to something like "no, no, that's a wrong comparison, compare it with immutable vs mutable OCaml, that is then just 2x slower! And the next compiler revision will remove it! 100% sure about it!" etc. Why can't other modes of thinking coexist with your view? FP is OK, so is OOP, so is imperative, low-level machine code, "loop programs" (see Dennis Ritchie dissertation), logic programming etc. I like them all but hate it when somebody tries to push me one way telling me all other ways are wrong.
  - mrkeen 4y ago
    Awesome, I'd love to read it!
  - freedomben 4y ago
    > Why can't other modes of thinking coexist with your view? FP is OK, so is OOP, so is imperative, low-level machine code, "loop programs" (see Dennis Ritchie dissertation), logic programming etc. I like them all but hate it when somebody tries to push me one way telling me all other ways are wrong. Why do you think GP is saying or doing that? I think you've put a lot of words into their mouth that aren't there, and then got yourself worked up about it, enough to accuse them of ignorance and small-mindedness (at best). I see absolutely nothing in their comment that even weighs in favor of FP, let alone saying other modes of thinking can't coexist. For all we know GP is a rabid OOP fan but sees the value in immutability (which FP certainly does not have a monopoly on).

cpursley 4y ago

Just don't make the mistake of studying FP first... I can't seem to wrap my head around OOP. There's too many concepts in OOP. In FP it's just data and functions for transforming that data.

bitL 4y ago
Can you explain monads to a 5-year old? Can you explain objects?
- mdcds 4y ago
  I heard following explanation of monads somewhere online: "monads allow us to write imperative code in the functional setting. e.i. chain computations". But that explanation wouldn't make sense to a 5-year-old
- solomonb 4y ago
  I don't think that is a fair comparison. Monad is a typeclass so it would be like explaining some specific Java Interface (and all the context for Interfaces) to a 5 year old. The Haskell (since you brought up Monads) equivalent to explaining Objects would be like explaining Records or Sum types, which would be very easy to explain and don't require talking about inheritance like Objects would.
- freedomben 4y ago
  I don't know if you're being serious or not, but you can learn a ton of FP without having to understand monads. Also asking to explain "objects" is too ambiguous. an "object" in json is very simple. OOP on the other hand involves a mountain of different concepts, design patterns, best practices, etc. I would guess GP is referring to that stuff.
  - LudwigNagasena 4y ago
    You can learn a ton of OOP without having to dive into a mountain of different concepts too.

jstx1 4y ago

I mean there's other options too. Go for example is mostly imperative(?) - it doesn't encourage heavy OOP or pure functional programming. Rust has more functional features but it's still neither purely functional nor heavily OOP. Julia isn't OO at all but it doesn't emphasize FP either. Those are just three languages that are all (1) modern, (2) generally well received, (3) neither OO nor heavily functional and (4) still very different from each other.

guelo 4y ago

One of the bigger advantages of OOP that I rarely see discussed is the natural namespacing that you get. In other paradigms you end up polluting the global namespace more easily, harming autocompletion and discoverability.

pharmakom 4y ago
Most FP languages have modules so not sure where this idea comes from.

rr888 4y ago

> OOP is a mess for control flow. I used to think this until my new project where everything is functional, everything is reactive, everything is a lambda. Each function is very simple but the whole thing is impossible to trace.

pllbnk 4y ago
I have seen this before, but I think the problem is the code, not the paradigm. If you bend your mind a little and think of stateless functions as a chain of (OOP) method calls, function arguments as class instances and namespaces those functions as classes themselves, then there is little reason to think that it should be impossible to trace, given equal familiarity with the tooling.
freedomben 4y ago
I've seen functional code like that as well, and it's truly awful. If all FP was that way I'd avoid touching it with a 1,000 foot pole. Most of the time though it's a developer who writes bad code no matter which language/paradigm they're in, but FP does give them tools to make it even more unreadable

pdpi 4y ago

Funnily enough, I disagree — I find that the overwhelming majority of problems with OOP come precisely from trying to use it with data. The only thing it’s good for is precisely control flow at the macro level.

eatonphil 4y ago
We'll just have to agree to stay away from each other's code. :)

kalekold 4y ago

> I think the best reason to study FP is to get out of the OOP mindset. > Objects are excellent for data but OOP is a mess for control flow. http://nomad.uk.net/articles/developers-who-hate-on-oop-don't-know-how-to-use-it.html http://nomad.uk.net/articles/developers-who-hate-on-oop-don'...

cardanome 4y ago
> If OOP is causing complexity in your program it's either the wrong tool for the job or you are using it poorly. No. The whole point about OOP is that it increases complexity. It uses higher levels of abstraction to organize the program. Sure you might end up with a program that is possibly easier to understand and maintain and maybe even shorter but always more complex than the strict procedural equivalent. Simply cause you increased the levels of abstractions one needs to go through to understand the program. That is, of course, not OOP specific. Introducing any form of abstraction introduces extra complexity. If you use the abstraction right, the problem becomes easier to handle but you always pay a cost. Though the have a point with > If you have used OOP well and the program still turns out more complicated than if it was written in a procedural style then you may as well use procedural code. The art of software engineering is finding a level of abstraction that is appropriate for the complexity of the problem that is to be solved. Don't over-engineer but also don't under-engineer your software.

kephasp 4y ago

> Immutability is great but everything-is-recursion is not. Why oppose a real pattern and a imaginary one?