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

[Hans van Thiel]

On Wed, 2007-12-12 at 16:27 +0100, Hans van Thiel wrote:
> [snip]
> > 
> > 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).
> I see your point, but maybe there should be better analyzing tools then,
> as well as tutorials which explain that problem. 
> > 
> > >> 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.
> I admit I don't understand this. 
> > 
> > >> 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.
> But that person will be used to all the help he's gotten from the Java
> and/or Eclipse, with tutorials and reference implementations. Now he has
> to depend on dissertations and JFP articles for anything that's less
> than 10 years old, and a few helpful experts (much appreciated, I want
> to add) who are willing to spend the time to answer questions. 
> > 
> > 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.
> It's possible, IMO, that Haskell requires a higher skill level in
> information science that the imperative languages. Many working
> programmers come from different backgrounds and are not experts in
> computer science. But, like a skyscraper is not built just by the
> architects, maybe those 'lower' skills have their place too. Maybe not,
> or not in Haskell. Could be, though I don't think so, myself.
> > 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.
> If they read this, I'm sure they will.
> 
> Best Regards,
> 
> Hans van Thiel
> >