5 ms·

Functional languages are a red herring. If you actually want to do something you still have to have side effects, and that's when all that Haskell-ish beauty g

Functional languages are a red herring. If you actually want to do something you still have to have side effects, and that's when all that Haskell-ish beauty goes out the window. It is still absolutely worth it to learn functional programming, it will change the way you think, it will make a better programmer in non functional languages, but it won't solve the problems of side effects.

ricky_clarkson 18y ago
You mean that no Haskell programs can do I/O? Given that I've written Haskell programs that do I/O, I'd guess you're wrong.
- smanek 18y ago
  He never said that. He just said the "Haskell-ish beauty goes out the window," which is arguably true. In my (limited) experience, Haskell code to do I/O (i.e., Monads) isn't a pretty or elegant as purely functional Haskell code. A lot of Haskell's useful tricks (i.e., its beauty like the ridiculously strong type system or lazy evaluation) don't work on code with side effects.
  - crabapple 18y ago
    Haskell code to do I/O (i.e., Monads) isn't a pretty or elegant as purely functional Haskell code are you using "do" notation? ITS JUST SUGAR. you can use >>=, >>, return etc directly and voila, Monads are as functional as the rest of haskell
gaius 18y ago
Purely functional languages are a red herring. So-called impure languages however like OCaml can be enormously productive for certain classes of problem. As always, it's a matter of the right tool for the job. Too many people these days only have one tool, then every problem looks like your face.
- davidw 18y ago
  Time to ditch the 'tools' metaphor, IMO: http://journal.dedasys.com/2007/12/12/programming-languages-are-not-like-hand-tools http://journal.dedasys.com/2007/12/12/programming-languages-... Most programmers, realistically, don't use that many languages at any given time, and if they could use fewer, they probably would. The more territory a language covers, the better off it is... well, at least as long as it can do so relatively well.
- crabapple 18y ago
  what can ocaml do that haskell can't? indeed these days its the other way around. the volume of submissions on hackage is far in excess of anything you see in ocaml land. on a language level they are equally capable, on a library level, haskell wins.
- jganetsk 18y ago
  Agreed. Languages like OCaml are actually higher-order imperative languages. They have a very rich, expressive system of "values". A value can be a function value, partially un-curried, and closed over arbitrary data. They can also be data values but can be arbitrarily complex. How many languages let you say: let tree = Node (Node (Leaf 3) (Leaf 4)) (Node (Leaf 7) (Leaf 8)) This value is constant, just like an integer or string constant in many languages. In other words, the right-hand side can be arbitrarily complex. And this data structure gets passed around in a very lightweight manner (by reference, not by copying). The Java notion that values are either primitive, or objects... is limiting.
  - deleted 18y ago
    [deleted]
crabapple 18y ago
??? the entire point of Monads is to put stateful, side-effect oriented code on the same level as pure functional code. so actually none of the "haskellish beauty" goes out the window with side-effects
daniel_yokomizo 18y ago
1. Most lines of code don't require side-effects, the Haskell way just asks you to structure your program in pure parts and side effecting parts (usually 90/10). 2. Also it's easy to define your own forms of side effects and parameterize your code on them (so I write my code to depend on any monad m that offers references and the code runs using IO, ST or STM), not being constrained by whatever choices the language designers gave you initially 3. Monads (and arrows and other abstractions that can model side-effects) are beautiful by themselves. It's one of the most elegant ways to express, compose and restrict side-effects. In most languages there's no easy way to create different combinators to deal with side-effects, but in Haskell 'do', ';' and '<-' are only pieces of notation, the real meat is '>>=' and 'return' and whatever combinators you build upon these. 4. The Haskell way to deal with side effects is to use a pure language to build a side-effecting program. Instead of writing down the program you abstract its parts and use combinators to mix them. 'IO' is a value that can be manipulated not an action that was already executed.

ricky_clarkson 18y ago

You mean that no Haskell programs can do I/O? Given that I've written Haskell programs that do I/O, I'd guess you're wrong.

smanek 18y ago
He never said that. He just said the "Haskell-ish beauty goes out the window," which is arguably true. In my (limited) experience, Haskell code to do I/O (i.e., Monads) isn't a pretty or elegant as purely functional Haskell code. A lot of Haskell's useful tricks (i.e., its beauty like the ridiculously strong type system or lazy evaluation) don't work on code with side effects.
- crabapple 18y ago
  Haskell code to do I/O (i.e., Monads) isn't a pretty or elegant as purely functional Haskell code are you using "do" notation? ITS JUST SUGAR. you can use >>=, >>, return etc directly and voila, Monads are as functional as the rest of haskell

gaius 18y ago

Purely functional languages are a red herring. So-called impure languages however like OCaml can be enormously productive for certain classes of problem. As always, it's a matter of the right tool for the job. Too many people these days only have one tool, then every problem looks like your face.

davidw 18y ago
Time to ditch the 'tools' metaphor, IMO: http://journal.dedasys.com/2007/12/12/programming-languages-are-not-like-hand-tools http://journal.dedasys.com/2007/12/12/programming-languages-... Most programmers, realistically, don't use that many languages at any given time, and if they could use fewer, they probably would. The more territory a language covers, the better off it is... well, at least as long as it can do so relatively well.
crabapple 18y ago
what can ocaml do that haskell can't? indeed these days its the other way around. the volume of submissions on hackage is far in excess of anything you see in ocaml land. on a language level they are equally capable, on a library level, haskell wins.
jganetsk 18y ago
Agreed. Languages like OCaml are actually higher-order imperative languages. They have a very rich, expressive system of "values". A value can be a function value, partially un-curried, and closed over arbitrary data. They can also be data values but can be arbitrarily complex. How many languages let you say: let tree = Node (Node (Leaf 3) (Leaf 4)) (Node (Leaf 7) (Leaf 8)) This value is constant, just like an integer or string constant in many languages. In other words, the right-hand side can be arbitrarily complex. And this data structure gets passed around in a very lightweight manner (by reference, not by copying). The Java notion that values are either primitive, or objects... is limiting.
- deleted 18y ago
  [deleted]

crabapple 18y ago

??? the entire point of Monads is to put stateful, side-effect oriented code on the same level as pure functional code. so actually none of the "haskellish beauty" goes out the window with side-effects

daniel_yokomizo 18y ago

1. Most lines of code don't require side-effects, the Haskell way just asks you to structure your program in pure parts and side effecting parts (usually 90/10). 2. Also it's easy to define your own forms of side effects and parameterize your code on them (so I write my code to depend on any monad m that offers references and the code runs using IO, ST or STM), not being constrained by whatever choices the language designers gave you initially 3. Monads (and arrows and other abstractions that can model side-effects) are beautiful by themselves. It's one of the most elegant ways to express, compose and restrict side-effects. In most languages there's no easy way to create different combinators to deal with side-effects, but in Haskell 'do', ';' and '<-' are only pieces of notation, the real meat is '>>=' and 'return' and whatever combinators you build upon these. 4. The Haskell way to deal with side effects is to use a pure language to build a side-effecting program. Instead of writing down the program you abstract its parts and use combinators to mix them. 'IO' is a value that can be manipulated not an action that was already executed.