4 ms·
This rant strives to dispel two myths: 1.) Haskell is "a bad language to write IO intensive programs in" 2.) "maintenance is more expensive as Haskell program
by ankrgyl 15y ago
This rant strives to dispel two myths:
1.) Haskell is "a bad language to write IO intensive programs in"
2.) "maintenance is more expensive as Haskell programmers are thin on the ground"
I was convinced of neither.
First, just because your own (potentially biased) benchmark shows that GHC performs "very favorably" doesn't mean this is true in general. For anyone to buy that argument, you need to provide code or at least a precise description of the experiment. These guys did a good job of that: http://www.yesodweb.com/blog/2011/02/warp-speed-ahead http://www.yesodweb.com/blog/2011/02/warp-speed-ahead. Also, just because iteratees are fast, doesn't mean they're "good" for writing I/O intensive programs in. They're really difficult to understand, so most people end up using lazy I/O. Part of not being bad for I/O programs is making the task approachable, and I'm not convinced of that by this article.
The argument to dispel #2 is vague too.
> If you agree that programs that are more correct are also of higher quality then the you should also agree that the cost of maintenance for Haskell programs is lower than for imperative programs.
Okay... You can still write errors in Haskell, they're just less frequent (at least that's what this statement suggests). But how can you maintain them if no one is willing to actually do it? If it's N times easier to maintain a Haskell programmer, there need to be at least 1/N as many Haskell programmers as there are imperative programmers, and the article doesn't address this at all. As someone who likes Haskell, I'm actually curious to know if this is true.
- chc 15y agoActually, there merely need to be 1/N programmers capable of using Haskell. There's no separate species known as a "Haskell programmer."
- eru 15y agoThere are. Some people, who after having tasted the forbidden fruit, refuse to program in lesser languages.
- DanWaterworth 15y agoOr just get irritated with lesser languages. I know I do this.
- tmorgan 15y agoYes, the argument presented for point one is pretty weak, but I do agree with it. Having the lazy I/O, and especially lazy bytestring option is great IMO. Although Oleg style left-fold enumerators as used by warp are superior in many respects, typically as a user you don't need to interact at that level; iirc you don't in Yesod, which is built on warp. As an example of approachability LBS approach, checkout this two line "wc -l" implementation, which beats "wc -l" by 64x, apples and pears no doubt, but shows fast enough,(from http://www.mail-archive.com/haskell@haskell.org/msg18878.html http://www.mail-archive.com/haskell@haskell.org/msg18878.htm...): > import qualified Data.ByteString.Lazy.Char8 as L > main = L.getContents >>= print . L.count '\n' edit: actually it beats "wc", and is roughly same speed as "wc -l".
- ankrgyl 15y agoThat's really cool, and is the kind of good benchmark I was referring to. I'm curious to see how it compares to an iteratee approach. I suspect in this case that there wouldn't be much of a difference, because iteratees are suited especially well for handling multiple concurrent streams, and this deals with only one.
- MostAwesomeDude 15y agoWhat I always found interesting was the implication that programs proven correct are also free of logic errors more of the time, and worse, that they are free of algorithmic complications. To be fair, the latter point is slowly being addressed, although it rips massive holes in the purity of Haskell and Scheme. I mean, who wants to see explicit tail recursion all the time, or mutable large data structures? But the alternative is slow code. I think that Haskell's forced purity is roughly as good at catching logic errors as the strict typing of C++ or the clean syntax of Python: It catches some stuff, some of the time, but never everything, and never reliably. At some point, the onus is on the programmer to write good code.