3 ms·

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 i

by 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.
dualogy 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. I half-expected this in my Haskell static site generator real-world-learning-project-of-sorts (reading files, writing files, "calling some smarty-pants composed combinators in between", nah not really just functions all the way down.. and somehow such a simple tool grew out of all proportion soon enough with ever more powerful markup notations to support etc pp..) but was profoundly surprised just how little of the code-base ended up in the IO monadic context and how much logic ended up as purely functional modules. Pleasantly eye-opening! (Sure even the IO monad is "purely functional" at least for the programmer though not the final assembler, but y'know-what-I-mean..) Just an idle anecdote though
- daxfohl 10y ago
  That's an interesting anecdote. I'm curious to know though, did Haskell's advanced type system help out at all? Like the various not-quite-IO monads such as State, Reader, Writer? Or other instances of HKTs such as Functor or Applicative? Did it force you to think about the problem any differently? Or was the only real benefit just the assurance that you weren't accidentally doing IO/mutation unnecessarily?
codygman 10y ago
> In my experience either IO absorbs everything but the most trivial trinkets that I wouldn't ever mess up anyway, Almost all business logic is pure, and it can get pretty complex in my opinion.

by daxfohl 10y ago

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.

dualogy 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. I half-expected this in my Haskell static site generator real-world-learning-project-of-sorts (reading files, writing files, "calling some smarty-pants composed combinators in between", nah not really just functions all the way down.. and somehow such a simple tool grew out of all proportion soon enough with ever more powerful markup notations to support etc pp..) but was profoundly surprised just how little of the code-base ended up in the IO monadic context and how much logic ended up as purely functional modules. Pleasantly eye-opening! (Sure even the IO monad is "purely functional" at least for the programmer though not the final assembler, but y'know-what-I-mean..) Just an idle anecdote though

daxfohl 10y ago
That's an interesting anecdote. I'm curious to know though, did Haskell's advanced type system help out at all? Like the various not-quite-IO monads such as State, Reader, Writer? Or other instances of HKTs such as Functor or Applicative? Did it force you to think about the problem any differently? Or was the only real benefit just the assurance that you weren't accidentally doing IO/mutation unnecessarily?

codygman 10y ago

> In my experience either IO absorbs everything but the most trivial trinkets that I wouldn't ever mess up anyway, Almost all business logic is pure, and it can get pretty complex in my opinion.