Re-Learning to Count with Haskell pt.1

Functional Programming in a Nutshell

    It is becoming clear to me that counting, particularly conditional counting, may be one of the core lessons of Functional Programming and thus Haskell. A pure FP language has no mutable-state variables. Likewise, there are no global-variables in Haskell. This makes counting a serious problem for those new to FP and thus to those new to Haskell. 

    This marks a crucial divergence in how programming languages are designed. Imperative languages make liberal usage of mutable-state global variables. This makes realizing a program into an intuitive process. Imperative languages represent the way that the human mind reasons verbally. For instance, in order to count we memorize a number and add to that number using a universally known-sequence: the number line. At all points during our calculations, the current state of that number (the tally) is known. In this way, all variables are global in the human mind. Not only are they global, they conform to patterns like the number-line. 

    For instance, if you give someone a collection of single digit numbers at random, and ask them to assemble them into an ordered list, we know by sight which  place-setting each individual number belongs in. We do not need to use a merge-sort or insertion-sort method. We simply look at a number, say 7 for example, and intuitively know that it goes ahead of 1 through 6 but below 8 and 9. When we sort, we simply put each number into it's place, there is little to no method needed because we have such a firmly ingrained number line already in our heads.

    Now, we pick up a Haskell book and find that Haskell can't even remember numbers. It has a memory like the compartments of a Nautilus shell, each one closed to all others and none aware of the other's existence. This is supremely frustrating to the uninitiated because counting is one of the first skills we learn and we spend our entire lives doing it exactly the same way. In order to use Haskell, you have to take that fundamental pre-school era tool and chuck it out the window.

    There is only one fundamental tool in Haskell: recursion. Functions are merely a method devised to implement recursion. In order to count, you need to understand recursion. In order to store state-data, you need to utilize recursion. In order utilize recursion, you need to utilize recursion. Its enough to make your brain melt. 

    Once a function outputs a piece of data in Haskell, it is gone forever. You can try to capture that piece of data using a declaration like 'let tally = product [1,5,6,2]'. But once you declare a piece of data (like 'tally'), it is set-in-stone. You can never change 'tally', you can only destroy it and make a new one. This is the crux of FP. If you can accept and master these core precepts, you can master FP. If not, then you might-as-well sell your Haskell texts and forget that you ever even heard the phrase Functional Programming. In fact, this is exactly what the vast majority of people do. Not just students, professionals, academics and instructors do this in droves. More people reject FP than those who last long enough to learn to use it productively. This is unquestionably a massive weakness to the FP paradigm. However, I don't think it is inexorable.

    The fundamental problem with FP is that there just aren't any good texts on the subject. The few that exists are unorganized and vague, most likely because there just aren't enough professional writers in the FP writing-pool. The few authors who will take-on the subject seem to know that FP will never really take off and so only write for the benefit of the most harcore programming enthusiasts, and as such, completely gloss over the most basic of subjects like: How to Count in a Functional Programming Language. I will therefore devote my next blog entry to this fundamental subject. Look for part 2 in the coming weeks; where I shall spell it out free of charge.