5 ms·

Wow, I sure have the opposite reaction to you. Makes me wonder what kind of code you wrote. Some specific points: "One is code reuse: yes FP code is definitely

Wow, I sure have the opposite reaction to you. Makes me wonder what kind of code you wrote. Some specific points: "One is code reuse: yes FP code is definitely more reusable. The problem is that the kind of code it enables reuse of more than OO is very small, simple loops." Combinator libraries sure are pretty useful, and they're more than small simple loops. "Writing the same 4 line method -- that could have been abstracted with a monad -- 10 times in a 50-150K LOC project is never a big problem" All our goes code through a bunch of monads (mostly Future + Writer). Very puzzled how you're using monads if they only appear 10 times in 50KLOC. "Another is state management" I think you're referring to STM here. That's been extensively explored in the Haskell community.

pron 12y ago
> Combinator libraries sure are pretty useful, and they're more than small simple loops. Useful -- yes. Useful enough to pay the price -- IMO, no. OO is decent at code reuse, and the most effective, most important code reuse, is that of big libraries with rich functionality, which is done rather well in many programming paradigms (i.e. pure, statically typed FP has little to no advantage here). > Very puzzled how you're using monads if they only appear 10 times in 50KLOC. I'm not. But OO code that refactoring with monads would have saved me does not amount to much. > I think you're referring to STM here. I was talking about more limited transactional (or "concurrently mutable") data structures like Clojure atoms and agents, or restricted STM like Clojure's refs and in-memory DBs (general purpose STM is pretty much dead). I know Haskell explores STM. I'm just saying you can enjoy the same benefits in Clojure or even Java.
- noelwelsh 12y ago
  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.
- seanmcdirmid 12y ago
  STM applies to OOP just as much as it does to FP. There is nothing magical about monads that make STM possible, they just make building the infrastructure for STM easier.

pron 12y ago

> Combinator libraries sure are pretty useful, and they're more than small simple loops. Useful -- yes. Useful enough to pay the price -- IMO, no. OO is decent at code reuse, and the most effective, most important code reuse, is that of big libraries with rich functionality, which is done rather well in many programming paradigms (i.e. pure, statically typed FP has little to no advantage here). > Very puzzled how you're using monads if they only appear 10 times in 50KLOC. I'm not. But OO code that refactoring with monads would have saved me does not amount to much. > I think you're referring to STM here. I was talking about more limited transactional (or "concurrently mutable") data structures like Clojure atoms and agents, or restricted STM like Clojure's refs and in-memory DBs (general purpose STM is pretty much dead). I know Haskell explores STM. I'm just saying you can enjoy the same benefits in Clojure or even Java.

noelwelsh 12y ago
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.
seanmcdirmid 12y ago
STM applies to OOP just as much as it does to FP. There is nothing magical about monads that make STM possible, they just make building the infrastructure for STM easier.