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

...