Re: [Haskell-cafe] I read somewhere that for 90% of a wide class of computing problems, you only need 10% of the source code in Haskell, that you would in an imperative language.

Deniz Dogan wrote:

2009/9/30 Andrew Coppin :

...

(Mr C++ argues that homo sapiens fundamentally think in an imperative way, and therefore functional programming in general will never be popular.

Sounds more like Mr C++ fundamentally thinks in an imperative way because that's what he is used to.

Entirely plausible, yes. Consider, for a moment, the task of counting how many elements there are in a linked list. The imperative way: "Initialise counter to zero. Start at the beginning of the list. If we have reached the end of the list, return the counter. Otherwise, increase the counter by one and fetch the next list node." The FP way: "The size of an empty list is zero. The size of a nonempty list is one plus the sum of the suffix of the list." It does read kind of like a riddle. It's not even immediately obvious that this is the entire definition. (Unless you already happen to be a maths nerd, like myself.) The first one reads like a list of instructions explaining HOW to count the list size. The second reads more like a definition of WHAT the list size is. It doesn't immediately look like there's even a way to execute this. (They don't call it declarative programming for nothing...) I note in passing that, even in English, the FP version is shorter. ;-) I think if you wanted to count the size of a tree, it seems a lot more natural though: "If this is a leaf node, return one. Otherwise: Initialise counter to zero. Count size of left subtree and add to counter. Count size of right subtree and add to counter. Return counter." "The size of a leaf node is one. The size of a branch node is the sum of the sizes of the two subtrees." Arguably most people are probably more accustomed to thinking in terms of "do this, do that, do the other" (think about, e.g., a cooking recipy or a task list) then they are to defining task goals as self-referential riddles. On the other hand, from what I've experienced, computer programming is already a task that some people "get", and others simply don't. Maybe in another forty years, all programming will be functional programming, and anybody who doesn't "get" recursion just won't become a programmer? Who knows...

Ah, the joy of FP.

Amen!