First of all, LISP hasn't been a total failure commercially. Viaweb aka Yahoo! Store comes to mind first.

No one I know had even heard of Viaweb before Paul Graham began touting it as a "success story for Lisp"! Erlang is the closest thing I've heard to a "success story" for FP; and it's an isolated case. Unix isn't written in LISP; Windows isn't written in LISP; in fact, all those horrible old LISP machine OS failed to compete with C. systems for decades. Functional programming isn't new. It's been the "latest, greatest thing" for the last fifty years or so. It's still not worth the hype, IMHO.

it was rewritten a few years ago in Perl/C++. Though I think that was more because they lacked in-house expertise once Paul Graham left.

Code that relies on individual heroics doesn't scale; that's part of my objection to functional programming. If you need to be able conceputalize the current state of sixteen different helper functions in order to keep the state of the function clearly in your head, you're probably going to fail, unless you're very smart. And when you leave, your replacement won't be, and the company will tank completely.

And just because you have trouble groking map and other functional code, that doesn't mean it wouldn't make perfect sense to someone who thought differently or had a better grasp on the subject.

You know, ad hominem is bad argument. :-( And while I may not be the best Perl programmer, I have been programming for a while (professionally since 1991), and what's more, I'm a good enough programmer to know my own limitations. I check my assumptions; and I did in this case, too.

One of my best friends is a LISP expert; though he and I disagree violently on the value of functional programming, he agreed in every single case when I asked him (and I asked often) that the functional code I was seeing was just plain bad, wrong, or occasionally, even "insane". Believe what you will of me or my abilities, but it's not just me. The FP devotees claim it's possible to write good FP code, but it's not what happens in the field, in my experience.

Aspects of functional programming are quite useful and a PITA to replicate imperatively.

I disagree. Being forced to reassemble an series of bottom-up self-referential maze of semi-correct function mappings into a single, coherent business rule is far less productive than just reading the imperative rule directly from the code.

Remember, when someone writes code, what they write doesn't matter much: in six months, it will be replaced anyway. The purpose of what they wrote it is critical; and the more layers of abstraction between the business and the code, the harder it is to discern intent.

Would you really rather read: 

sub transform {
    my $coderef=shift;
    reduce($coderef,@_)/(@_+1);
}
sub display {
    printf("Avg: %f",transform(sub { $a > $b ? $a : $b },@_));
}

[download]
OR 
sub display {
    my (@quarterly_results) = @_;
    # compute the arithmetic mean (average) of the results
    # for the past four quarters
    printf("Avg: %f", average(@quarterly_results);
}

sub average {
    my $average;
    $average = sum(@_)/ scalar(@_);
    return($average);
}

[download]

The first example is "more clever", and more typical of the FP crowd. The second is "stupider", "more boring", and ore typical of my code. I find it easier to follow the business logic, so that when my code breaks, someone can fix it.

Throw in several more layers on the call stack, and the differences become even more pronounced; when the return value of a function is literally composed of a hundred little calls to other functions, each of which tampers with different states of different variables in different scopes, it's really, really hard to reconstruct what's being done, let alone WHY. True, that's not pure FP (lots of side effects), but it's what perl supports as FP, and it's what I get saddled with by FP-wannabees.

Encouraging more functional programming will at best lead to more ivory tower code, comprehensible only to the wise few, and at worst to the drek I see lately, where FP concepts are tangled with side effects of all sorts of scopes and flavours, and the net effect is a mess uglier than most.

I'm taking a pragmatic point of view: it's like if you serve alcohol at a bar, you hire bouncers. There's no reason, in principle, why people can't be rational, reasonable adults when they drink, and conduct themselves well, and leave when asked. In theory, you won't find piles of vomit all over the floor. In practice, you'ld better get the bouncers out and the puke buckets ready! Adding alcohol in the form of FP to Perl might be fun for you, but for me it just means more code puke to clean up.

--
Ytrew

In reply to Re^5: RFC: Should join subsume reduce? by Anonymous Monk
in thread RFC: Should join subsume reduce? by Roy Johnson

Title:
Use:  <p> text here (a paragraph) </p>
and:  <code> code here </code>
to format your post, it's "PerlMonks-approved HTML":


  • Posts are HTML formatted. Put <p> </p> tags around your paragraphs. Put <code> </code> tags around your code and data!
  • Titles consisting of a single word are discouraged, and in most cases are disallowed outright.
  • Read Where should I post X? if you're not absolutely sure you're posting in the right place.
  • Please read these before you post! —
  • Posts may use any of the Perl Monks Approved HTML tags:
    a, abbr, b, big, blockquote, br, caption, center, col, colgroup, dd, del, details, div, dl, dt, em, font, h1, h2, h3, h4, h5, h6, hr, i, ins, li, ol, p, pre, readmore, small, span, spoiler, strike, strong, sub, summary, sup, table, tbody, td, tfoot, th, thead, tr, tt, u, ul, wbr
  • You may need to use entities for some characters, as follows. (Exception: Within code tags, you can put the characters literally.)
            For:     Use:
    & &amp;
    < &lt;
    > &gt;
    [ &#91;
    ] &#93;
  • Link using PerlMonks shortcuts! What shortcuts can I use for linking?
  • See Writeup Formatting Tips and other pages linked from there for more info.