5 ms·

"...especially since a large amount of programming is all about state and side effects." Haskell provides lots of tools for reasoning about and managing si

"...especially since a large amount of programming is all about state and side effects." Haskell provides lots of tools for reasoning about and managing side effects; it just doesn't (and, indeed, can't) allow them arbitrarily. In terms of interacting with the outside world—e.g. doing GUI work or interacting with a database—you usually have an effectful 'core' that manages side effects while a slew of pure helper functions operate on the data derived from those side effects. (This is good style in non-functional languages, as well, as it is a kind of separation of concerns.) Other functional languages are far less stringent about side effects, so both the ML family and Scheme allow state modification and side effects, although the functional style is preferred when possible. In terms of writing algorithms, you'd be amazed at how little needs to be expressed in terms of manipulation of state. It feels natural to write stateful functions if you've spent large amounts of time programming in stateful languages, but that has more to do with your familiarity than a property inherent in the problem. If you were immersed in Scheme, you might say, "...a large amount of programming is about function definition and application", just like if you were immersed in Forth, you might say, "...a large amount of programming is about stack manipulation." You certainly could use e.g. Scheme as language for general-purpose programming, and I suspect the problems that would arise would not be problems with functional programming, but rather an unfortunate lack of modern libraries for things like Unicode handling.

jiggy2011 15y ago
I agree that you can vastly reduce state is a large number of cases. It just seems strange to write in a purely functional language when there are many languages out there that combine functional style with the ability to write in an imperative way. I can quite happily write programs in python without any real side effects, indeed as you suggest I usually try and divide my functions between those which have side effects and those which don't. So what advantage would I get for picking haskell instead? Other than marginally shorter programs? FP seems to be picking up steam recently, is this just because we are doing more computation in the cloud and CPUs are getting more cores rather than more raw clock speed or am I missing something?
- nightski 15y ago
  The advantage is that you can reason about the correctness of code. Sure, if you write an entire code base depending on its size you may be able to reason about all the side effects in your head. But when moving to a larger project, or one developed by a team - all bets are off. It is really important to have the effects embedded in the type system. Even with a large test suite. On top of this, having professionally written C/C++ for years in the embedded systems space I can say that Monads for IO is not awkward. In fact, it feels far more powerful because you are not limited to the awful semicolon operator for chaining effects. Lastly FP != slower (even on single core). I agree Haskell can be hard to reason about performance wise at times due to choosing lazy by default. However, have you ever heard of Sisal? Many strict by default FP languages are quite fast, however they sacrifice purity. But to be honest, with experience Haskell can be damn fast also.
  - jiggy2011 15y ago
    Interesting, my question is more though why now? Since LISP has been around for a very long time and FP has had very little mainstream interest until the last year or 2.
    - nickik 15y ago
      Good question. I think its a couple of diffrent things. 1. Java is not really evolving, people are frustrated 2. Multicore is difficulte and FP claim they are better at it. 3. Complexety of ever bigger codebases 4. Java Script not longer the worst language in the world, people start to understand whats powerful about it and want to know what more is possible.
      - danieldk 15y ago
        Additionally, I think that Haskell really has to offer something over most other FP languages. Many features of dynamic impure FP languages have already been ported to languages such as Ruby or Python. What Haskell provides over, say Lisp, is exceptionally strong typing and isolation of side-effects. This is a quality that cannot be ported to mainstream languages easily. So, why didn't Haskell become more popular earlier? I think that's simple: the GHC compilers has improved tremendously over the past years, Hackage has grown considerably, and there are now more books oriented at practical programming.

jiggy2011 15y ago

I agree that you can vastly reduce state is a large number of cases. It just seems strange to write in a purely functional language when there are many languages out there that combine functional style with the ability to write in an imperative way. I can quite happily write programs in python without any real side effects, indeed as you suggest I usually try and divide my functions between those which have side effects and those which don't. So what advantage would I get for picking haskell instead? Other than marginally shorter programs? FP seems to be picking up steam recently, is this just because we are doing more computation in the cloud and CPUs are getting more cores rather than more raw clock speed or am I missing something?

nightski 15y ago
The advantage is that you can reason about the correctness of code. Sure, if you write an entire code base depending on its size you may be able to reason about all the side effects in your head. But when moving to a larger project, or one developed by a team - all bets are off. It is really important to have the effects embedded in the type system. Even with a large test suite. On top of this, having professionally written C/C++ for years in the embedded systems space I can say that Monads for IO is not awkward. In fact, it feels far more powerful because you are not limited to the awful semicolon operator for chaining effects. Lastly FP != slower (even on single core). I agree Haskell can be hard to reason about performance wise at times due to choosing lazy by default. However, have you ever heard of Sisal? Many strict by default FP languages are quite fast, however they sacrifice purity. But to be honest, with experience Haskell can be damn fast also.
- jiggy2011 15y ago
  Interesting, my question is more though why now? Since LISP has been around for a very long time and FP has had very little mainstream interest until the last year or 2.
  - nickik 15y ago
    Good question. I think its a couple of diffrent things. 1. Java is not really evolving, people are frustrated 2. Multicore is difficulte and FP claim they are better at it. 3. Complexety of ever bigger codebases 4. Java Script not longer the worst language in the world, people start to understand whats powerful about it and want to know what more is possible.
    - danieldk 15y ago
      Additionally, I think that Haskell really has to offer something over most other FP languages. Many features of dynamic impure FP languages have already been ported to languages such as Ruby or Python. What Haskell provides over, say Lisp, is exceptionally strong typing and isolation of side-effects. This is a quality that cannot be ported to mainstream languages easily. So, why didn't Haskell become more popular earlier? I think that's simple: the GHC compilers has improved tremendously over the past years, Hackage has grown considerably, and there are now more books oriented at practical programming.