brainwagon

I’ve been fascinated by functional programming languages for at least twenty years, but I must admit, despite my rather academic interest, I’ve simply not found them to be very pleasant or useful. Nevertheless, I keep thinking that I haven’t really dedicated myself to resolving this issue fully, and I keep thinking that someday I should get around it it.

Mark Chu-Carroll, over at the Good Math Bad Math blog has decided to try to write a series which will serve as an intermediate tutorial that might convince you that writing programs in the functional programming language Haskell might just be a good idea. His first installment actually fills me with a sense of uneasy foreboding, because it reuses the tired chestnut that we always see in intro to functional programming languages: namely qsort.

Yes, qsort is easy to write in functional programming languages. But the simple fact is: it’s pretty damned simple to write in any language, particular if the language has some kind of list datatype. Consider this version in Python:

def split(x, l):
        lo, hi = [], []
        for y in l:
            if y < x:
                lo.append(y)
            else:
                hi.append(y)
        return (lo, hi)

def qsort(l):
        if l == []:
                return l
        else:   
                lo, hi = split(l[0], l[1:])
                return qsort(lo) + [l[0]] + qsort(hi)

Is this version harder to understand than the Haskell version? I can’t see how it is. Is it less efficient? Well, it’s hard to say actually, at least from principles. Python doesn’t really guarantee much about the efficiency of recursion, and combined with the its applicative order evaluation, it builds a lot of temporary lists that the Haskell version could avoid. But Haskell isn’t exactly a free ride either. Sometimes lazy evaluation can turn around and bite you as well. But the real point is simply this: that this particular example does really very little to justify Haskell as a choice for programming.

Most books on functional programming suffer from this fault. They are demonstrations of trivial or near trivial programs carefully chosen by people who like functional programming because they demonstrate the conciseness of functional programming. The problem is that these examples are convincing only to the converted: they don’t generate any new converts.

Real programming is messy. Efficiency matters. Clarity matters, but cleverness probably does not matter. Handling exceptions reasonably matters. Code reuse matters.

I’m skeptical, but I am still looking forward to the rest of the series.

[tags]Programming Languages,Haskell[/tags]