4 ms·

pure FP is just like pure OO As someone who did OO for ten years and is doing FP full time, this statement is absurd. Why constraint ourselves? You are n

by runT1ME 10y ago

pure FP is just like pure OO As someone who did OO for ten years and is doing FP full time, this statement is absurd. Why constraint ourselves? You are not constrained in any way by FP, you just have to make everything explicit so programs are easier to read and reason about. There's nothing I can't do in a pure FP language. The world is not pure, The world is not a touring machine either, does this argument have more substance or is it just an offhanded comment...? our programs don't become ANY better because of the IO monad Do you actually have any experience with functional programming? Non rhetorical...it's such an odd thing to say. Programs absolutely become better when you encapsulate IO in a monadic context. The entire point is to demarcate what functions interact with the world and which don't. This makes testing easier, reading code easier, composition easier. What functional language do you have experience with that would lead you to these bizzare conclusions? :)

allover 10y ago
> The entire point is to demarcate what functions interact with the world and which don't. This makes testing easier, reading code easier, composition easier. This is 1. a tradeoff , 2. subjective. Words like 'bizarre' aren't really necessary, and come off as feigned surprise (passive aggressive). You think a function being easier to test (without reaching for extra tools like mocking libraries, presumably), justifies needing to write and understand 'monads' in order to interact with the real world. Another programmer finds myObject.doExplicitThingToWorld() far more expressive and easy to understand and is very familiar with the mocking tools/practices they need to test that. As for composition ... well composhmishion. It's so rare you can actually compose your business logic/app-code (beyond the original use-case you wrote the thing for, which you might well have chosen to write in a 'compositional' way). It's neat for frameworks and libraries to create composable stuff but it just doesn't come up as often as we'd all like to hope in our day-to-day code in my experience. And if you really want to compose something OO absolutely has ways to do it. (So composition is not the big win over OO some FP fans make it out to be IMO).
- boubiyeah 10y ago
  Agreed. I've used many nice libs using various monads, applicative builders, functors, yada yada under the hood; It can make the libs more pleasant to use for an end user for sure. But telling people that you should write EVERYTHING using this style because it's "objectively" superior strikes me as being almost religious. Surely, you don't need IO monads to write, say, an API server.
  - chriswarbo 10y ago
    At least in Haskell, things like `Monad`, `Functor`, `Applicative`, etc. are just interfaces ("type classes"). You can ignore them if you like, so you don't need IO monads, or any other monads, to write, say, an API server; in the same way that, for example, in Java just because you have an Iterable value doesn't mean you need to iterate over it. In comparison, `IO` is a type (actually a "type constructor", AKA a generic). Since many useful functions (e.g. `readFile`) return values of this type, it's pretty hard to avoid; although you can probably get quite far by ignoring types completely and having everything inferred. In that sense you do need `IO` to write, say, an API server; but I think that's pretty reasonable, since you want you server to read input and write output. Whether or not `IO` is a `Monad`, `Functor`, `Monoid`, `Alternative`, etc. doesn't really matter for that. Of course, you can always wrap your code in `do { ...; }`, cause all the side-effects you like, and ignore the fact that behind the scenes it just-so-happens that you're using a monad; after all, that's what pretty much all imperative languages do! More seriously, I think that the Haskell community should try to avoid this habit of saying "the Foo monad", when "a Foo value" would be more accurate, since I think it can confuse new users about types, values, type classes and instances. In particular it can give the false impression (reflected in your comment) that writing simple programs in Haskell (or FP in general) requires learning fancy things like monads. In reality, that's no more true than claiming that before writing a Web site in PHP you have to learn inversion-of-control containers. They're a commonly used framework/scaffolding, but there's no reason to confront them before you've written a few applications without, and hence are able to appreciate why they exist and what problems they do/don't solve. This mostly seems to be a problem for IO and Maybe. In particular, "State monad" and "Reader monad" don't have this problem, since their values have more widely used names like pairs/tuples and functions, respectively. Likewise, I've not seen this happen with other type classes, like "it returns a Maybe functor", or "I need to combine two List monoids".
daxfohl 10y ago
In my experience either IO absorbs everything but the most trivial trinkets that I wouldn't ever mess up anyway, or I go so far out of my way to avoid IO that it's near impossible to keep track of all the layers of abstraction. The first case adds nothing and the second case hurts more than it helps. That said, most of my work is "doing stuff", not data manipulation, so perhaps that's the difference. Also "OOP" for me is C#, which has plenty of FP features (though F# style records and `with` syntax are annoyingly missing); if I was comparing Haskell to Java 1.0 code then I could imagine seeing things differently.
- boubiyeah 10y ago
  Exactly. It doesn't document much. In any non trivial Elm program, 2/3 of your update fonctions are going to return Tasks. So what, nothing is pure? ok. imo, types shouldn't be used to compensate for the lack of separation of concerns (simple data manipulation VS IO)
- runT1ME 10y ago
  in my experience either IO absorbs everything but the most trivial trinkets that I wouldn't ever mess up anyway You mean you never mess up business logic? IO should only really be used when you need to be interacting with the world, IE, network calls, UI, etc.
  - daxfohl 10y ago
    Interesting you ask, because honestly the answer is, not really. In the grand scheme of things, business logic isn't that difficult. Take some data in, process it, output it. And what Haskell provides over C#, an explicit separation of purity and impurity, isn't that great of a help. I design most of my logic to be pure anyway, and when it's not there's a reason for it. Forcing me to jump through hoops to handle those few cases of necessary impurity generally harms more than it helps. "Difficult" code is stuff that involves things like distributed transactions and whatnot. All that stuff has to be bundled in a big wad of IO anyway and so Haskell has nothing to help out with that in the first place (if there was a language that could, I'd be all over it). At least that's my experience. YMMV.

by runT1ME 10y ago

allover 10y ago

> The entire point is to demarcate what functions interact with the world and which don't. This makes testing easier, reading code easier, composition easier. This is 1. a tradeoff , 2. subjective. Words like 'bizarre' aren't really necessary, and come off as feigned surprise (passive aggressive). You think a function being easier to test (without reaching for extra tools like mocking libraries, presumably), justifies needing to write and understand 'monads' in order to interact with the real world. Another programmer finds myObject.doExplicitThingToWorld() far more expressive and easy to understand and is very familiar with the mocking tools/practices they need to test that. As for composition ... well composhmishion. It's so rare you can actually compose your business logic/app-code (beyond the original use-case you wrote the thing for, which you might well have chosen to write in a 'compositional' way). It's neat for frameworks and libraries to create composable stuff but it just doesn't come up as often as we'd all like to hope in our day-to-day code in my experience. And if you really want to compose something OO absolutely has ways to do it. (So composition is not the big win over OO some FP fans make it out to be IMO).

boubiyeah 10y ago
Agreed. I've used many nice libs using various monads, applicative builders, functors, yada yada under the hood; It can make the libs more pleasant to use for an end user for sure. But telling people that you should write EVERYTHING using this style because it's "objectively" superior strikes me as being almost religious. Surely, you don't need IO monads to write, say, an API server.
- chriswarbo 10y ago
  At least in Haskell, things like `Monad`, `Functor`, `Applicative`, etc. are just interfaces ("type classes"). You can ignore them if you like, so you don't need IO monads, or any other monads, to write, say, an API server; in the same way that, for example, in Java just because you have an Iterable value doesn't mean you need to iterate over it. In comparison, `IO` is a type (actually a "type constructor", AKA a generic). Since many useful functions (e.g. `readFile`) return values of this type, it's pretty hard to avoid; although you can probably get quite far by ignoring types completely and having everything inferred. In that sense you do need `IO` to write, say, an API server; but I think that's pretty reasonable, since you want you server to read input and write output. Whether or not `IO` is a `Monad`, `Functor`, `Monoid`, `Alternative`, etc. doesn't really matter for that. Of course, you can always wrap your code in `do { ...; }`, cause all the side-effects you like, and ignore the fact that behind the scenes it just-so-happens that you're using a monad; after all, that's what pretty much all imperative languages do! More seriously, I think that the Haskell community should try to avoid this habit of saying "the Foo monad", when "a Foo value" would be more accurate, since I think it can confuse new users about types, values, type classes and instances. In particular it can give the false impression (reflected in your comment) that writing simple programs in Haskell (or FP in general) requires learning fancy things like monads. In reality, that's no more true than claiming that before writing a Web site in PHP you have to learn inversion-of-control containers. They're a commonly used framework/scaffolding, but there's no reason to confront them before you've written a few applications without, and hence are able to appreciate why they exist and what problems they do/don't solve. This mostly seems to be a problem for IO and Maybe. In particular, "State monad" and "Reader monad" don't have this problem, since their values have more widely used names like pairs/tuples and functions, respectively. Likewise, I've not seen this happen with other type classes, like "it returns a Maybe functor", or "I need to combine two List monoids".

daxfohl 10y ago

In my experience either IO absorbs everything but the most trivial trinkets that I wouldn't ever mess up anyway, or I go so far out of my way to avoid IO that it's near impossible to keep track of all the layers of abstraction. The first case adds nothing and the second case hurts more than it helps. That said, most of my work is "doing stuff", not data manipulation, so perhaps that's the difference. Also "OOP" for me is C#, which has plenty of FP features (though F# style records and `with` syntax are annoyingly missing); if I was comparing Haskell to Java 1.0 code then I could imagine seeing things differently.

boubiyeah 10y ago
Exactly. It doesn't document much. In any non trivial Elm program, 2/3 of your update fonctions are going to return Tasks. So what, nothing is pure? ok. imo, types shouldn't be used to compensate for the lack of separation of concerns (simple data manipulation VS IO)
runT1ME 10y ago
in my experience either IO absorbs everything but the most trivial trinkets that I wouldn't ever mess up anyway You mean you never mess up business logic? IO should only really be used when you need to be interacting with the world, IE, network calls, UI, etc.
- daxfohl 10y ago
  Interesting you ask, because honestly the answer is, not really. In the grand scheme of things, business logic isn't that difficult. Take some data in, process it, output it. And what Haskell provides over C#, an explicit separation of purity and impurity, isn't that great of a help. I design most of my logic to be pure anyway, and when it's not there's a reason for it. Forcing me to jump through hoops to handle those few cases of necessary impurity generally harms more than it helps. "Difficult" code is stuff that involves things like distributed transactions and whatnot. All that stuff has to be bundled in a big wad of IO anyway and so Haskell has nothing to help out with that in the first place (if there was a language that could, I'd be all over it). At least that's my experience. YMMV.