First, thank you for your most-recent response. There are many interesting ideas within it, and I want to get to them. But before we do that, let's put our discussion within proper context.

I must make clear that we have wandered onto dangerous ground. We are using my meditation as the testing ground for your conclusions about the merits functional programming, and it was never indented to be anything other than a meditation.

To be blunt: If you're looking at my mediation as anything other than a meditation, you're making a mistake. My meditation is not meant to be practical. It is not meant to be advocacy for functional programming. It is a meditation: a discourse intended to express my focusing on one idea – sequences – and going with it as deep as I can.

The point of the meditation is not to say that "this way is better." The point is to ignore earthly concerns that normally hold us back (such as practicality) and to keep moving forward with an idea, just to see where it takes us. Maybe we'll end up at a really cool place. Maybe not. Regardless, we hope to learn something from the journey, if not from the destination.

At certain points along our journey you have asked, "Why did we walk this strange path to get to this spot? I know a road that most people would think is better."

But we're not trying to find the best path just now. We're trying to walk a different path to see if we can learn anything. Instead of comparing our path to the road and dismissing it as inferior after the first few miles, can we not keep on walking, just to walk, and to see if we encounter anything new or valuable?

In the end, maybe we will still prefer the road, but then again, maybe knowing the path will come in handy. Maybe some destinations will best be reached by traveling both road and path. Maybe the path will be a valuable addition to our options for future travel.

To come at it practically, don't judge my examples. Judge the ideas the examples represent. But only later, after due consideration.

Now, on to specific items.

My question is: "Do I need this new vocabulary?"

Whether you need any new vocabulary depends on the vocabulary and on the problems you are trying to solve. If the cost of learning the vocabulary and then using the vocabulary to solve your problems is less than the cost of solving your problems otherwise, then you probably ought to use the vocabulary.

Do you need my meditation's sequence vocabulary? Most likely, no. It exists only for this meditation. If I were to create a CPAN module from it, as some have suggested, the resulting library would look and be organized much differently than presented here. The goals of meditation and of practical programming are far apart.

I would, however, argue that much of the vocabulary of ideas and techniques within the meditation are useful and could earn its place in most personal programming toolboxes.

But the single line that sums up my feelings of what I've seen of FP tutorials and advocacy comes from the Abstract on the page you linked to above.

Since modularity is the key to successful programming, functional languages are vitally important to the real world.

The problem with that statement is that it implies that the only way to achieve modularity, is through FP--which is clearly not the case.

I don't think that Hughes implies that FP is the only way to achieve modularity. Rather, he argues that FP (especially modern FP) reduces the cost of modularity to the point where it can be used, and its benefits reaped, almost ubiquitously – not just at object or function boundaries but at much finer granularities.

In most languages, the smallest unit of modularity is the object or function. But in Haskell, for example, I can go much finer. I can slice function calls in half, turn operators into functions and functions into operators, flip arguments around, and do a whole lot more to reshape code until it fits my needs. The potential for code reuse goes up dramatically because I can modularize on a much finer granularity than before; the artificial distinctions that other languages impose between language and library cease to exist. Libraries aren't merely collections of functions but real vocabularies that extend the language.

I've been trying to get into FP since I first starting reading articles on Lisp in Byte magazine circa. 1979/80. I currently have Common Lisp, Scheme, and most recently Haskell.

To help me understand and quantify where you're coming from, how many hours would you conservatively estimate that you have spent writing functional code in the last year?

The problem is that in common with many other FP (and, notoriously OO) tutorials, ("Why Functional Programming Matters") selects very specifically limited and condusive (to their aims) examples. It then spends an inordinate amount of time concentrating on how to construct the solution--in it's own, very esoteric, terms. Your real world examples are infinitely better (IMO).

The problem for people who write about FP to non-FP audiences is that the introductory slant of their writing prevents the use of complex example problems, where FP's merits are readily visible. Anybody can solve simple problems in any language, and so readers understandably wonder why FP is so great when their "normal" solutions to the same example problems would arguably be better.

For this reason, some FP authors will pick simple example problems that just happen to be hard to solve in non-FP languages. While the intent is to keep the problems simple enough that readers can follow them and yet "hard" enough to show the merits of FP, many readers conclude that the examples are contrived or even rigged to put FP in an artificially glowing light.

Sadly, this is a case when the limitations of the medium undo the message.

FP languages let you manipulate pieces of programming logic as easily as most languages let you manipulate data. As a result, it is easy to create FP programs that morph their shape to match the structure of the problems they solve. Thus the straightforward FP solution is often general enough to scale from the simplest to the most complex problems within a wide spectrum of related problems.

This is deeply cool magic, but you won't appreciate it until you experience it. And you won't experience it in introduction-to-FP papers. You can't put examples like that into a paper. The best way, then, to read the papers is to study the examples carefully, understand the thinking behind them, and then meditate on how far that thinking will take you. Often, it will take you surprisingly far.

I hope that doesn't all seem negative? It isn't meant to be. I'm continuing to enjoy reading your article and pursue various angles that lead from it.

No, I don't take it as negative. But I do see a slight danger of your drawing conclusions about FP without due consideration. Be deliberate about forcing your mind to remain wide open while you invest serious time in studying and coding functional programs.

The best advice I can give you is to force yourself to write functional code, the more the better. If you're already looking at Haskell, that's your best bet. (There is no finer modern FP language, IMHO.) Get a copy of Paul Hudak's The Haskell School of Expression: Learning Functional Programming through Multimedia and work through it. Solve the problems. Don't skip the proofs.

For me, the most significant thing that came out of your response to my initial post is:

Instead of passing in \(@site1,@site2) you can pass in any number of input arrays. And the same code works, as is.

Now that is a benefit that I can understand and internalise :). I did try to download your code and try this out, but there seem to be some bits missing to allow the examples to work?

I think the problem is that you commented out the OO portion of my code but forgot to recode seqsub accordingly. Add the following to your code (or uncomment the OO portion that you commented out), and you should be good to go:

    sub seqsub(&) { $_[0] }
[download]

Here's our example solution put into a subroutine so that we can call it repeatedly with differently "shaped" inputs:

    sub count_zipped_combo_vals {
        my %counts;
        seq_foreach_from_spec( \@_, sub {
            seq_foreach(
                seq_zip( ( map seq(split//), @_ ) ),
                sub { $counts{"@_"}++ }
            )
        });
        \%counts;
    }
[download]

Now we can see how will it handles problems of different shapes. We'll try 1-, 2-, and 3-array cases, but the same code should work for any number of arrays greater than zero.

    # a few problem cases to try

    my @site1 = qw( AATKKM aatkkm        );
    my @site2 = qw( GGGGGG gggggg        );     
    my @site3 = qw( XXXXXX ++++++ yyyyyy );
    # ... and so on ...

    my @sites = \( 
        @site1, @site2, @site3, # ... and so on ...
    ); 

    # try 1-, 2-, and 3- array cases
    print Dumper( count_zipped_combo_vals( @sites[0..$_] ) )
        for 0 .. $#sites;


    # $VAR1 = {
    #           'A' => 2,
    #           'k' => 2,
    #           'a' => 2,
    #           'M' => 1,
    #           'T' => 1,
    #           'K' => 2,
    #           'm' => 1,
    #           't' => 1
    #         };
    # $VAR1 = {
    #           'K G' => 2,
    #           'A G' => 2,
    #           'm g' => 1,
    #           'a g' => 2,
    #           'A g' => 2,
    #           'M G' => 1,
    #           'k g' => 2,
    #           'k G' => 2,
    #           'T G' => 1,
    #           'a G' => 2,
    #           'm G' => 1,
    #           't G' => 1,
    #           'K g' => 2,
    #           'M g' => 1,
    #           't g' => 1,
    #           'T g' => 1
    #         };
    # $VAR1 = {
    #           't G y' => 1,
    #           'T G +' => 1,
    #           'K G X' => 2,
    #           'a G X' => 2,
    #           'm G +' => 1,
    #           'a G +' => 2,
    #           'T g y' => 1,
    #           'm g +' => 1,
    #           'a g +' => 2,
    #           'k G X' => 2,
    #           'a g X' => 2,
    #           'm g X' => 1,
    #           'T g X' => 1,
    #           't G +' => 1,
    #           'M G y' => 1,
    #           'k g y' => 2,
    #           't g y' => 1,
    #           'm G X' => 1,
    #           't G X' => 1,
    #           'K G +' => 2,
    #           't g +' => 1,
    #           'a g y' => 2,
    #           'T G X' => 1,
    #           'm g y' => 1,
    #           'm G y' => 1,
    #           'A G X' => 2,
    #           'M g +' => 1,
    #           'k g +' => 2,
    #           'k g X' => 2,
    #           'A g X' => 2,
    #           'A g +' => 2,
    #           'M g y' => 1,
    #           'k G +' => 2,
    #           'a G y' => 2,
    #           'M G +' => 1,
    #           'A g y' => 2,
    #           'K g X' => 2,
    #           'K G y' => 2,
    #           'K g y' => 2,
    #           'K g +' => 2,
    #           'k G y' => 2,
    #           'A G y' => 2,
    #           'T g +' => 1,
    #           't g X' => 1,
    #           'M G X' => 1,
    #           'M g X' => 1,
    #           'T G y' => 1,
    #           'A G +' => 2
    #         };
[download]

Thanks again for taking the time to consider our discussion. I hope that in the end your will find the journey to be the reward.

Cheers,
Tom