
On 10/12/2007, Henning Thielemann
On Mon, 10 Dec 2007, Dan Piponi wrote:
When someone comes to me and says "I have this Python script that scans through these directories and finds the files that meet these criteria and generates a report based on this template, could I do it better in Haskell?" it'd be good to have a better answer than "to do this you could use the IO monad, but to do things properly you need to understand monads so here, learn about the List monad and the Maybe monad first, understand how this interface abstracts from both, come back when you've finished that, and then I'll tell you how to read and write files". And I definitely want a better answer than "Haskell I/O is performed using the IO monad but everyone thinks this is bad so just wait a few years and someone may write a fancy new nice combinator library that does exactly what you want". There are thousands of competing programming languages out there, and there are dozens that are viable choices for the task I just mentioned. If my response to their question takes longer than the time it would take to find another language and implement a solution, then Haskell will remain a niche language.
I raise my question once again: Must Haskell's tutorials be tailored to impatient programmers? Does Haskell need quick&dirty hackers?
Sigh. I've seen this type of comment on this list so many times, and I still feel insulted by it. Must the Haskell community (and yes, I know it's not everyone, it's quite probably only a few members, but it feels like a lot) treat anyone who just wants to get a job done, while being open minded enough to consider a new and very unconventional language, as being "impatient" and a "quick and dirty hacker"? I'm sorry. I left it quite a while before I responded, so that my initial annoyed feeling could subside, but it didn't. I've hit all of Dan's barriers (apart from fear of recursion :-)) and yet I would not characterise myself as you describe (OK, maybe somewhat impatient :-)). Also, I have a fair bit of experience with non-imperative styles - I have, over the years, learnt a number of languages including Lisp, Prolog, Scheme and many others with functional or non-imperative aspects (I even recall looking a little at Hope and Miranda a long while ago). Haskell is the most practical functional language I have encountered, but I still feel that IO (in the most general sense of interaction with the outside world) is hard in Haskell[1]. Maybe it *can* be easy, but it isn't yet. And ignoring that fact isn't helping anyone. Paul. [1] Certainly you can toss out examples of easy IO in Haskell. Things like interact help a lot. But ultimately, you hit something hard - maybe it's handling errors robustly while using IO, or interacting with a database rather than a screen, or whatever. But at some point, you run out of clean off-the-shelf encapsulations, and get to genuinely hard stuff - and that happens in a huge step change, rather than a gradual increase of complexity that you can take as slowly as you need to.