On Friday 26 January 2007 22:14, Tim Newsham wrote:
impractical language, only useful for research. Erik Meijer at one point states that programming in Haskell is too hard and compares it to assembly programming!
He brings up a very good point. Using a monad lets you deal with side effects but also forces the programmer to specify an exact ordering. This *is* a bit like making me write assembly language
programming. I have to write:
do { x <- getSomeNum y <- anotherWayToGetANum return (x + y) }
even if the computation of x and y are completely independant of each other. Yes, I can use liftM2 to hide the extra work (or fmap) but I had to artificially impose an order on the computation. I, the programmer, had to pick an order.
Humm. While I can accept that this is a valid criticism of Haskell's monadic structure for dealing with I/O, I fail to see how it could drive a decision to prefer an imperative language like C#, where every statement has this property (overspecification of evaluation order). The only mainstream-ish general-purpose language I know of that I know of that attempts to addresses this problem head-on is Fortress. (Although, to be honest, I don't know enough about Fortress to know how it handles I/O to even know if it is an actual improvement over the situation in Haskell.)
Ok, maybe "assembly language" is a bit extreme (I get naming, allocation and garbage collection!) but it is primitive and overspecifies the problem.
Tim Newsham http://www.thenewsh.com/~newsham/