in reply to RFC: Should join subsume reduce?

Is there any reason that would be a bad idea?

It would make join() more confusing.

Is it an appealing idea?

Not to me. You're taking a very simple, concrete, useful concept, and confounding it with a very abstract, complicated, and silly one. I can describe the purpose of a join in a single sentence: it joins together a list of stuff into a single string, using a given character as a separator.

I can't do that with reduce(), because what reduce is useful for varies wildly depending upon the helper function I give it. All I really know is that it produces some sort of summary statistic as a scalar from a list; which isn't that descriptive or helpful.

I don't like it. Taking something very simple and making it terribly complex is not the way perl should go, IMHO. Perl is hard enough to understand; there's too much overloading of concepts as it is. Making it worse is just, well, worse. ;-) --
Ytrew

Replies are listed 'Best First'.
Re^2: RFC: Should join subsume reduce?
by Roy Johnson (Monsignor) on Feb 21, 2006 at 21:07 UTC
    I'm not entirely clear what your objection is. Are you saying that it would become terribly difficult to read code, because you wouldn't know what form of join was being called? If that's your concern, the general-reduce version could be limited to when join is called with an explicit block: 
    join { $a + $b } @list; # Computes the sum of the list
join foo, @list;        # builds a string in the old-fashioned way, ev
+en if foo returns a coderef

    [download]
    I think that restriction is a Very Good Idea.

    If you think it would require you to write joins in a new and unfamiliar way, you've simply misread my proposal.

    If you hate the idea of people writing reduce expressions, and are afraid this would encourage it, I'm afraid that cow is already out of the barn. It's a fundamental function for array processing; a built-in one in many languages. The fact that it's included in List::Util (and that so many of the functions therein are merely applications of it) indicates that it's generally considered useful rather than silly. I don't consider it particularly abstract or complicated, either; certainly no more so than map.

    Caution: Contents may have been coded under pressure.
[reply]
[d/l]
[select]
      You're making the definition of the function more complex. It no longer does one single thing; it now does different things when called in different contexts.

      If you hate the idea of people writing reduce expressions, and are afraid this would encourage it, I'm afraid that cow is already out of the barn. It's a fundamental function for array processing; a built-in one in many languages.

      That cow is called "LISP", and it's been the toy of academics, and a total commerical failure, for approximately the last fourty years. The fundamentals of functional programming haven't changed since then. It's still too abstract, too pointless, and too far removed from the actual imperatives of daily life (there's a reason we think in an imperative style -- it's how we live).

      Don't get me started on map() -- I've seen more twisted code written using map() idioms than any other. In general, when I see a map() statement, I have to mentally start refactoring, because odds are, the code won't work.

      90% of the time, I'm right. People who use map() tend to be too clever for their own code, and write 80% solutions that have to be re-written from scratch to actually solve the real problem at hand. Maybe you're smart enough to pull off a functional language, but I've been bitten by too many people who weren't to be impressed.

      So, if you want to program in a functional language, do so. But don't ruin perl any more than it is already -- God knows how many messes I've had to clean up thanks to overzelous use of map() statements! :-( I shudder to think what life will be like if reduce() (by any name) becomes part of the perl core! :-(
      --
      Ytrew

[reply]
        While I think changing join is a bad idea, I also disagree with the majority of your points.

        First of all, LISP hasn't been a total failure commercially. Viaweb aka Yahoo! Store comes to mind first. Though 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.

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

        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.

        -Lee
        "To be civilized is to deny one's nature."
[reply]
        The cow is called "List::Util". People seem to like it. People often look for things like min and max, which are reduce-based functions. I'm sorry you find such things pointless and abstract. Perhaps you will one day find a language crippled enough that people can't write bad code in it, and then you will be happy. However, that language will not be Perl. Perl is full of things that do different things in different contexts, and its development trend is to give programmers more power, not to confine them.

        The problem you are dealing with is bad programmers, not Perl.

        Caution: Contents may have been coded under pressure.
[reply]

In Section Seekers of Perl Wisdom