On 5/3/05, Daniel Carrera <[EMAIL PROTECTED]> wrote: > Hi all, > > Again, I'm the new guy slowly learning this "fuctional programming" > thing. :-) > > I've been reading, and I'm really liking the elgance of Haskell, and FP > as a whole. But I wonder about the range of applicability. You see, one > of the things about FP is that there are no side-effects and the same > function on the same parameters always returns the same value. But any > program that interacts with the real world cannot meet those properties. > > The function ask_user_name() will not return the same value each time. > If write a chess program, the function get_user_move() will be different > each time. And every time you update the screen, you're having a > side-effect. > > So, I figure that to do these tasks you heed that "do ... <-" work > around. But that kills the whole point of using FP in the first place, > right? > > So, I'm tempted to conclude that FP is only applicable to situations > where user interaction is a small part of the program. For example, for > simulations. > > Now, I'm sure I'm not the first person to have this train of thought. > And I'm sure there is a good answer why I'm wrong. :-) I'm eager to hear > what that might be. >
Others have already touched most of it so I'll just summarized why I prefer Haskell even in cases where there's tons of IO. First of all, there's LESS stateful code. Code with state really is quite unintuitive (how often do you change the meaning of a name in real life?) so if most of your code is _guaranteed_ to be pure and free from state, then that's certainly better than having all of your code potentially tainted. Also in Haskell the IO computations are first class (unlike most imperative languages). So you can send computations to a function as a parameter, and write your own control structures (like for-loops for example) and it's just a lot easier to deal with in Haskell then it is in imperative languages since IO-computations are just haskell values and nothing "special". And finally, the impure code is separated clearly from the pure code. So you get an "imperative skin" which does interactions with the impure world outside, and a pure "functional core" which does the bulk of the real computations. /S -- Sebastian Sylvan +46(0)736-818655 UIN: 44640862 _______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe