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