5 ms·

The funny thing is it's exactly the same thing with functional languages, and no, there's no clear definition of FP. Some FP is lazy, some isn't. Some is immuta

by slver 5y ago

The funny thing is it's exactly the same thing with functional languages, and no, there's no clear definition of FP. Some FP is lazy, some isn't. Some is immutable, some isn't. Some claim it's a style in any language, others that it's a type of language.

jtdev 5y ago
FP is a cult.
- ebingdom 5y ago
  > FP is a cult. It's a programming paradigm based on simple, well-understood mathematical framework. It's also the starting point for most research in programming language theory.
  - jtdev 5y ago
    Explain why closures are allowed to mutate state in this “simple, well understood” framework.
    - valenterry 5y ago
      They are not allowed to. Why do you think they are?
      - jtdev 5y ago
        From the Swift docs regarding closures (I would have used Haskell doc reference, but the Haskell docs are so esoteric and vague as to be nearly useless): “A closure can capture constants and variables from the surrounding context in which it’s defined. The closure can then refer to and modify the values of those constants and variables from within its body, even if the original scope that defined the constants and variables no longer exists.” https://docs.swift.org/swift-book/LanguageGuide/Closures.html https://docs.swift.org/swift-book/LanguageGuide/Closures.htm...
        valenterry 5y ago
        Swift is not a language that enforces code to be pure functional though.
        jtdev 5y ago
        FP = debating largely academic nuances that have almost zero material effect on software deliverables, purely for ego driven reasons.
        ebingdom 5y ago
        > From the Swift docs regarding closures What makes you think Swift only supports functional programming? > I would have used Haskell doc reference And if you would have, you would have disproved your own point. In Haskell, closures cannot mutate state, because mutable state is not part of the language semantics. It's modeled explicitly via monads.
    - pflanze 5y ago
      Whether closures are or are not allowed to mutate state depends on the programming language (or the aim of the programmer, if the programming language doesn't force their way). Closures are a syntactical building block helping functional programming (building functions out of objects is just much more syntactical overhead), but whether a particular closure is a pure function or not is a separate concern. If the function is to be pure (hence satisfying the core of the "framework") then it would not be allowed to mutate state.
ebingdom 5y ago
It's true that functional programming also doesn't have a formal definition, but I wouldn't say it's "exactly the same" as with OOP. Functional programming is based on a simple well-understood mathematical model: lambda calculus. While there are different flavors of lambda calculus, they are related in obvious ways and one can reach formal conclusions them as a whole, e.g., the Church-Rosser theorem. In contrast, the many attempts to formalize the essence of OOP have resulted in countless wildly different results, so it's impossible to say anything meaningful about OOP, with the possible exception of this sentence.
- ebingdom 5y ago
  To all the people downvoting me: if you really think OOP is as well understood as FP, learn some programming language theory. Tell me what the universally agreed foundation of OOP is. You won't be able to, but I can tell for FP it's lambda calculus.
  - jasperry 5y ago
    I agree that functional programming has a more widely agreed-upon foundational set of definitions than OOP. However, it doesn't follow from that that "it's impossible to say anything meaningful about OOP".
  - slver 5y ago
    > Tell me what the universally agreed foundation of OOP is. I'll deliberately avoid terms so we don't get to argue about words, but rather substance. 1. Objects have identity that's independent of their state (two objects with same state are still distinct). 2. Objects contain implementation which is hidden, including optionally mutable state. 3. Communication occurs through handlers/methods/calls, which provide only INDIRECT access to the object's internal state. 4. Objects can stand for one another, if their handlers react in a compatible way with the object they're replacing. I tried to keep it as basic as possible, while avoiding topics about inheritance and what not. Now the question is "do you need an OOP language to do OOP", and no, you don't. There's overlap. For example if you take the above, you'll notice that closures in FP match all of those except one thing: mutable state. So if your FP language allows mutable state, then you can do OOP in it with closures. And that's not a proof that OOP is not a thing, rather it's a proof that what some small minds keep putting in opposition, things like FP vs OOP vs DOP are just pieces of a larger puzzle that forms a single cohesive picture.
pflanze 5y ago
AFAICT the core of FP is referential transparency. The "meat" of FP are the tools available which allow to (comfortably) increase the portion of the program that is referentially transparent. Immutability, first class functions, laziness are all such tools. And which tools are used can vary, just like the tools that help "doing OO" can vary. But I think that FP does have that core which has a glass clear definition. I'm not sure which is the core of OO. Maybe it's the idea of "encapsulating" mutation (basically inverting the core of FP). Maybe it's the principle of virtual methods / messaging. It's not so clear I think.
valenterry 5y ago
FP means that every expression (= part that can be evaluated) is referential transparent. Nowadays the word "functional" is used different from the original meaning (which some now call "pure functional") > Some FP is lazy, some isn't. The definition of FP implies that laziness is irrelevant. A language can enforce a pure functional style without being lazy or not. > Some is immutable, some isn't That's wrong. And it is a good example of why FP is much clearer defined. Referential transparency implies immutability. So there is no pure FP code that uses mutability. > Some claim it's a style in any language, others that it's a type of language. It's neither. It is a property of a program. Some languages enforce this property, others make it impossible to write a full program in this style. But that's independent of the definition itself. I hope that explanation sheds a bit of light into it.
- pflanze 5y ago
  > FP means that every expression (= part that can be evaluated) is referential transparent. Most real-world programming requires handling of side effects somewhere, so such programs have parts which are not referentially transparent. It's why I distinguished between "core" and "meat" in my other response. Functional programming languages offer features that help making a larger part of the program referentially transparent (and, optionally, to ensure that property in the types). > Nowadays the word "functional" is used different from the original meaning (which some now call "pure functional") I don't think the meaning changed, just the tools offered and the scope of the support they offer to achieve referential transparency (pure functions). Early Lisp offered expression oriented programming which was a step towards it, but used dynamic scoping which isn't really helping. Later on both Lisps and ML offered lexical scoping. Then the purely functional trend came up via Miranda and (Clean and) Haskell, the latter encoding purity in the type system. In the last decade mainstream programming languages added functional programming features but are falling short in encoding purity in the types (just as Lisp never did), which means that it's (easily) possible for the abstractions offered (both functions but also libraries built on iterators) to not be referentially transparent, manual care (and/or culture) is required instead. The tooling doesn't help enough to guarantee referential transparency. But the core idea, the target of the efforts, is the same. > Referential transparency implies immutability. I didn't go into immutability in my other response because you can use mutation inside pure functions, as long as the effect doesn't leave the function. Building referentially transparent functions does not imply using immutable data structures or variable bindings inside.

by slver 5y ago

jtdev 5y ago

FP is a cult.

ebingdom 5y ago
> FP is a cult. It's a programming paradigm based on simple, well-understood mathematical framework. It's also the starting point for most research in programming language theory.
- jtdev 5y ago
  Explain why closures are allowed to mutate state in this “simple, well understood” framework.
  - valenterry 5y ago
    They are not allowed to. Why do you think they are?
    - jtdev 5y ago
      From the Swift docs regarding closures (I would have used Haskell doc reference, but the Haskell docs are so esoteric and vague as to be nearly useless): “A closure can capture constants and variables from the surrounding context in which it’s defined. The closure can then refer to and modify the values of those constants and variables from within its body, even if the original scope that defined the constants and variables no longer exists.” https://docs.swift.org/swift-book/LanguageGuide/Closures.html https://docs.swift.org/swift-book/LanguageGuide/Closures.htm...
      - valenterry 5y ago
        Swift is not a language that enforces code to be pure functional though.
        jtdev 5y ago
        FP = debating largely academic nuances that have almost zero material effect on software deliverables, purely for ego driven reasons.
      - ebingdom 5y ago
        > From the Swift docs regarding closures What makes you think Swift only supports functional programming? > I would have used Haskell doc reference And if you would have, you would have disproved your own point. In Haskell, closures cannot mutate state, because mutable state is not part of the language semantics. It's modeled explicitly via monads.
  - pflanze 5y ago
    Whether closures are or are not allowed to mutate state depends on the programming language (or the aim of the programmer, if the programming language doesn't force their way). Closures are a syntactical building block helping functional programming (building functions out of objects is just much more syntactical overhead), but whether a particular closure is a pure function or not is a separate concern. If the function is to be pure (hence satisfying the core of the "framework") then it would not be allowed to mutate state.

ebingdom 5y ago

It's true that functional programming also doesn't have a formal definition, but I wouldn't say it's "exactly the same" as with OOP. Functional programming is based on a simple well-understood mathematical model: lambda calculus. While there are different flavors of lambda calculus, they are related in obvious ways and one can reach formal conclusions them as a whole, e.g., the Church-Rosser theorem. In contrast, the many attempts to formalize the essence of OOP have resulted in countless wildly different results, so it's impossible to say anything meaningful about OOP, with the possible exception of this sentence.

ebingdom 5y ago
To all the people downvoting me: if you really think OOP is as well understood as FP, learn some programming language theory. Tell me what the universally agreed foundation of OOP is. You won't be able to, but I can tell for FP it's lambda calculus.
- jasperry 5y ago
  I agree that functional programming has a more widely agreed-upon foundational set of definitions than OOP. However, it doesn't follow from that that "it's impossible to say anything meaningful about OOP".
- slver 5y ago
  > Tell me what the universally agreed foundation of OOP is. I'll deliberately avoid terms so we don't get to argue about words, but rather substance. 1. Objects have identity that's independent of their state (two objects with same state are still distinct). 2. Objects contain implementation which is hidden, including optionally mutable state. 3. Communication occurs through handlers/methods/calls, which provide only INDIRECT access to the object's internal state. 4. Objects can stand for one another, if their handlers react in a compatible way with the object they're replacing. I tried to keep it as basic as possible, while avoiding topics about inheritance and what not. Now the question is "do you need an OOP language to do OOP", and no, you don't. There's overlap. For example if you take the above, you'll notice that closures in FP match all of those except one thing: mutable state. So if your FP language allows mutable state, then you can do OOP in it with closures. And that's not a proof that OOP is not a thing, rather it's a proof that what some small minds keep putting in opposition, things like FP vs OOP vs DOP are just pieces of a larger puzzle that forms a single cohesive picture.

pflanze 5y ago

AFAICT the core of FP is referential transparency. The "meat" of FP are the tools available which allow to (comfortably) increase the portion of the program that is referentially transparent. Immutability, first class functions, laziness are all such tools. And which tools are used can vary, just like the tools that help "doing OO" can vary. But I think that FP does have that core which has a glass clear definition. I'm not sure which is the core of OO. Maybe it's the idea of "encapsulating" mutation (basically inverting the core of FP). Maybe it's the principle of virtual methods / messaging. It's not so clear I think.

valenterry 5y ago

FP means that every expression (= part that can be evaluated) is referential transparent. Nowadays the word "functional" is used different from the original meaning (which some now call "pure functional") > Some FP is lazy, some isn't. The definition of FP implies that laziness is irrelevant. A language can enforce a pure functional style without being lazy or not. > Some is immutable, some isn't That's wrong. And it is a good example of why FP is much clearer defined. Referential transparency implies immutability. So there is no pure FP code that uses mutability. > Some claim it's a style in any language, others that it's a type of language. It's neither. It is a property of a program. Some languages enforce this property, others make it impossible to write a full program in this style. But that's independent of the definition itself. I hope that explanation sheds a bit of light into it.

pflanze 5y ago
> FP means that every expression (= part that can be evaluated) is referential transparent. Most real-world programming requires handling of side effects somewhere, so such programs have parts which are not referentially transparent. It's why I distinguished between "core" and "meat" in my other response. Functional programming languages offer features that help making a larger part of the program referentially transparent (and, optionally, to ensure that property in the types). > Nowadays the word "functional" is used different from the original meaning (which some now call "pure functional") I don't think the meaning changed, just the tools offered and the scope of the support they offer to achieve referential transparency (pure functions). Early Lisp offered expression oriented programming which was a step towards it, but used dynamic scoping which isn't really helping. Later on both Lisps and ML offered lexical scoping. Then the purely functional trend came up via Miranda and (Clean and) Haskell, the latter encoding purity in the type system. In the last decade mainstream programming languages added functional programming features but are falling short in encoding purity in the types (just as Lisp never did), which means that it's (easily) possible for the abstractions offered (both functions but also libraries built on iterators) to not be referentially transparent, manual care (and/or culture) is required instead. The tooling doesn't help enough to guarantee referential transparency. But the core idea, the target of the efforts, is the same. > Referential transparency implies immutability. I didn't go into immutability in my other response because you can use mutation inside pure functions, as long as the effect doesn't leave the function. Building referentially transparent functions does not imply using immutable data structures or variable bindings inside.