Brandon Allbery:

On Sun, Aug 3, 2014 at 10:39 AM, Doug McIlroy mailto:doug@cs.dartmouth.edu> wrote:

Because the effects of buffering are not transparent, it would be wise to make it an optional optimization, not a default.

It's not just efficiency, it's also behaving compatibility with other implementations. Or were you going to argue this with e.g. the ANSI C committee too?

I admit that I didn't follow this thread, so I might have skipped something, but ... Is Brandon Albery suggesting that Haskell should progress in the direction that makes it as compatible as possible with ANSI C? Jerzy Karczmarczuk

I'm sorry you find this an unpalatable notion; perhaps Haskell should forcibly reject all conceivable real world usage in order to properly meet your expectations.

Take it down a notch, guys. We're usually very good at being a place where outsiders can be confident their (coherent) questions and ideas will be treated respectfully. If they can't be, many people with good ideas will stay silent or go elsewhere. Tom

On Sun, Aug 3, 2014 at 6:31 PM, wrote:

"Java does not buffer by default, it is up to YOU to use BufferedReader and/or BufferedWriter if you do not want I/O to be catastrophically slow".

Pretty much, yes. I'd forgotten that particular Java misfeature, particularly since everyone else who'd considered changing the default learned from the Java experience instead of repeating it. (Granted, Java is something of a pessimal case.) -- brandon s allbery kf8nh sine nomine associates allbery.b@gmail.com ballbery@sinenomine.net unix, openafs, kerberos, infrastructure, xmonad http://sinenomine.net