[Haskell-cafe] IO is a bad example for Monads

[Dan Weston]

Hans van Thiel wrote:
> On Tue, 2007-12-11 at 16:56 +0100, Wolfgang Jeltsch wrote:
>> Maybe there are also patient people in the outside world so that we can still 
>> expose Haskell to the outside world while not trying to attract 
>> quick-and-dirty hackers. ;-) 
> But who are those people? And what harm can they possibly do, assuming
> they fit the derogatory description?

I fear those people can do vast amounts of damage. :(

When inept programming yields the wrong result, it is clear (even to the 
inept) that the program is bad.

When the result is correct but there are egregious time or space leaks, 
it is "clear" to everyone but the Haskell guru that it "must" be the 
programming language that is deficient, and will be duly flamed far and 
wide. This perception will be impossible to reverse when it gains 
traction (and nothing ever goes away on the Internet).

Seeming "deus ex machina" code changes (perhaps helpfully offered on 
haskell-cafe) to minimize or correct the undesirable runtime behavior 
appear even to many Haskellites to be black magic, accompanied by the 
runes of profile dumps (like knowing what generation 0 and generation 1 
garbage collection is).

>> Haskell is not a quick-and-dirty language but quite the opposite.  Haskell’s 
>> unique selling propositions are features like type classes, higher order 
>> functions and lazy evaluation which make life easier in the long term.  The 
>> downside of these features is that they might make life harder in the short 
>> term.
> I don't know. In a sense Haskell is easier than, for example, C, because
> the concept of a function definition is more natural that that of
> assignments and loops. The idea that x = 5; x = x + 7 makes sense
> requires a complete new way of thinking. OK, once you've been doing it
> for a few years switching back to x = 5 + 7 is hard.

I would limit that to say that *denotational* semantic intuition is easy 
to wield in Haskell. Operational semantic intuition is Haskell is very 
non-obvious to the imperative (and many functional) programmers.

Making matters worse, the first is an advantage well-hyped by 
functionistas, the second hurdle is rarely admitted to.

>> That said, I definitely think that we should make learning the language as 
>> easy as possible.  But our ultimate goal should be to primarily show 
>> newcomers the Haskell way of problem solving, not how to emulate Python or 
>> Java programming in Haskell.
> Again, is there a danger of that happening?

Yes. Those absent the necessary humility to approach haskell-cafe with 
open mind and flame-retardant dialog will fall back on what they know: 
transliterated Java/Python with a morass of do blocks and IO monads, 
then (rightly) bash how "ugly" Haskell syntax is when used in this way.

This type of programmer looking to use Haskell casually should sign a 
"benefit of the doubt" contract whereby they assume that any runtime 
suboptimalities derive from their own coding and not from Haskell's 
defects. This is the innate assumption of the curious, the 
self-motivated, the clever. This is not typically the starting 
assumption of the "I'm an expert at Joe-imperative language" hacker who 
took 10 years to perfect his Java skills and expects thereby to jump to 
at least year 5 of Haskell without effort.

I do strongly believe in stimulating the curiosity of all comers, just 
not in giving the false impression that a quick read-through of a few 
tutorials will let you write lightning-fast code, or know when to 
abandon [Char] for something more clever, or where to insert those bangs 
and fold left instead of right, and how ad hoc and parametric 
polymorphism differ, and what Rank-n and existential means (and why you 
can just pickle any object in Python but need to know a half dozen 
abstract things including who Peano was to do the same in Haskell), and 
what the heck an infinite type is, and on and on.

Haskell has definitely been teaching me some serious humility! Possibly 
it is best that those not ready for that lesson might better stick with 
Python.