I really have to wonder why are you even using Perl in the first place; it gives people way too much rope, FP or not.

No one I know had even heard of Viaweb before Paul Graham began touting it as a "success story for Lisp"!

And that proves what, exactly? “Noone I know has” is a classic case of unrepresentative sample.

The first example is "more clever", and more typical of the FP crowd.

The other Anonymonks have already called you out on that one; this is a straw man.

Quit the fallacies.

Makeshifts last the longest.

I really have to wonder why are you even using Perl in the first place; it gives people way too much rope, FP or not.

Well, the guy doing the maintenance doesn't get to choose the language he maintains.

And that proves what, exactly? “Noone I know has” is a classic case of unrepresentative sample.

In response to a single example anecodote, I didn't feel it was out of place.

The other Anonymonks have already called you out on that one; this is a straw man.

I still don't think so; every single definition of a function in List::Util explains the function in terms of reduce(), implying that if you'ld only use reduce() for everything, you wouldn't need all these other functions.

Quit the fallacies

Quit the hypocrisy. You and I both know that FP isn't mainstream, and that it's been a known technique for well over fifty years, and that there are damn good reasons for it. This is a known argument; it's been proven, it's DONE. If you want to retread fifty-year old ground, you go do it: you know you're wrong, and I'm getting tired of the trolling, and the miscategorization of my posts.

every single definition of a function in List::Util explains the function in terms of reduce(), implying that if you’ld only use reduce() for everything, you wouldn’t need all these other functions.

That seems like a stretch. In the documentation I’m looking at, the reduce analogy always follows last, after an explanation of what the function in question does. The way I see it, it’s there as a guide in case you need to do something slightly different from what the builtin function does.

You and I both know that FP isn’t mainstream, and that it’s been a known technique for well over fifty years, and that there are damn good reasons for it.

There was a long-standing debate over whether structured programming was better than GOTOs in times past. When object-orientation was first championed by C++, its benefits had to be sold to each developer and manager individually.

Draw your own conclusions about what I think of your argument.

The damn good reasons are in the silicon, not the carbon.

Makeshifts last the longest.

I really have to wonder why are you even using Perl in the first place; it gives people way too much rope, FP or not.

How is making things worse going to rectify that flaw?

And that proves what, exactly? “Noone I know has” is a classic case of unrepresentative sample.

A sample size of one was hardly representative to begin with. No one has presented an argument to explain when and why the majority of industry moved towards functional programming; that's of course, because it hasn't ever done it, despite ample opportunities. Prove it for yourself if you don't believe me; I think you'll find everything from operating systems to databases to web browsers written in an imperative or object oriented style. A single example, (which later reverses itself), is hardly compelling evidence of the superiority of functional programming in industry.

The other Anonymonks have already called you out on that one; this is a straw man.

No, it isn't. The List::Util system is quick to explain how all these typical functions can be implemented using reduce(), and that reduce() is the only function you really need.

An approach that contrasts the approach advocated by the reduce-is-everything FP crowd was exactly what I contrasted with a normal, non-clever approach.

Quit the fallacies.

Fine. Why don't you quit your own, then? Quit the self-denial that says that FP is a major industry player, or appropriate for the workplace. Quit the cowboy mentality that goes with FP; the elitist crap that says that since something *can* be made complex, it *must* be made complex. Quit the "lets have fun being clever" approach to code; and go with trying to actually make code simple, obvious, and maintainable. Try professionalism for a change.

Okay, rant over. I doubt I've convinced you of anything, so I quit. You "win".

Quit the “lets have fun being clever” approach to code; and go with trying to actually make code simple, obvious, and maintainable. Try professionalism for a change.

Are you implying that I put obfuscated code in production? Have you seen any code I’ve written? Excuse me while I laugh with gusto.

Have you tried writing callback-heavy code, like, oh, GUIs f.ex., both with closures and without? Do you care to dispute the fact that having closures available makes such code about 100 times easier to write and clearer to read?

Makeshifts last the longest.

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.

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

sub average { sum(@_) / scalar(@_) }
[download]

sub average
{
    my @arr = @_;
    my $average = 0;
    my $length = @arr;

    for(my $x=0; $x<$#arr; $x++)
    {
        $average = $average + $arr[$x]/$length;
    }

    return $average;
}
[download]

You know, ad hominem is bad argument...

One of my best friends is a LISP expert

Yeah, ad hominem is almost as bad as using unsubstantiable anecdotes.

1) No, ad hominem is just plain wrong; honest anecodotes offer evidence about at least one data point.

2) Paul Graham's claims are no more substantiated than my own are. For all you know, I'm lying about my abilities, and my friend has never seen LISP. Then again, for all you know, Paul Graham was lying about the language he wrote his code in, and his software was really secretly written by trained hamsters jumping on keyboards to churn out INTERCAL code.