3 ms·

Most functional languages cannot do imperative things as smoothly as imperative languages, but there are very few functional languages that can't do them at all

Most functional languages cannot do imperative things as smoothly as imperative languages, but there are very few functional languages that can't do them at all. OCaml, Haskell, and their derivatives can all do precisely what you listed above just fine. It's just a tradeoff to make one kind of programming easier at the expense of another (through perhaps not a necessary tradeoff).

wyager 10y ago
> Most functional languages cannot do imperative things as smoothly as imperative languages I don't even buy this for most definitions of "imperative things". The only algorithms that I've ever found unwieldy in functional programming are heavily array-oriented algorithms like random shuffles. Almost everything else comes out more elegant.
- johncolanduoni 10y ago
  When I say "imperative things", I mean insisting on doing things in an imperative manner (for loops, mutation, etc.), not the problems themselves.
  - wyager 10y ago
    When transliterating code from distributed systems papers (uncomfortably imperative) to Haskell, I had an excellent experience with Lenses and the State monad. It allows you to reproduce imperative, mutable code in functional Haskell and without mutability. The semantics are also much more restricted (in a good way) than imperative code in a real imperative language. For example, you have to specify the entire state beforehand, which prevents you from falling for ultimately unproductive temptations like global variables. You can even do for loops if you want. http://hackage.haskell.org/package/base-4.9.0.0/docs/Data-Traversable.html#v:for http://hackage.haskell.org/package/base-4.9.0.0/docs/Data-Tr... for [1,2,3] $ \i -> do counter += i print i I wrote a bit about the experience here if you're interested. It was on HN a while back. http://yager.io/Distributed/Distributed.html http://yager.io/Distributed/Distributed.html
- Peaker 10y ago
  And even array-oriented algorithms can be quite nice, syntactically, if nice operators are defined for them[1]. But the FP community does not care that much about that kind of code, so nice operators are just not defined for them. [1]: http://augustss.blogspot.co.il/2007/08/programming-in-c-ummm-haskell-heres.html http://augustss.blogspot.co.il/2007/08/programming-in-c-ummm...

wyager 10y ago

> Most functional languages cannot do imperative things as smoothly as imperative languages I don't even buy this for most definitions of "imperative things". The only algorithms that I've ever found unwieldy in functional programming are heavily array-oriented algorithms like random shuffles. Almost everything else comes out more elegant.

johncolanduoni 10y ago
When I say "imperative things", I mean insisting on doing things in an imperative manner (for loops, mutation, etc.), not the problems themselves.
- wyager 10y ago
  When transliterating code from distributed systems papers (uncomfortably imperative) to Haskell, I had an excellent experience with Lenses and the State monad. It allows you to reproduce imperative, mutable code in functional Haskell and without mutability. The semantics are also much more restricted (in a good way) than imperative code in a real imperative language. For example, you have to specify the entire state beforehand, which prevents you from falling for ultimately unproductive temptations like global variables. You can even do for loops if you want. http://hackage.haskell.org/package/base-4.9.0.0/docs/Data-Traversable.html#v:for http://hackage.haskell.org/package/base-4.9.0.0/docs/Data-Tr... for [1,2,3] $ \i -> do counter += i print i I wrote a bit about the experience here if you're interested. It was on HN a while back. http://yager.io/Distributed/Distributed.html http://yager.io/Distributed/Distributed.html
Peaker 10y ago
And even array-oriented algorithms can be quite nice, syntactically, if nice operators are defined for them[1]. But the FP community does not care that much about that kind of code, so nice operators are just not defined for them. [1]: http://augustss.blogspot.co.il/2007/08/programming-in-c-ummm-haskell-heres.html http://augustss.blogspot.co.il/2007/08/programming-in-c-ummm...