6 ms·

There seems to be an implication in your comment that people aren't using FP to write "big serious programs". Is that really what you are implying?

by DCKing 12y ago

seanmcdirmid 12y ago
In that domain, yes! How many UI frameworks are functional (beyond I think...Om?)?
- agumonkey 12y ago
  Let's wait and see if Om inspire others. You know that ideas take time to diffuse, OOP/MVC has been a somehow natural fit for IHM, but like many other ideas (closures?) now that people can see it, maybe they'll change their mind.
- DCKing 12y ago
  It's unfair to focus on "UI frameworks" when UI frameworks are specifically aimed at supporting client OSes where they have to deal with "preferred frameworks", all of which were developed when OO was all the craze. Functional programming has only been discovered as a practical paradigm quite recently! Besides, implying that "big serious programs" necessarily implies that they are UI programs is completely wrong. Unsurpisingly, if a given JS UI framework is OO, it is not OO in the traditional sense because JavaScript itself is not OO in the traditional sense. If you make a framework, you use the language of whatever runtime you are targeting. Functional programming is often used to write server code that must easily parallelize and scale across cores, CPUs and clusters. Mostly because the FP paradigm is more obviously advantageous in that setting, but also because those services have less baggage of trends than UI heavy programs do. So you are arguing that there is some perceived evidence for OO in UI programming, but I think that could more easily be attributed to historical trends. Note that I'm not necessarily disagreeing with your conclusion, just that your reasoning is flawed.
  - mike_hearn 12y ago
    Functional programming has been known and researched for decades. Mostly what happens is the obviously good features filter down into more mainstream languages, hence the new stream extension in Java 8, and the rest (lazy by default?) gets left behind.
    - DCKing 12y ago
      The key selling point of functional languages is not lambdas, but immutable state and referential transparency. People read "advantages of functional programming" and think "anonymous functions" and "they're talking about scary Haskell" which is wrong. Although lambdas are a big improvement to Java, they are not helping enough to make the language more functional. Java is built upon mutable state to its very core, and will never share FP's redeeming qualities. Lazy by default is a feature of Haskell, and is not a feature of (or necessary for) functional programming. Scala, OCaml, F# and Lisps are not lazy by default.
      - sigmaml 12y ago
        > The key selling point of functional languages is not lambdas, but immutable state and referential transparency. Not everyone agrees, evidently! In his influential paper, Hughes argues that higher-order functions and laziness are key to functional programming.
        seanmcdirmid 12y ago
        I'm going to agree with parent. OO programming is mostly about objects...they have names and identity, with that identity they can have mutable state (would be difficult to have state without identity and aliasing). In pure functional programming land, all values are anonymous, there is no way to tell if you seen something for unless you setup a GUID in the value (which would also require state, but whatever). Those values have no identity, so mutable state is impossible, leading to a very different style of programming. If you allow for value identities (via GUIDs or if your language is really impure) in your functional code, you wind up with a style of programming that is very similar to programming with objects (messaging those values to do things with their state). Heck, you wouldn't even need overt mutable state to arrive at a very OO style (see clojure).

There seems to be an implication in your comment that people aren't using FP to write "big serious programs". Is that really what you are implying?

by DCKing 12y ago

There seems to be an implication in your comment that people aren't using FP to write "big serious programs". Is that really what you are implying?

seanmcdirmid 12y ago

In that domain, yes! How many UI frameworks are functional (beyond I think...Om?)?

agumonkey 12y ago
Let's wait and see if Om inspire others. You know that ideas take time to diffuse, OOP/MVC has been a somehow natural fit for IHM, but like many other ideas (closures?) now that people can see it, maybe they'll change their mind.
DCKing 12y ago
It's unfair to focus on "UI frameworks" when UI frameworks are specifically aimed at supporting client OSes where they have to deal with "preferred frameworks", all of which were developed when OO was all the craze. Functional programming has only been discovered as a practical paradigm quite recently! Besides, implying that "big serious programs" necessarily implies that they are UI programs is completely wrong. Unsurpisingly, if a given JS UI framework is OO, it is not OO in the traditional sense because JavaScript itself is not OO in the traditional sense. If you make a framework, you use the language of whatever runtime you are targeting. Functional programming is often used to write server code that must easily parallelize and scale across cores, CPUs and clusters. Mostly because the FP paradigm is more obviously advantageous in that setting, but also because those services have less baggage of trends than UI heavy programs do. So you are arguing that there is some perceived evidence for OO in UI programming, but I think that could more easily be attributed to historical trends. Note that I'm not necessarily disagreeing with your conclusion, just that your reasoning is flawed.
- mike_hearn 12y ago
  Functional programming has been known and researched for decades. Mostly what happens is the obviously good features filter down into more mainstream languages, hence the new stream extension in Java 8, and the rest (lazy by default?) gets left behind.
  - DCKing 12y ago
    The key selling point of functional languages is not lambdas, but immutable state and referential transparency. People read "advantages of functional programming" and think "anonymous functions" and "they're talking about scary Haskell" which is wrong. Although lambdas are a big improvement to Java, they are not helping enough to make the language more functional. Java is built upon mutable state to its very core, and will never share FP's redeeming qualities. Lazy by default is a feature of Haskell, and is not a feature of (or necessary for) functional programming. Scala, OCaml, F# and Lisps are not lazy by default.
    - sigmaml 12y ago
      > The key selling point of functional languages is not lambdas, but immutable state and referential transparency. Not everyone agrees, evidently! In his influential paper, Hughes argues that higher-order functions and laziness are key to functional programming.
      - seanmcdirmid 12y ago
        I'm going to agree with parent. OO programming is mostly about objects...they have names and identity, with that identity they can have mutable state (would be difficult to have state without identity and aliasing). In pure functional programming land, all values are anonymous, there is no way to tell if you seen something for unless you setup a GUID in the value (which would also require state, but whatever). Those values have no identity, so mutable state is impossible, leading to a very different style of programming. If you allow for value identities (via GUIDs or if your language is really impure) in your functional code, you wind up with a style of programming that is very similar to programming with objects (messaging those values to do things with their state). Heck, you wouldn't even need overt mutable state to arrive at a very OO style (see clojure).