5 ms·

> Haskell makes your functions pure by default. You have to change the type signature if you want to do IO The author seems to be conflating IO and side effect

by laureny 14y ago

> Haskell makes your functions pure by default. You have to change the type signature if you want to do IO The author seems to be conflating IO and side effects. IO is just one of the many ways that side effects can occur. > Purity also means you can't read or write global variables, that's just another type of IO. Er... what? No, not at all. Reading global variables is not side effects, much less IO. Writing global variables is side effects, but has nothing to do with IO. > Functions that do IO are difficult or impossible to test. Absolutely not, IO functions are not harder to test than regular ones. Is your function creating a file? Start your test, assert the file doesn't exist, call your function, assert your file exists. Done. > I now put all my IO in top-level functions that are called directly from main This is great for homework, but in the real life, IO needs to be performed throughout your entire application, and unsafePerformIO is just not an option. You have to use iteratees for this kind of operation, which adds a pretty thick layer of complexity to your code base. > boo :: Map Integer String -> String -> Integer This syntax is clean but it doesn't tell me anything that def boo(map: Map[Integer, String], key: String) : Integer doesn't tell me. > The point is, you can't confidently reason about a function from its signature if IO is involved. Sure, you can: the mention of IO tells me this function operates within the IO monad, so I know a lot of operations and laws that apply to it. Haskell is a fantastic language but this article is doing a very poor job at explaining why. I suspect its author has only recently started using Haskell and would have been better advised to wait a bit before sharing his enthusiasm.

fusiongyro 14y ago
Global variables certainly create opportunities for side-effects. The author may be throwing everything into one big pot and labeling it I/O, but they're right that you can't sneak a global variable access into a function without changing the function's type. That's a valid point even if it's poorly worded. > This is great for homework, but in the real life, IO needs to be performed throughout your entire application My experience has been that I could get away with pushing I/O out to the fringes of the app and make 80-90% of the code pure. But everybody lives in a different "real life" and it's not unlikely that the kinds of things I do on the side for fun just don't require it. I fully concur with the rest of your remarks.
dbaupp 14y ago
> > Functions that do IO are difficult or impossible to test. > Absolutely not, IO functions are not harder to test than regular ones. Is your function creating a file? Start your test, assert the file doesn't exist, call your function, assert your file exists. Done. They are harder to test (although definitely not impossible). What if your function does a network request, and the result is highly dependent on latency etc, sure you can mock an endpoint that responds with the various properties desired, but it's much harder than just using Quickcheck or HUnit or one of the other testing libraries.
tome 14y ago
I'm not sure if it's due to a misunderstanding, but many of your comments seem to be incorrect or nonsequiturs. > > Haskell makes your functions pure by default. You have to change the type signature if you want to do IO > The author seems to be conflating IO and side effects. IO is just one of the many ways that side effects can occur. Indeed, but that does not refute the OP's statement. > > Functions that do IO are difficult or impossible to test. > Is your function creating a file? Start your test, assert the file doesn't exist, call your function, assert your file exists. Done. Right, and (in my opinion) that is more difficult than testing something that doesn't create a file. > > boo :: Map Integer String -> String -> Integer > This syntax is clean but it doesn't tell me anything that > def boo(map: Map[Integer, String], key: String) : Integer > doesn't tell me. Indeed, but again that does not refute the OP's statement which was simply that the syntax is clean. > > The point is, you can't confidently reason about a function from its signature if IO is involved. > Sure, you can: the mention of IO tells me this function operates within the IO monad, so I know a lot of operations and laws that apply to it. You do? Please tell me a law that applies to IO.
- laureny 14y ago
  > You do? Please tell me a law that applies to IO. How about three? Right identity, left identity and associativity. That's for the laws. For the properties, IO is a monad so I can compose any value in the IO monad with other monads (Maybe, ST, etc...).
  - dllthomas 14y ago
    There are certainly laws as to what goes on when you do various things with IO values. The relevant point, though, was that access to IO means there are few (any?) laws restricting what is actually going on when that integer is generated. Actually, I kind of wish IO was split up a bit... I have been meaning to play with rolling some typeclasses (with an IO instance and a testing instance) that wrap up IO of various types, so I define my functions in terms of these and spot what kind of IO various functions might do - I'm not yet sure how much of a win it will be, but it seems like something to explore.
gracenotes 14y ago
About the difference between the signatures. Well, one is in Haskell and one is in an imperative language. I think there's a significant software-engineering-philosophical difference, though. Concatenative programming languages are kinda based on this same philosophy. When you call boo function in Haskell, you have the power to create the "universe" which is both necessary and sufficient for the function to perform some self-contained computation. When enough of these computations are composed and nested together, you can really see how data flows through some logical procedure, possibly one with lots of essential complexity. On the other hand, when I look at the same signature translated into Java, for all I know it could be the 4th function call in a stateful 8-function-long set of functions you always have to call in order, except you don't have to call the 6th function if you pass true to the 2nd function. Easy enough, right? The fewer combinations of arbitrary state are allowed to determine the behavior of your program, the fewer unanticipated scenarios arise. I think this is a good software engineering principle. The corollary that I think Haskell really brings home when it comes to designing programs is that it's better to change the way data flows in one small section than to add a little more state somewhere and handwave away state combinations which you think are impossible. This idea applies in both Haskell and Java.
mercurial 14y ago
> Absolutely not, IO functions are not harder to test than regular ones. Is your function creating a file? Start your test, assert the file doesn't exist, call your function, assert your file exists. Done. There are a lot of things you're not testing for. Permission issues, etc. Besides, you have -plenty of functions doing IO on databases, or doing parallel operations. That's definitely a pain to test. > > boo :: Map Integer String -> String -> Integer > This syntax is clean but it doesn't tell me anything that > def boo(map: Map[Integer, String], key: String) : Integer > doesn't tell me It tells you it's not doing IO. Besides, what about this: def boo (foo: Some Obj): void What does this do? Write to a file? Change a field? I don't know.
Jare 14y ago
> Absolutely not, IO functions are not harder to test than regular ones Testing IO involves systems and context that are external to both your code and your tests. This makes them more complex to set up and more error prone.
enigmo 14y ago
> This is great for homework, but in the real life, IO needs to be performed throughout your entire application, and unsafePerformIO is just not an option. Large Haskell applications benefit from different overall design than the typical C++ or Java app. Our very large Haskell codebase doesn't use IO much nowadays, and as we go back through to refactor older code it diminishes even more.

by laureny 14y ago

fusiongyro 14y ago

Global variables certainly create opportunities for side-effects. The author may be throwing everything into one big pot and labeling it I/O, but they're right that you can't sneak a global variable access into a function without changing the function's type. That's a valid point even if it's poorly worded. > This is great for homework, but in the real life, IO needs to be performed throughout your entire application My experience has been that I could get away with pushing I/O out to the fringes of the app and make 80-90% of the code pure. But everybody lives in a different "real life" and it's not unlikely that the kinds of things I do on the side for fun just don't require it. I fully concur with the rest of your remarks.

dbaupp 14y ago

> > Functions that do IO are difficult or impossible to test. > Absolutely not, IO functions are not harder to test than regular ones. Is your function creating a file? Start your test, assert the file doesn't exist, call your function, assert your file exists. Done. They are harder to test (although definitely not impossible). What if your function does a network request, and the result is highly dependent on latency etc, sure you can mock an endpoint that responds with the various properties desired, but it's much harder than just using Quickcheck or HUnit or one of the other testing libraries.

tome 14y ago

I'm not sure if it's due to a misunderstanding, but many of your comments seem to be incorrect or nonsequiturs. > > Haskell makes your functions pure by default. You have to change the type signature if you want to do IO > The author seems to be conflating IO and side effects. IO is just one of the many ways that side effects can occur. Indeed, but that does not refute the OP's statement. > > Functions that do IO are difficult or impossible to test. > Is your function creating a file? Start your test, assert the file doesn't exist, call your function, assert your file exists. Done. Right, and (in my opinion) that is more difficult than testing something that doesn't create a file. > > boo :: Map Integer String -> String -> Integer > This syntax is clean but it doesn't tell me anything that > def boo(map: Map[Integer, String], key: String) : Integer > doesn't tell me. Indeed, but again that does not refute the OP's statement which was simply that the syntax is clean. > > The point is, you can't confidently reason about a function from its signature if IO is involved. > Sure, you can: the mention of IO tells me this function operates within the IO monad, so I know a lot of operations and laws that apply to it. You do? Please tell me a law that applies to IO.

laureny 14y ago
> You do? Please tell me a law that applies to IO. How about three? Right identity, left identity and associativity. That's for the laws. For the properties, IO is a monad so I can compose any value in the IO monad with other monads (Maybe, ST, etc...).
- dllthomas 14y ago
  There are certainly laws as to what goes on when you do various things with IO values. The relevant point, though, was that access to IO means there are few (any?) laws restricting what is actually going on when that integer is generated. Actually, I kind of wish IO was split up a bit... I have been meaning to play with rolling some typeclasses (with an IO instance and a testing instance) that wrap up IO of various types, so I define my functions in terms of these and spot what kind of IO various functions might do - I'm not yet sure how much of a win it will be, but it seems like something to explore.

gracenotes 14y ago

About the difference between the signatures. Well, one is in Haskell and one is in an imperative language. I think there's a significant software-engineering-philosophical difference, though. Concatenative programming languages are kinda based on this same philosophy. When you call boo function in Haskell, you have the power to create the "universe" which is both necessary and sufficient for the function to perform some self-contained computation. When enough of these computations are composed and nested together, you can really see how data flows through some logical procedure, possibly one with lots of essential complexity. On the other hand, when I look at the same signature translated into Java, for all I know it could be the 4th function call in a stateful 8-function-long set of functions you always have to call in order, except you don't have to call the 6th function if you pass true to the 2nd function. Easy enough, right? The fewer combinations of arbitrary state are allowed to determine the behavior of your program, the fewer unanticipated scenarios arise. I think this is a good software engineering principle. The corollary that I think Haskell really brings home when it comes to designing programs is that it's better to change the way data flows in one small section than to add a little more state somewhere and handwave away state combinations which you think are impossible. This idea applies in both Haskell and Java.

mercurial 14y ago

> Absolutely not, IO functions are not harder to test than regular ones. Is your function creating a file? Start your test, assert the file doesn't exist, call your function, assert your file exists. Done. There are a lot of things you're not testing for. Permission issues, etc. Besides, you have -plenty of functions doing IO on databases, or doing parallel operations. That's definitely a pain to test. > > boo :: Map Integer String -> String -> Integer > This syntax is clean but it doesn't tell me anything that > def boo(map: Map[Integer, String], key: String) : Integer > doesn't tell me It tells you it's not doing IO. Besides, what about this: def boo (foo: Some Obj): void What does this do? Write to a file? Change a field? I don't know.

Jare 14y ago

> Absolutely not, IO functions are not harder to test than regular ones Testing IO involves systems and context that are external to both your code and your tests. This makes them more complex to set up and more error prone.

enigmo 14y ago

> This is great for homework, but in the real life, IO needs to be performed throughout your entire application, and unsafePerformIO is just not an option. Large Haskell applications benefit from different overall design than the typical C++ or Java app. Our very large Haskell codebase doesn't use IO much nowadays, and as we go back through to refactor older code it diminishes even more.