Ben,

This is precisely the kind of problem I am currently thinking about and why I asked for pointers to documents on best practices. The current model for gaining the necessary experience to use Haskell effectively does not scale well.

Here are some ideas on how to address the knowledge issue:

1) Outstanding best practices documents that capture this knowledge and provides useful answers. Organizing this information in an online document that can be searched by keyword or index would be really helpful. The hard part will be maintaining it. As someone already pointed out the wiki entry on performance is already dated.

2) Training presentations derived from #1 that provides lots of examples.

3) Online Training Videos based on #2 above

4) Profiling tools that uses the captured knowledge above, highlights problem areas, and provides guidance on correcting them.

As I mentioned in a previous email. I am willing to take on organization #1, but I will need help from people on this list. I can start with the performance wiki, but we will still need examples of where people get into trouble and the ways around them.

Gregg


On 5/16/2012 4:00 PM, Ben Gamari wrote:
Kevin Charter<kchar...@gmail.com>  writes:

snip
For example, imagine you're new to the language, and as an exercise decide
to write a program that counts the characters on standard input and writes
the count to standard output. A naive program in, say, Python will probably
use constant space and be fairly fast. A naive program in Haskell stands a
good chance of having a space leak, building a long chain of thunks that
isn't forced until it needs to write the final answer.  On small inputs,
you won't notice. The nasty surprise comes when your co-worker says "cool,
let's run it on this 100 MB log file!" and your program dies a horrible
death. If your friend is a sceptic, she'll arch an eyebrow and secretly
think your program -- and Haskell -- are a bit lame.

I, for one, can say that my initial impressions of Haskell were quite
scarred by exactly this issue. Being in experimental physics, I often
find myself writing data analysis code doing relatively simple
manipulations on large(ish) data sets. My first attempt at tackling a
problem in Haskell took nearly three days to get running with reasonable
performance. I can only thank the wonderful folks in #haskell profusely
for all of their help getting through that period. That being said, it
was quite frustrating at the time and I often wondered how I could
tackle a reasonably large project if I couldn't solve even a simple
problem with halfway decent performance. If it weren't for #haskell, I
probably would have given up on Haskell right then and there, much to my
deficit.

While things have gotten easier, even now, nearly a year after writing
my first line of Haskell, I still occassionally find a performance
issue^H^H^H^H surprise. I'm honestly not really sure what technical
measures could be taken to ease this learning curve. The amazing
community helps quite a bit but I feel that this may not be a
sustainable approach if Haskell gains greater acceptance. The profiler
is certainly useful (and much better with GHC 7.4), but there are still
cases where the performance hit incurred by the profiling
instrumentation precludes this route of investigation without time
consuming guessing at how to pare down my test case. It's certainly not
an easy problem.

Cheers,

- Ben


_______________________________________________
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

_______________________________________________
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Reply via email to