> One is that Haskell forces your program into two parts. Parts that contain > side-effects (in monads) and the part that is pure.
You can actually do quite a bit more, using different monads to compartementalize different aspects of your code. You will, by the way, have noticed that Haskellers tend to put everything in the IO monad (when a separate monad would make more sense) because mixing monads is difficult. > This is great because > the compiler can now do some optimizations not available when you don't know > if your code is pure. I suppose you could get the same benefits with a "purity inference" compiler pass, the same way haskell compilers a "strictness inference". > it makes side-effect creep very obvious (when you realize "oops, that needs > to be in a monad too... and that... and that ... crap"). unsafePerformIO to the rescue ! I generally agree with the interest of pure programming in some part of the language. It is, however, not all as rosy as you say (i've seen people argue that the "side-effect creep" related to monads cause composability problems) because they are hard issue (monads mixing for example) wich have not been quite resolved yet. Haskell is interesting because of that experimental taste, but i totally agree it "sometimes gets in your way". > A similar argument follows for lazy (non-strict) evaluation as well. Allows > some really cool stuff (eg. infinite lists) and optimizations (eg. > deforestation). Explicit lazy evaluation (as in OCaml) can give you the same cool stuff, with a saner standard (strict evaluation) and, in my opinion, increased comprehensibility (by explicitely highlighting the part that rely on lazy evaluation). Both library and syntaxic support of lazy values in OCaml could be better that they are now, but they is work going on (we even have *several* lazy lists librairies these day). > That's true, but I think Haskell's point of view is to stop that completely. > They want to remove optimization of code and put it into the hands of the > compiler. The ideal is to say to the programmer: "don't worry about > performance and optimization, just write correct code. The compiler will > figure out the rest". I strongly disagree on that point. You just can't rely on anything that optimizes "as much as possible" when you don't know precisely what it does. The idea to "not worry about performance" is, in my opinion, wrong because you'll always have specific cases wich are not correctly optimized (see for example the posts on the performance of high-level automatic differentiation stuff that went on the Haskell planet a month ago or so). The usual programmer should not need to know about subtle and implementation-specific stuff (whereas the requirement of understanding tail-recursion is commonly accepted among OCaml programmers), but trying to optimize every naive code into something efficient is a dangerous dream. _______________________________________________ Caml-list mailing list. Subscription management: http://yquem.inria.fr/cgi-bin/mailman/listinfo/caml-list Archives: http://caml.inria.fr Beginner's list: http://groups.yahoo.com/group/ocaml_beginners Bug reports: http://caml.inria.fr/bin/caml-bugs
