6 ms·

Rust still allows imperative programming whereas Haskell doesn't. This makes a big difference. Rust is closer to Alan Turing than it is to Alonzo Church.

wyager 9y ago
Haskell allows you to recreate standard imperative semantics purely (with the State monad, plus lenses for familiar syntax), or to use actual stateful imperative mutability ("purely" via ST or impurely via IO).
danidiaz 9y ago
There was a recent post about "imperative Haskell": http://vaibhavsagar.com/blog/2017/05/29/imperative-haskell/ http://vaibhavsagar.com/blog/2017/05/29/imperative-haskell/ The code in this other post about implementing string distance metrics is also quite imperative: https://markkarpov.com/post/migrating-text-metrics.html https://markkarpov.com/post/migrating-text-metrics.html
xedrac 9y ago
Haskell definitely allows imperative programming, it's just not particularly good at it.
- eklavya 9y ago
  What is it lacking for imperative programming? I find it to be immensely good at it!
  - pathsjs 9y ago
    Don't know... mutable collections? A way to make sure things are evaluated without writing seq every other line?
    - Tarean 9y ago
      Mutable hashtables: https://hackage.haskell.org/package/hashtables https://hackage.haskell.org/package/hashtables Mutable arrays: https://hackage.haskell.org/package/vector-0.12.0.1/docs/Data-Vector-Mutable.html https://hackage.haskell.org/package/vector-0.12.0.1/docs/Dat... Strict by default: Put {#- Language Strict #-} at the top of files where necessary but usually you'd just use bangpatterns and unbox-strict-fields.
      - pathsjs 9y ago
        Well, these are mutable, but only in the ST or IO monad - which is a guarantee, but at the same time it is not quite the same thing. You cannot just accumulate state by mutating some stuff, then in a separate part of the program mutate it again. Which is intentional, of course, but quite opposite to the imperative mindset. About {#- Language Strict #-}, thank you - I was not aware of it. I think the first example in this post https://markkarpov.com/post/migrating-text-metrics.html https://markkarpov.com/post/migrating-text-metrics.html makes it clear that, while one can program in imperative style, it is not at all natural, and it is going to introduce as much boilerplate as, say, trying to program in functional style in Java 6
        kqr 9y ago
        Well, if you want to do full imperative programming with warts and all, you'll probably want to stick to the IO monad for your entire program anyway. You just have to be aware that you're actively handicapping your compiler by choosing to do full imperative programming. (In most other languages, the compilers come handicapped out of the box...) I think the first example in that post is a bit unfair. The Haskell code is unusually complicated because it avoids a complicated problem that exists in the C code. (Which is that 16-bit encodings can't cover all of UCS-4 with fixed character widths.) Besides, I don't understand why they are making such a complicated solution. In this comparison [1], the first example in that post is the "target". The best performing solution is... you guessed it: foldZip a b = List.foldl' (\r (cha, chb) -> if cha /= chb then r+1 else r) 0 (Text.zip a b) And a pet peeve: the way you say "only in the ST monad" is a funny rhetoric device. You make it sound like everyone agrees it's a bad thing to isolate mutation to local regions. Here's the thing: it's not. And the way you can integrate local mutation in your application with the ST monad is fantastic. By just typing "ST" a few extra times you get local mutation exactly where you want to, and nowhere you don't want it! [1]: http://i.xkqr.org/scrot_20170615032548.png http://i.xkqr.org/scrot_20170615032548.png
  - cousin_it 9y ago
    I tried implementing some simple imperative algorithms (like union-find) and found the Haskell code very noisy. For example, "var x = f(y)" in an imperative language might translate to "let x = f y" or "do x <- f y" in a Haskell do block, and the wrong variant won't compile. There's no general purpose idiom you can use to replace all loops, only tons of special purpose HOFs you must memorize. Writing code that mixes different types of side-effecting calls is combinator hell. And so on. Usually an imperative algorithm will be much clearer in an imperative language than in Haskell, and easier to get right on the first try.
    - Retra 9y ago
      Just because it doesn't translate 1-to-1 from another imperative language doesn't mean it isn't imperative itself. Haskell is not in the C family. It's not going to accept straight translations from C, but C doesn't monopolize imperativeness either.
      - deleted 9y ago
        [deleted]
    - vmchale 9y ago
      >There's no general purpose idiom you can use to replace all loops, only tons of special purpose HOFs you must memorize. Ah, but there is! Recursion schemes. >Usually an imperative algorithm will be much clearer in an imperative language than in Haskell, and easier to get right on the first try. Not sure what an "imperative algorithm" is, but I agree there are tasks better suited to imperative languages.
    - kqr 9y ago
      > There's no general purpose idiom you can use to replace all loops, only tons of special purpose HOFs you must memorize. Well, yes, there is: general recursion. You can recreate any loop with plain old recursion. But stating that as a problem is a little like coming to Java and saying that "there's no general purpose idiom you can use to replace goto, only tons of special semantic branching constructs you must memorize." Sure, a valid complaint if you've been forced to only use goto in your life, but not a reflection on good programming practise.
- cannam 9y ago
  "Haskell is, in my view, the world’s best imperative programming language, and second-best functional language" - Robert Harper (https://existentialtype.wordpress.com/2011/04/09/persistence-of-memory/ https://existentialtype.wordpress.com/2011/04/09/persistence...)

wyager 9y ago

Haskell allows you to recreate standard imperative semantics purely (with the State monad, plus lenses for familiar syntax), or to use actual stateful imperative mutability ("purely" via ST or impurely via IO).

danidiaz 9y ago

There was a recent post about "imperative Haskell": http://vaibhavsagar.com/blog/2017/05/29/imperative-haskell/ http://vaibhavsagar.com/blog/2017/05/29/imperative-haskell/ The code in this other post about implementing string distance metrics is also quite imperative: https://markkarpov.com/post/migrating-text-metrics.html https://markkarpov.com/post/migrating-text-metrics.html

xedrac 9y ago

Haskell definitely allows imperative programming, it's just not particularly good at it.

eklavya 9y ago
What is it lacking for imperative programming? I find it to be immensely good at it!
- pathsjs 9y ago
  Don't know... mutable collections? A way to make sure things are evaluated without writing seq every other line?
  - Tarean 9y ago
    Mutable hashtables: https://hackage.haskell.org/package/hashtables https://hackage.haskell.org/package/hashtables Mutable arrays: https://hackage.haskell.org/package/vector-0.12.0.1/docs/Data-Vector-Mutable.html https://hackage.haskell.org/package/vector-0.12.0.1/docs/Dat... Strict by default: Put {#- Language Strict #-} at the top of files where necessary but usually you'd just use bangpatterns and unbox-strict-fields.
    - pathsjs 9y ago
      Well, these are mutable, but only in the ST or IO monad - which is a guarantee, but at the same time it is not quite the same thing. You cannot just accumulate state by mutating some stuff, then in a separate part of the program mutate it again. Which is intentional, of course, but quite opposite to the imperative mindset. About {#- Language Strict #-}, thank you - I was not aware of it. I think the first example in this post https://markkarpov.com/post/migrating-text-metrics.html https://markkarpov.com/post/migrating-text-metrics.html makes it clear that, while one can program in imperative style, it is not at all natural, and it is going to introduce as much boilerplate as, say, trying to program in functional style in Java 6
      - kqr 9y ago
        Well, if you want to do full imperative programming with warts and all, you'll probably want to stick to the IO monad for your entire program anyway. You just have to be aware that you're actively handicapping your compiler by choosing to do full imperative programming. (In most other languages, the compilers come handicapped out of the box...) I think the first example in that post is a bit unfair. The Haskell code is unusually complicated because it avoids a complicated problem that exists in the C code. (Which is that 16-bit encodings can't cover all of UCS-4 with fixed character widths.) Besides, I don't understand why they are making such a complicated solution. In this comparison [1], the first example in that post is the "target". The best performing solution is... you guessed it: foldZip a b = List.foldl' (\r (cha, chb) -> if cha /= chb then r+1 else r) 0 (Text.zip a b) And a pet peeve: the way you say "only in the ST monad" is a funny rhetoric device. You make it sound like everyone agrees it's a bad thing to isolate mutation to local regions. Here's the thing: it's not. And the way you can integrate local mutation in your application with the ST monad is fantastic. By just typing "ST" a few extra times you get local mutation exactly where you want to, and nowhere you don't want it! [1]: http://i.xkqr.org/scrot_20170615032548.png http://i.xkqr.org/scrot_20170615032548.png
- cousin_it 9y ago
  I tried implementing some simple imperative algorithms (like union-find) and found the Haskell code very noisy. For example, "var x = f(y)" in an imperative language might translate to "let x = f y" or "do x <- f y" in a Haskell do block, and the wrong variant won't compile. There's no general purpose idiom you can use to replace all loops, only tons of special purpose HOFs you must memorize. Writing code that mixes different types of side-effecting calls is combinator hell. And so on. Usually an imperative algorithm will be much clearer in an imperative language than in Haskell, and easier to get right on the first try.
  - Retra 9y ago
    Just because it doesn't translate 1-to-1 from another imperative language doesn't mean it isn't imperative itself. Haskell is not in the C family. It's not going to accept straight translations from C, but C doesn't monopolize imperativeness either.
    - deleted 9y ago
      [deleted]
  - vmchale 9y ago
    >There's no general purpose idiom you can use to replace all loops, only tons of special purpose HOFs you must memorize. Ah, but there is! Recursion schemes. >Usually an imperative algorithm will be much clearer in an imperative language than in Haskell, and easier to get right on the first try. Not sure what an "imperative algorithm" is, but I agree there are tasks better suited to imperative languages.
  - kqr 9y ago
    > There's no general purpose idiom you can use to replace all loops, only tons of special purpose HOFs you must memorize. Well, yes, there is: general recursion. You can recreate any loop with plain old recursion. But stating that as a problem is a little like coming to Java and saying that "there's no general purpose idiom you can use to replace goto, only tons of special semantic branching constructs you must memorize." Sure, a valid complaint if you've been forced to only use goto in your life, but not a reflection on good programming practise.
cannam 9y ago
"Haskell is, in my view, the world’s best imperative programming language, and second-best functional language" - Robert Harper (https://existentialtype.wordpress.com/2011/04/09/persistence-of-memory/ https://existentialtype.wordpress.com/2011/04/09/persistence...)