3 ms·

>> Functional programming that introduces or models state requires more abstraction, and then complexity. > I'm pretty sure I've said exactly that. Good thing

by epgui 3y ago

>> Functional programming that introduces or models state requires more abstraction, and then complexity. > I'm pretty sure I've said exactly that. Good thing we agree on it. I strongly disagree with the complexity part of this statement. Yes, FP is in many ways "more abstract", but so is natural human thought. More abstraction is not the same as more complexity (except when the abstractions are inappropriate in a given situation), does not lead to more complexity, and the FP approach to state is objectively simpler in most* real-life scenarios. [*] as always, exceptions do apply.

c_crank 3y ago
I don't believe in zero cost abstractions. All abstractions have a cost of being understood and implemented. x = x + 1 is simpler than world = worldupdate(world(increment(x)).
- epgui 3y ago
  Abstractions exist in our brains. They are costly when they are unfamiliar (requiring learning) or when they are inappropriate (the product of incompetence and causing pain for everyone). Sometimes they are exactly as costly as they should be, reflecting the inherent and essential complexity of the problem, which is ideal. Inappropriate can mean either “too little” or “not enough”… but more accurately, it just means “the wrong abstraction”. Making everything a class, or treating everything like a Turing tape, is also creating mountains of almost-certainly inappropriate abstractions, in most (but not all) cases. This is very handwavy, because i’m speaking in very general terms. But for a single, narrow, non-general, concrete example, just look at the ORM impedence mismatch problem with OOP languages. AFAIK, after 40-some years it’s still unsolved. I don’t believe FP suffers from this specific problem (again, just to give a concrete and non-handwavy example), because FP is very analogous to relational programming (functions are a special case of relations). This shouldn’t be so controversial and should be very intuitive to anyone who spends a bit of time thinking about it. A function is fundamentally a simpler building block than a class. It’s more atomic.
  - c_crank 3y ago
    I don't believe an ORM is a zero cost abstraction either. Or most of OOP. The cost of implementing everything as a function is when one has to contend with the fundamental machine architecture not dealing with everything as a function. This often leads to one of the highest cost abstractions out there, the Monad.
- epgui 3y ago
  There is no reason to use state at all here, let alone the state of the world. In FP you just do: x + 1 Moreover, this example is totally meaningless, because it doesn't feature anything that is different about FP and the imperative style at all.
  - c_crank 3y ago
    y = x + 1 is not dealing with state. Supposing there was a desire to have x = x + 1, the simple way of doing this is x = x + 1, and the complicated way is to do world = Increment(x, world).

by epgui 3y ago

c_crank 3y ago

I don't believe in zero cost abstractions. All abstractions have a cost of being understood and implemented. x = x + 1 is simpler than world = worldupdate(world(increment(x)).

epgui 3y ago
Abstractions exist in our brains. They are costly when they are unfamiliar (requiring learning) or when they are inappropriate (the product of incompetence and causing pain for everyone). Sometimes they are exactly as costly as they should be, reflecting the inherent and essential complexity of the problem, which is ideal. Inappropriate can mean either “too little” or “not enough”… but more accurately, it just means “the wrong abstraction”. Making everything a class, or treating everything like a Turing tape, is also creating mountains of almost-certainly inappropriate abstractions, in most (but not all) cases. This is very handwavy, because i’m speaking in very general terms. But for a single, narrow, non-general, concrete example, just look at the ORM impedence mismatch problem with OOP languages. AFAIK, after 40-some years it’s still unsolved. I don’t believe FP suffers from this specific problem (again, just to give a concrete and non-handwavy example), because FP is very analogous to relational programming (functions are a special case of relations). This shouldn’t be so controversial and should be very intuitive to anyone who spends a bit of time thinking about it. A function is fundamentally a simpler building block than a class. It’s more atomic.
- c_crank 3y ago
  I don't believe an ORM is a zero cost abstraction either. Or most of OOP. The cost of implementing everything as a function is when one has to contend with the fundamental machine architecture not dealing with everything as a function. This often leads to one of the highest cost abstractions out there, the Monad.
epgui 3y ago
There is no reason to use state at all here, let alone the state of the world. In FP you just do: x + 1 Moreover, this example is totally meaningless, because it doesn't feature anything that is different about FP and the imperative style at all.
- c_crank 3y ago
  y = x + 1 is not dealing with state. Supposing there was a desire to have x = x + 1, the simple way of doing this is x = x + 1, and the complicated way is to do world = Increment(x, world).