
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:
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
On Tue, 2007-12-11 at 16:56 +0100, Wolfgang Jeltsch wrote: 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@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe