[Haskell-cafe] IO is a bad example for Monads
Hans van Thiel
hthiel.char at zonnet.nl
Wed Dec 12 10:29:40 EST 2007
On Wed, 2007-12-12 at 16:27 +0100, Hans van Thiel wrote:
> > 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
More information about the Haskell-Cafe