2 ms·

I don't agree with your definition of FP then. Erlang is broadly the same as Clojure: pure in the small but stateful in the large (mailboxes in Erlang store sta

I don't agree with your definition of FP then. Erlang is broadly the same as Clojure: pure in the small but stateful in the large (mailboxes in Erlang store state). Your basic argument seems to come down to Haskell (the only pure statically typed language with any widespread adoption) vs any other language. That's not an argument I'm particularly interested in. As for OO vs FP in combinator libraries -- the same pattern is often called a fluent interface in OO. This gets to the larger point that FP is as much a programming style as a language that supports that style, and you can program in a FP style in any language. The question I'm interested in is "is FP style useful?" to which I give a resounding "yes!"

pron 12y ago
I agree with every word. Alas, FP does not have a definition, so, when I was saying "FP", I meant "FP as the article's author practices", which means "statically typed, pure FP". FP using Java streams, FP in Clojure/Erlang, and FP in Haskell mean very different things.
- noelwelsh 12y ago
  Agreement with someone on the Internet? o.O ;-) [To the downvoters: this is me replying to the conversation I've had in the previous posts in this thread. If you can't handle my surprise and happiness at reaching some agreement hit up 4chan.]
seanmcdirmid 12y ago
All Erlang, Clojure, Scheme sport pretty nifty object systems, even if they don't resemble the Java kind. I find it funny when someone espouses the benefits of functional programming with...objects? On the other hand, these languages are quite pragmatic and I believe such blending is the future. The only language that is purely FP is Haskell. It doesn't have anything that we could mistake for an object system, its functions all the way down! Fluent interfaces should die a horrible death; it is a confusing style in OOP and quite easy to make lots of errors without the equational reasoning that supports combinators in FP.
- tel 12y ago
  Haskell completely has something you can mistake as an object system! The entire typeclass machinery works that way less classes and inheritance. There's even a highly functional subtyping relation.
  - seanmcdirmid 12y ago
    Type classes work strictly over values, with none of the naming machinery to give these values names and identities. Type classes only resemble classes in their unfortunate label; subtyping and polymorphism isn't really exclusive to OOP (with the exception of name-oriented nominal subtyping). The only way to create an object in Haskell is through giving it a GUID of some kind.
    - tel 12y ago
      I'm not claiming typeclasses are classes, but more like modules and that modules achieve at least some of OO. Entity-like identity is a notably more difficult thing to pull off, but still is easily embedded in IO or ST. I'm not saying it's a complete OO implementation, but instead that it's not so far as to be completely unconfusable, though it might be hard to, say, do Smalltalk-in-Haskell.
      - seanmcdirmid 12y ago
        Typeclasses don't give you any specific to OO: they are abstractions over values and that's about it. You wouldn't be able to emulate an existing OO system in Haskell, and anyways, it wouldn't bring you closer to "talking about" and "thinking in terms of" objects. My point that OOP is essentially "thinking in terms of named objects" whereas most of what Haskell focuses on is "expressing math by composing anonymous values." I believe this starting from a design perspective is the best way to highlight the real differences between OOP and pure FP.
        tel 12y ago
        I disagree, but I think we'd have to go to definitions to make headway on this conversation, so I'll back out. As final thoughts: while type classes give abstraction over values, (a) those values encompass HKTs so they can also be effectual in various ways and (b) universally quantified bounded types are a basically final algebras and codata goes a long way toward modeling objects. Between those two I think you can give OO in Haskell a run.
deleted 12y ago
[deleted]

pron 12y ago

I agree with every word. Alas, FP does not have a definition, so, when I was saying "FP", I meant "FP as the article's author practices", which means "statically typed, pure FP". FP using Java streams, FP in Clojure/Erlang, and FP in Haskell mean very different things.

noelwelsh 12y ago
Agreement with someone on the Internet? o.O ;-) [To the downvoters: this is me replying to the conversation I've had in the previous posts in this thread. If you can't handle my surprise and happiness at reaching some agreement hit up 4chan.]

seanmcdirmid 12y ago

All Erlang, Clojure, Scheme sport pretty nifty object systems, even if they don't resemble the Java kind. I find it funny when someone espouses the benefits of functional programming with...objects? On the other hand, these languages are quite pragmatic and I believe such blending is the future. The only language that is purely FP is Haskell. It doesn't have anything that we could mistake for an object system, its functions all the way down! Fluent interfaces should die a horrible death; it is a confusing style in OOP and quite easy to make lots of errors without the equational reasoning that supports combinators in FP.

tel 12y ago
Haskell completely has something you can mistake as an object system! The entire typeclass machinery works that way less classes and inheritance. There's even a highly functional subtyping relation.
- seanmcdirmid 12y ago
  Type classes work strictly over values, with none of the naming machinery to give these values names and identities. Type classes only resemble classes in their unfortunate label; subtyping and polymorphism isn't really exclusive to OOP (with the exception of name-oriented nominal subtyping). The only way to create an object in Haskell is through giving it a GUID of some kind.
  - tel 12y ago
    I'm not claiming typeclasses are classes, but more like modules and that modules achieve at least some of OO. Entity-like identity is a notably more difficult thing to pull off, but still is easily embedded in IO or ST. I'm not saying it's a complete OO implementation, but instead that it's not so far as to be completely unconfusable, though it might be hard to, say, do Smalltalk-in-Haskell.
    - seanmcdirmid 12y ago
      Typeclasses don't give you any specific to OO: they are abstractions over values and that's about it. You wouldn't be able to emulate an existing OO system in Haskell, and anyways, it wouldn't bring you closer to "talking about" and "thinking in terms of" objects. My point that OOP is essentially "thinking in terms of named objects" whereas most of what Haskell focuses on is "expressing math by composing anonymous values." I believe this starting from a design perspective is the best way to highlight the real differences between OOP and pure FP.
      - tel 12y ago
        I disagree, but I think we'd have to go to definitions to make headway on this conversation, so I'll back out. As final thoughts: while type classes give abstraction over values, (a) those values encompass HKTs so they can also be effectual in various ways and (b) universally quantified bounded types are a basically final algebras and codata goes a long way toward modeling objects. Between those two I think you can give OO in Haskell a run.

deleted 12y ago

[deleted]