6 ms·

I'd say that "pure Functional programming" has become a no. But "Functional programming approach" has been subsumed into existing programming languages, e.g. r

I'd say that "pure Functional programming" has become a no. But "Functional programming approach" has been subsumed into existing programming languages, e.g. records in Java. You get most of the benefit of FP while keeping all of the other good stuf from an imperative language.

unregistereddev 3y ago
I'd agree with this and add that pattern matching and functional interfaces are additional examples of tools from the FP toolbox being subsumed into existing programming languages. Pure functional programming seems tempting. In small projects it can produce beautiful, readable code. In large projects I've only seen it result in messes, and I still haven't decided whether that's due to limitations of functional purity, due to the team (and myself) misusing features that we don't understand, or both.
ildjarn 3y ago
What mainstream languages have a good suite of FP features though? If you try to write mostly pure code in Java I’m afraid you’re in for a bad time, despite the (big!) improvements of records and lambdas. Minimum viable FP starts at OCaml, F#, Scala and Closure, yet none of these are mainstream.
- AS37 3y ago
  I code in C# and use a ton of LINQ when writing business logic. It's FP-ish enough to avoid logic mistakes. The mediator design pattern, which is kind of bringing another FP paradigm to the OO world, also features heavily.
  - ska 3y ago
    I think this is the point really, not that mainstream, "general purpose" languages support FP well, but that FP ideas and aspects have been adapted into many of them.
  - ildjarn 3y ago
    C# LINQ, being a round-about implementation of do-notation, is a pretty advanced FP feature, and beyond most mainstream languages. C# is certainly a step up over Java etc. However, most developers wouldn’t understand, say, a result monad implemented via LINQ, so you’re still fighting the ecosystem somewhat.
- anon291 3y ago
  Hold on... Purity and functional programming are different things. Functional programs can be pure but not necessarily. Functional programming means functions are first class citizens and can be constructed on the fly. Modern python, c++, rust, even java now do this. Purity is a nice to have (and arguably rusts borrow system enforces a kind of purity).
  - ildjarn 3y ago
    > Functional programming means functions are first class citizens and can be constructed on the fly. FP is much more than this one language feature.
    - anon291 3y ago
      Yes, the field of FP is much more, but the core of FP is that. A language doesn't become non-FP simply because it has some imperative abilities, or logic programming builtin, etc.
      - ildjarn 3y ago
        I’m arguing it’s not FP when you take an OOP language and bolt on lambdas. Lambdas are necessary but not sufficient. You need expression orientation, immutability by default, persistent collections in the standard library, some way to handle monadic code, etc…
        anon291 3y ago
        Immutability by default is not a requirement for functional programming (I mean... if it were, Haskell would be obviously not FP since the 'default' entrypoint is very mutable). Neither are monads. There are entire FP languages without monads for effects (obviously, you can write a monadic interface in them, but it's not part of the idiomatic core). For example, clean uses linear types to control effects and purescript / Idris use a custom effect-system. So no, monads are not a requirement, and even if they are, modern c++ fully supports them, as does rust, javascript, etc. It's very common in javascript to use Array.map() and Array.flat().
- paulddraper 3y ago
  Java streams. java.time Valhalla even
macintux 3y ago
Hybrid languages are sub-optimal in a lot of ways. One of the joys of functional programming are the guarantees that imperative languages can't offer (primarily immutability).
- jprival 3y ago
  “Functional style” doesn’t offer the same guarantees, sure, but I wouldn’t underestimate the structural and readability benefits it can offer for certain kinds of tasks.
- Terr_ 3y ago
  The moment you have any database or filesystem or remote-service, the hybridization starts anyway. Sure, technically a single computer's local RAM is being managed with strict guidelines, but that correlates less and less to overall application state and behavior these days.
  - marcosdumay 3y ago
    The promise of FRP was to solve this problem. It makes "state change" a first class object, and organizes your code around it. The problem is that nobody made an usable FRP system yet. It's not obvious why it's so hard, and everything feels like it should be easy. But everybody just keep failing.
    - canadianfella 3y ago
      [dead]
  - macintux 3y ago
    True, but you can isolate side effects. Knowing that a small collection of functions is not referentially transparent is better than having to deal with any part of the program potentially changing your state.
- dehrmann 3y ago
  > Hybrid languages are sub-optimal in a lot of ways. The real world is messy and stateful.
tubthumper8 3y ago
Definitely agree that mainstream languages are adopting functional features, but records aren't a functional feature. Records are basic data modeling and something that has been around since the beginning of programming languages, whether procedural or functional. It's one of the bare minimums of having a type system, and Java didn't have this due to the misguided belief that "everything is an object". I think records being added is more of a symptom of that belief weakening. There are functional features that have made it over to Java which are the things related to functions, i.e. lambdas and such which are a welcome addition.
- gardenhedge 3y ago
  Java records are object-oriented construct
  - tubthumper8 3y ago
    Maybe. It depends what the definition of "object-oriented" is, which depends what the definition of "object" is. Neither of which has any semblance of agreement among programmers. Many people would define an object as something that has externally visible behavior and internally hidden _data_. Objects could never be compared to each other for equality, because one could not access the internal data, only its public behavior. However, Java records can be compared for equality which objects would not. Java records also cannot be extended from. Inheritance is the only uniquely OOP feature, which doesn't apply here either. So I'm not sure that Java records are an object-oriented construct. First, the precise definition of OO should be established, and then we'll see
  - ildjarn 3y ago
    OOP is about bundling state and behaviour into units that hide their internal mechanisms by some kind of interface. Records can have no state - compared to regular classes - so they are an anti-OOP feature.
    - gardenhedge 3y ago
      I would say OOP revolves around the concept of modeling real-world entities or concepts as objects in code. Records encapsulate data fields within an object, providing a way to model real-world entities.
mrkeen 3y ago
> e.g. records in Java Aren't these just C structs? > You get most of the benefit of FP FP = Functions. Same output for the same input. No capability to interfere with (or to be interfered with) other functions.
- raydev 3y ago
  > Aren't these just C structs? Are C structs guaranteed to be immutable at compile-time?

unregistereddev 3y ago

I'd agree with this and add that pattern matching and functional interfaces are additional examples of tools from the FP toolbox being subsumed into existing programming languages. Pure functional programming seems tempting. In small projects it can produce beautiful, readable code. In large projects I've only seen it result in messes, and I still haven't decided whether that's due to limitations of functional purity, due to the team (and myself) misusing features that we don't understand, or both.

ildjarn 3y ago

What mainstream languages have a good suite of FP features though? If you try to write mostly pure code in Java I’m afraid you’re in for a bad time, despite the (big!) improvements of records and lambdas. Minimum viable FP starts at OCaml, F#, Scala and Closure, yet none of these are mainstream.

AS37 3y ago
I code in C# and use a ton of LINQ when writing business logic. It's FP-ish enough to avoid logic mistakes. The mediator design pattern, which is kind of bringing another FP paradigm to the OO world, also features heavily.
- ska 3y ago
  I think this is the point really, not that mainstream, "general purpose" languages support FP well, but that FP ideas and aspects have been adapted into many of them.
- ildjarn 3y ago
  C# LINQ, being a round-about implementation of do-notation, is a pretty advanced FP feature, and beyond most mainstream languages. C# is certainly a step up over Java etc. However, most developers wouldn’t understand, say, a result monad implemented via LINQ, so you’re still fighting the ecosystem somewhat.
anon291 3y ago
Hold on... Purity and functional programming are different things. Functional programs can be pure but not necessarily. Functional programming means functions are first class citizens and can be constructed on the fly. Modern python, c++, rust, even java now do this. Purity is a nice to have (and arguably rusts borrow system enforces a kind of purity).
- ildjarn 3y ago
  > Functional programming means functions are first class citizens and can be constructed on the fly. FP is much more than this one language feature.
  - anon291 3y ago
    Yes, the field of FP is much more, but the core of FP is that. A language doesn't become non-FP simply because it has some imperative abilities, or logic programming builtin, etc.
    - ildjarn 3y ago
      I’m arguing it’s not FP when you take an OOP language and bolt on lambdas. Lambdas are necessary but not sufficient. You need expression orientation, immutability by default, persistent collections in the standard library, some way to handle monadic code, etc…
      - anon291 3y ago
        Immutability by default is not a requirement for functional programming (I mean... if it were, Haskell would be obviously not FP since the 'default' entrypoint is very mutable). Neither are monads. There are entire FP languages without monads for effects (obviously, you can write a monadic interface in them, but it's not part of the idiomatic core). For example, clean uses linear types to control effects and purescript / Idris use a custom effect-system. So no, monads are not a requirement, and even if they are, modern c++ fully supports them, as does rust, javascript, etc. It's very common in javascript to use Array.map() and Array.flat().
paulddraper 3y ago
Java streams. java.time Valhalla even

macintux 3y ago

Hybrid languages are sub-optimal in a lot of ways. One of the joys of functional programming are the guarantees that imperative languages can't offer (primarily immutability).

jprival 3y ago
“Functional style” doesn’t offer the same guarantees, sure, but I wouldn’t underestimate the structural and readability benefits it can offer for certain kinds of tasks.
Terr_ 3y ago
The moment you have any database or filesystem or remote-service, the hybridization starts anyway. Sure, technically a single computer's local RAM is being managed with strict guidelines, but that correlates less and less to overall application state and behavior these days.
- marcosdumay 3y ago
  The promise of FRP was to solve this problem. It makes "state change" a first class object, and organizes your code around it. The problem is that nobody made an usable FRP system yet. It's not obvious why it's so hard, and everything feels like it should be easy. But everybody just keep failing.
  - canadianfella 3y ago
    [dead]
- macintux 3y ago
  True, but you can isolate side effects. Knowing that a small collection of functions is not referentially transparent is better than having to deal with any part of the program potentially changing your state.
dehrmann 3y ago
> Hybrid languages are sub-optimal in a lot of ways. The real world is messy and stateful.

tubthumper8 3y ago

Definitely agree that mainstream languages are adopting functional features, but records aren't a functional feature. Records are basic data modeling and something that has been around since the beginning of programming languages, whether procedural or functional. It's one of the bare minimums of having a type system, and Java didn't have this due to the misguided belief that "everything is an object". I think records being added is more of a symptom of that belief weakening. There are functional features that have made it over to Java which are the things related to functions, i.e. lambdas and such which are a welcome addition.

gardenhedge 3y ago
Java records are object-oriented construct
- tubthumper8 3y ago
  Maybe. It depends what the definition of "object-oriented" is, which depends what the definition of "object" is. Neither of which has any semblance of agreement among programmers. Many people would define an object as something that has externally visible behavior and internally hidden _data_. Objects could never be compared to each other for equality, because one could not access the internal data, only its public behavior. However, Java records can be compared for equality which objects would not. Java records also cannot be extended from. Inheritance is the only uniquely OOP feature, which doesn't apply here either. So I'm not sure that Java records are an object-oriented construct. First, the precise definition of OO should be established, and then we'll see
- ildjarn 3y ago
  OOP is about bundling state and behaviour into units that hide their internal mechanisms by some kind of interface. Records can have no state - compared to regular classes - so they are an anti-OOP feature.
  - gardenhedge 3y ago
    I would say OOP revolves around the concept of modeling real-world entities or concepts as objects in code. Records encapsulate data fields within an object, providing a way to model real-world entities.

mrkeen 3y ago

> e.g. records in Java Aren't these just C structs? > You get most of the benefit of FP FP = Functions. Same output for the same input. No capability to interfere with (or to be interfered with) other functions.

raydev 3y ago
> Aren't these just C structs? Are C structs guaranteed to be immutable at compile-time?