Re^7: RFC: Should join subsume reduce?

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.

Comment on Re^7: RFC: Should join subsume reduce?

Replies are listed 'Best First'.
Re^8: RFC: Should join subsume reduce? by Aristotle (Chancellor) on Feb 25, 2006 at 00:52 UTC
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.	[reply]

Replies are listed 'Best First'.

Re^8: RFC: Should join subsume reduce?
by Aristotle (Chancellor) on Feb 25, 2006 at 00:52 UTC

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.

[reply]