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

Alex Jacobson alex at alexjacobson.com
Tue Dec 11 22:49:25 EST 2007


It might help to point out that its easy to end up with memory/space 
leaks in Java/python/ruby/perl too.  Also stack overflow is really easy. 
  Also, you can get into really deep badness if you do anything 
interesting with concurrency because of the global interpreter lock etc.

As far as pickling goes, HAppS-Data makes it trivial to pickle most 
anything into XML or name/value pairs so that is no longer a valid 
complaint.

-Alex-


Dan Weston wrote:
> 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.
> 
> _______________________________________________
> Haskell-Cafe mailing list
> Haskell-Cafe at haskell.org
> http://www.haskell.org/mailman/listinfo/haskell-cafe



More information about the Haskell-Cafe mailing list