6 ms·

So the first example, in C#, (1) uses logging in the middle of an otherwise pure function, (2) is criticized for the unpredictability of a bounded/well-define

by comex 10y ago

So the first example, in C#, (1) uses logging in the middle of an otherwise pure function, (2) is criticized for the unpredictability of a bounded/well-defined instance of laziness, namely iteration. The author's proposed solution is Haskell, which (1) makes it difficult to add logging at all to pure code without refactoring to add monads, unless you subvert the type system by using functions like 'trace'... (2) ...in which case behavior will be significantly less predictable than C# due to Haskell's pervasive laziness - something which also comes up in other situations, like reasoning about performance/memory use. I find it hard to take this article seriously.

moron4hire 10y ago
There is also the empirical evidence that "mostly functional" C# has successfully been used in perhaps thousands of others around the world. It's hard to take "it doesn't work" seriously when it has clearly worked for me and many others.
- continuational 10y ago
  How do you do functional programming in C#? It has lambda functions, but it lacks sum types, pattern matching and immutable collections (they exist, but it's not much use if none of the libraries use them).
  - kwhitefoot 10y ago
    None of these things are essential for functional programming in the sense of pure functions free of side effects.
    - continuational 10y ago
      In that sense, no programming language feature is essential; you can do pure functions in assembler.
catnaroek 10y ago
Yes, Haskell is a very flawed language, however: (0) The fact you need to modify value-level code to put it in a monadic context is a defect of Haskell's design, not of monads per se. See: http://www.cs.umd.edu/~mwh/papers/monadic.pdf http://www.cs.umd.edu/~mwh/papers/monadic.pdf (1) Laziness has nothing to do with being purely functional.
- comex 10y ago
  I'm not even trying to criticize Haskell, really; Haskell has plenty of great attributes (though the paper you linked is interesting). I just think this particular argument advocating for it is poorly constructed, basically pointing to a weakness as if it were a strength.
- klodolph 10y ago
  On the second point, laziness and purity are very closely related. See http://haskell.cs.yale.edu/wp-content/uploads/2011/02/history.pdf http://haskell.cs.yale.edu/wp-content/uploads/2011/02/histor... (§3.2) See http://stackoverflow.com/questions/31477074/how-lazy-evaluation-forced-haskell-to-be-pure http://stackoverflow.com/questions/31477074/how-lazy-evaluat...
  - catnaroek 10y ago
    Maybe for social reasons. From a purely technical standpoint: (0) You can have a pure strict language just fine. You can also have a lazy impure language just fine. (1) Nontermination is an effect anyway, so Haskell isn't pure unless you wish nontermination out of existence. (Which the Haskell community is in the habit of doing.)
    - klodolph 10y ago
      I think you may have glossed over that paper I linked. No, you can't have a non-strict impure language just fine, the semantics would make it too difficult to reason about side effects. I am not aware of any such language. According to Wikipedia, Miranda and Clean are also non-strict but they are also purely functional. https://en.wikipedia.org/wiki/Strict_programming_language https://en.wikipedia.org/wiki/Strict_programming_language Haskell allows you to create non-strict impure code using functions like unsafeInterleaveIO, this is generally regarded as a bad idea for technical reasons except in very special cases. See for example Data.ByteString.Lazy.readFile, which is more or less obsolete since the creation of iteratees. http://stackoverflow.com/questions/5892653/whats-so-bad-about-lazy-i-o http://stackoverflow.com/questions/5892653/whats-so-bad-abou... On your second point, nontermination is treated semantically as a value in Haskell. It is an error to consider nontermination an "effect". See: https://en.wikibooks.org/wiki/Haskell/Denotational_semantics https://en.wikibooks.org/wiki/Haskell/Denotational_semantics In short, a function which does not terminate is said to return ⊥ from a semantic perspective. The monotonicity of Haskell functions is what makes this work as you'd expect without violating purity, since ⊥ is the least element.
klodolph 10y ago
In my experience, it is rare to want to put logging in pure code in the first place. You tend to already be using some kind of monad or IO facility in the places where you would naturally want to put logging. This is from my experience with Haskell.
- marcosdumay 10y ago
  That's my experience too. The only reason you may want to log something is because there's something that may change on different executions of the same code, what means it is not pure. That kind of mixing is common on languages that are not completely pure. Because people do not have a good idea about what code depends on the real world, and tend to get "pure" code that can not be relied to be actually pure.

by comex 10y ago

moron4hire 10y ago

There is also the empirical evidence that "mostly functional" C# has successfully been used in perhaps thousands of others around the world. It's hard to take "it doesn't work" seriously when it has clearly worked for me and many others.

continuational 10y ago
How do you do functional programming in C#? It has lambda functions, but it lacks sum types, pattern matching and immutable collections (they exist, but it's not much use if none of the libraries use them).
- kwhitefoot 10y ago
  None of these things are essential for functional programming in the sense of pure functions free of side effects.
  - continuational 10y ago
    In that sense, no programming language feature is essential; you can do pure functions in assembler.

catnaroek 10y ago

Yes, Haskell is a very flawed language, however: (0) The fact you need to modify value-level code to put it in a monadic context is a defect of Haskell's design, not of monads per se. See: http://www.cs.umd.edu/~mwh/papers/monadic.pdf http://www.cs.umd.edu/~mwh/papers/monadic.pdf (1) Laziness has nothing to do with being purely functional.

comex 10y ago
I'm not even trying to criticize Haskell, really; Haskell has plenty of great attributes (though the paper you linked is interesting). I just think this particular argument advocating for it is poorly constructed, basically pointing to a weakness as if it were a strength.
klodolph 10y ago
On the second point, laziness and purity are very closely related. See http://haskell.cs.yale.edu/wp-content/uploads/2011/02/history.pdf http://haskell.cs.yale.edu/wp-content/uploads/2011/02/histor... (§3.2) See http://stackoverflow.com/questions/31477074/how-lazy-evaluation-forced-haskell-to-be-pure http://stackoverflow.com/questions/31477074/how-lazy-evaluat...
- catnaroek 10y ago
  Maybe for social reasons. From a purely technical standpoint: (0) You can have a pure strict language just fine. You can also have a lazy impure language just fine. (1) Nontermination is an effect anyway, so Haskell isn't pure unless you wish nontermination out of existence. (Which the Haskell community is in the habit of doing.)
  - klodolph 10y ago
    I think you may have glossed over that paper I linked. No, you can't have a non-strict impure language just fine, the semantics would make it too difficult to reason about side effects. I am not aware of any such language. According to Wikipedia, Miranda and Clean are also non-strict but they are also purely functional. https://en.wikipedia.org/wiki/Strict_programming_language https://en.wikipedia.org/wiki/Strict_programming_language Haskell allows you to create non-strict impure code using functions like unsafeInterleaveIO, this is generally regarded as a bad idea for technical reasons except in very special cases. See for example Data.ByteString.Lazy.readFile, which is more or less obsolete since the creation of iteratees. http://stackoverflow.com/questions/5892653/whats-so-bad-about-lazy-i-o http://stackoverflow.com/questions/5892653/whats-so-bad-abou... On your second point, nontermination is treated semantically as a value in Haskell. It is an error to consider nontermination an "effect". See: https://en.wikibooks.org/wiki/Haskell/Denotational_semantics https://en.wikibooks.org/wiki/Haskell/Denotational_semantics In short, a function which does not terminate is said to return ⊥ from a semantic perspective. The monotonicity of Haskell functions is what makes this work as you'd expect without violating purity, since ⊥ is the least element.

klodolph 10y ago

In my experience, it is rare to want to put logging in pure code in the first place. You tend to already be using some kind of monad or IO facility in the places where you would naturally want to put logging. This is from my experience with Haskell.

marcosdumay 10y ago
That's my experience too. The only reason you may want to log something is because there's something that may change on different executions of the same code, what means it is not pure. That kind of mixing is common on languages that are not completely pure. Because people do not have a good idea about what code depends on the real world, and tend to get "pure" code that can not be relied to be actually pure.