One of the great aspects of programming Haskell is the community. We should aim to have the strongest, friendliest, most productive community we can. We're doing a good job so far, can we do even better? Reading this: "How to Build a User Community" http://headrush.typepad.com/creating_passionate_users/2006/12/how_to_build_a... has inspired me to make some suggestions of what *you* can do to help make Haskell the language and community people want to spend time on. * Always encourage newbies to ask questions + I rate us at 8/10 * Encourage newer users--especially those who've been active askers--to start trying to answer questions + we can do more here. If you know the solutoin to a problem, dive in and help out. Canonical, type correct answers preferred! + if you're at the 'intermediate' stage, you can help *now* by contributing to the wiki, solving new user problems, blogging your ideas and code and so on. * Give tips on how to answer questions + Ok. we can put up an article here. Some suggestions: - No questions are bad questions - Code should come with examples of how to run it - Solutions with unsafePerformIO should be discouraged (moreso ;) - Be polite! (we're good at this) * Adopt a near-zero-tolerance "Be Nice" policy when people answer questions + 8/10, we can do even better I think * Teach and encourage the more advanced users (including moderators) how to correct a wrong answer while maintaining the original answerer's dignity. + Pretty good. I encourage people to point out (privately) and encourage grumpy people to be nicer So dive in! Help out new users, collaborate, contribute to the wiki, release your code, and help make Haskell the language people want to use. -- Don
On 12/13/06, Donald Bruce Stewart
* Give tips on how to answer questions + Ok. we can put up an article here. Some suggestions: - Solutions with unsafePerformIO should be discouraged (moreso ;)
I'd like to at least suggest a slight qualification here, based on some personal experience. A colleague of mine learned Haskell after having spent a while doing systems programming, and (with the danger of completely misinterpreting him here), the (perceived) lack of unsafePerformIO et. al. led him to conclude that Haskell was a good high-level language, but a certain number of projects would at least require you to write a fair amount of your code in C. Once he saw some code that (safely) used unsafePerformIO - particularly in fps, as I recall - he changed his mind. To this day, he hasn't written any code using unsafe*, but is generally somewhat more interested in Haskell. So, I'd suggest that demonstrating both the use of unsafePerformIO when the question is obviously trending that way and mentioning why it is a bad idea -- perhaps with an example of something that will obviously segfault or otherwise break type safety - is sometimes a better idea than simply not admitting its existence. Also, I strongly support the necromancy/IO analogies. /g -- It is myself I have never met, whose face is pasted on the underside of my mind.
Hi
* Give tips on how to answer questions
+ Ok. we can put up an article here. Some suggestions: - No questions are bad questions - Code should come with examples of how to run it - Solutions with unsafePerformIO should be discouraged (moreso ;) - Be polite! (we're good at this)
I'd say our worst feature is tending to give solutions which are not "simple" Haskell, but make use of advanced features. When a beginner asks a question, sometimes the answer requires GADT's, Template Haskell, rank-2 types etc. However this is usually because they asked the wrong question - thinking in an imperative frame of mind. Often it would be better to peel back to the original problem, where the answer is more likely to be pure neat Haskell. I guess unsafePerformIO is just one instance of this. Thanks Neil
On 12/14/06, Neil Mitchell
Hi
* Give tips on how to answer questions
+ Ok. we can put up an article here. Some suggestions: - No questions are bad questions - Code should come with examples of how to run it - Solutions with unsafePerformIO should be discouraged (moreso ;) - Be polite! (we're good at this)
I'd say our worst feature is tending to give solutions which are not "simple" Haskell, but make use of advanced features. When a beginner asks a question, sometimes the answer requires GADT's, Template Haskell, rank-2 types etc. However this is usually because they asked the wrong question - thinking in an imperative frame of mind. Often it would be better to peel back to the original problem, where the answer is more likely to be pure neat Haskell.
As a newbie, and a lurker on this list, I'd second this. Often, the subtle and sophisticated answers are very rewarding to study, but they do give the impression that what the person who asked the original question was trying to do, is hard. Generally, it's a turn-off to feel that something which seems simple in another (probably procedural) language is hard in Haskell. At its worst, it comes across as people trying to look clever, rather than trying to help. If the user thinks it's a simple task, show a simple answer where at all possible. But overall I'd agree, this is a very helpful community - it's just that you all seem so much cleverer than I, so I'm not sure I'll ever be smart enough to write Haskell programs :-) (50% joke...) Paul.
Hallo,
On 12/14/06, Paul Moore
But overall I'd agree, this is a very helpful community - it's just that you all seem so much cleverer than I, so I'm not sure I'll ever be smart enough to write Haskell programs :-) (50% joke...)
I know the feeling. :-) -- -alex http://www.ventonegro.org/
On Thu, Dec 14, 2006 at 10:16:10AM +0000, Neil Mitchell wrote:
I'd say our worst feature is tending to give solutions which are not "simple" Haskell, but make use of advanced features. When a beginner asks a question, sometimes the answer requires GADT's, Template Haskell, rank-2 types etc. However this is usually because they asked the wrong question - thinking in an imperative frame of mind. Often it would be better to peel back to the original problem, where the answer is more likely to be pure neat Haskell.
I guess unsafePerformIO is just one instance of this.
Absolutely. Some more questions of this type: How do I update a variable? How can I efficiently update an array? How do I get debugging output? How can I put different types of things in a list? Sometimes the person asking is ready for the advanced features, but all too often beginners are pointed at IORefs, the ST monad, trace and existential types, when, as you say, they probably asked the wrong question because they don't have the frame of reference to know what they need.
On 12/14/06, Ross Paterson
Absolutely. Some more questions of this type:
How do I update a variable? How can I efficiently update an array? How do I get debugging output? How can I put different types of things in a list?
Sometimes the person asking is ready for the advanced features, but all too often beginners are pointed at IORefs, the ST monad, trace and existential types, when, as you say, they probably asked the wrong question because they don't have the frame of reference to know what they need.
I've definitely made that mistake about the heterogenous list. I blurted out existential code when they just didn't know about "data" types. Sure I see the mistake I made there, but variant types are often assumed to have been ruled out--it's kind of step one with Haskell. That's not to say it was the poster's fault: any question is a good question. Sometimes it's appropriate to assume some knowledge on the poster's behalf, and it would be tedious if every first response was a list of 10 questions gauging the poster's familiarity with various intro topics. Brainstorming: 1) The first response to a FAQ should be a link to a thorough treatment of the FAQ on the wiki. Of course first responders ignorant of the wiki FAQ's existence wouldn't be able to do this, but if the community is consistent, then people will most likely catch on (I suddenly realize that I'm talking about myself...) 2) The "welcome to the mailing list" message could say "if you're new to Haskell, please check this FAQ first". I'm talking big letters here; I'd even be OK with <marquee>. Are these rules too draconian? Should we just adopt the tedium of quizing every new poster? What are some other steps that could help prevent overly sophistocated first responses? Nick
On 15/12/06, Nicolas Frisby
... That's not to say it was the poster's fault: any question is a good question.
I agree ...
2) The "welcome to the mailing list" message could say "if you're new to Haskell, please check this FAQ first". I'm talking big letters here; I'd even be OK with <marquee>.
... hence I'd caution against such a rule. Part of the reason this community is welcoming is because there is no such barrier for people new to Haskell to ask questions. Everyone has a different mathematics ability and programming experience, and an ambiguously posed question is often just scratching the surface of what someone really wants to know. It's great that this community recognises that and responds accordingly. By contrast, many technical communities follow the advice of a document called "How to ask questions the smart way" by Eric Raymond and Rick Moen [0]. Although it contains some useful advice for individuals who want to find the answers to simply definable technical questions, imposing that advice on people who ask questions often ends up being elitist. For an example from that document: What [hackers] are, unapologetically, is hostile to people who seem to be unwilling to think or to do their own homework before asking questions. People like that are time sinks — they take without giving back, and they waste time we could have spent on another question more interesting and another person more worthy of an answer. We call people like this "losers" (and for historical reasons we sometimes spell it "lusers"). I hope the Haskell community never adopts such an arrogant tone. By all means, responders should politely refer to existing FAQ entries, and use the opportunity of answering questions to also improve the FAQ. At best, answering questions (the smart way ;-) should be thought of as taking part in a mathematical dialogue, not as a game of wits where the original poster is only given one chance to precisely formulate their question. cheers, Conrad [0] (which you can find by searching the Web for its title)
On 14/12/06, Conrad Parker
What [hackers] are, unapologetically, is hostile to people who seem to be unwilling to think or to do their own homework before asking questions. People like that are time sinks — they take without giving back, and they waste time we could have spent on another question more interesting and another person more worthy of an answer. We call people like this "losers" (and for historical reasons we sometimes spell it "lusers").
I hope the Haskell community never adopts such an arrogant tone.
I really agree with this. I think that one of the reasons that the Haskell community has grown to be so polite and helpful compared to many communities of comparable size is that kindness begets kindness. There's been a lot of chatter lately about how the Haskell community can grow faster than it has been. Personally, I would rather not have it grow any faster than we can manage. If there was a sudden influx of 10000 brand-new Haskell users overnight (unattached to some pre-existing educational program), I think this community would quickly have a major problem answering all the mailing list and IRC traffic. If the community grows gradually, we'll easily be able to support it, because there will be a correspondingly larger number of experts and intermediate level users to help us out. Remember, if some significant factor of Haskell programmers advocate the language just to two of their friends, that's still exponential growth. There are also lots of other reasons why growing too quickly and gaining commercial users too quickly are double edged swords. Personally, I'd like to see the Prelude undergo a few more iterations, and it gets harder to change as more and more projects rely on it. When it does change, the maintenance cost of old code goes up, and not every project has an active maintainer. Popularity also results in large numbers of people who are invested in a particular way of doing things and are resistant to change. Haskell is a research language, and I'd personally like to see it remain a research language as its user-base grows. Granted, it would be better than the 30-year-old-at-heart programming languages people are using today, but I don't think I'd be truly satisfied if the Haskell which everyone used was not the Haskell which the researchers were working on with all the cool new ideas in it. I'm not saying "don't advocate Haskell", I love it too, and I like seeing new users, but I think we need to take some care in maintaining our excellent community while we're at it. Advocating the language on a grassroots basis means that each new user gets a mentor, or if not one, then an equivalent-mentor spread across the community, and people who have been mentored in such a way tend to repay it many times over in helping other beginners. Having a tightly-knit community who have adopted the mindset of following language development closely will also help offset the costs of change to the language. There are lots of benefits to growing the community, I just think that these are things to consider before we take out a full-page ad in the New York Times. :) - Cale
Cale Gibbard schrieb:
There are also lots of other reasons why growing too quickly and gaining commercial users too quickly are double edged swords. Personally, I'd like to see the Prelude undergo a few more iterations, and it gets harder to change as more and more projects rely on it. When it does change, the maintenance cost of old code goes up, and not every project has an active maintainer.
This problem affects all libraries, not just the Prelude. And it would be futile to hope that all of it will ever stabilize. There will always be new libraries that are too new to have stabilized yet, and that will always be an excuse for not "going commercial" (or, vice versa, not adopting Haskell in a commercial setting). The only solution that I know is explicit version numbering: wxHaskell 5.3.1 needs the Prelude 3.1.574, and there's a respository somewhere (on the net or locally or whatever) that will automatically deliver Prelude 3.1.574 along with a requested wxHaskell 5.3.1. Details can vary considerably, of course. Regards, Jo
Hello Joachim, Friday, December 15, 2006, 11:34:09 PM, you wrote:
This problem affects all libraries, not just the Prelude.
The only solution that I know is explicit version numbering: wxHaskell 5.3.1 needs the Prelude 3.1.574, and there's a respository somewhere (on the net or locally or whatever) that will automatically deliver Prelude 3.1.574 along with a requested wxHaskell 5.3.1. Details can vary considerably, of course.
look at http://haskell.org/haskellwiki/Library_versioning_policy which is my proposal of how to maintain this problem -- Best regards, Bulat mailto:Bulat.Ziganshin@gmail.com
participants (11)
-
Alex Queiroz -
Bulat Ziganshin -
Cale Gibbard -
Conrad Parker -
dons＠cse.unsw.edu.au -
J. Garrett Morris -
Joachim Durchholz -
Neil Mitchell -
Nicolas Frisby -
Paul Moore -
Ross Paterson