http://qs321.pair.com?node_id=296864


in reply to Think for yourself.
in thread is the use of map in a void context deprecated ?

Abigail-II: That "three line patch" is one of thousands that bloats Perl. If you want to discourage people from calling this a bad thing, we can't stop you.

With regards to your argument that nobody considers it bad style that the return value of print and other functions are not checked, I disagree. Many people consider it bad style, but see no practical solution to the problem. People have argued for years (on and off) that print should really raise an exception. The matter has never been closed off. It has only been put off.

With regards to your argument that it is really a bug that map in void context creates a list, I find your argument to be faulty. It is only the knowledge that the 3 lines patch has been applied (i.e. intimate implementation knowledge of the language) that has since encouraged people to continue to use map in void context. Intuitively, and according to the original documentation, most reasonable people would assume that a list was created, and would only be pleasantly surprised to find that the case was optimized now so that the list is not created.

With regards to your last argument that calls all people who disagree with you "sheep", and points out that no patch was provided, I think you have missed the point. The people who consider it bad style did not *want* to submit a patch. They did not *want* Perl to be officially implemented to encourage such a bad style. And yet, now that a patch was submitted, and included, this very thing has happened. Respected members of the Perl community such as yourself encourage (or silence the discouragers, which is the same thing) the very odd practice of using a list transformation control structure to iterate through a list.

It isn't as if this sort of practice is un-Perl. After all, Perl is the language that encourages people to use operations like "tr/a/a/" to count the number of a's in a string.

I use Perl because it is practical. I don't use it to ensure that non-Perl-familiar members of the community will be unable to understand my code.

Replies are listed 'Best First'.
Re: Think for yourself.
by Abigail-II (Bishop) on Oct 06, 2003 at 08:27 UTC
    That "three line patch" is one of thousands that bloats Perl.

    If an optimization that only takes three lines "bloats" Perl, then you must have been an unhappy camper ever since Perl 5.000 came out. If you already consider this bloat, how do you feel about statement modifiers? What about having unless? What about short cuts like +=? Or having two kinds of for/foreach, a while, and an until? Shouldn't that be all bloat because we have goto?

    It isn't as if this sort of practice is un-Perl. After all, Perl is the language that encourages people to use operations like "tr/a/a/" to count the number of a's in a string.
    Funny that you bring this one up. For a long time, "tr/a/a/" modified the string it was working on (replacing every 'a' with an 'a'). Noone considered that bad style. And still, after a couple of years, this operation was also optimized. Do you consider that 'bloat' as well?

    I use Perl because it is practical. I don't use it to ensure that non-Perl-familiar members of the community will be unable to understand my code.
    You must have a limited view of the world of programming languages. The non-Perl world is bigger than Java. There are languages in which map like constructs *are* the way to iterate over an array. In fact, I know more languages that use map like constructs to iterate over an array (or list) than I know that use 'for (LIST)'. And outside of Perl, I do not know any that uses 'EXPR for LIST'.

    Abigail

      With regard to my bloat argument, you have purposefully exaggerated your defense by mentioning operators that provide unique benefits that are impractical to not use. += is impractical to not use. Statement modifiers are impractical to not use. Map in void context is not nearly as necessary of a construct.

      With regard to the tr/a/a/ that I mentioned, it isn't funny that I brought this up, nor is it a coincidence. I am admitting that the language has a precident for providing behaviour in un-obvious or circular implementation, that is at some point optimized for general use. Do I consider it bloat? I sure do. I brought it up, after all.

      As for your last attempt to insult me, I suggest you re-think your motivations. I rarely ever use Java. My day-to-day programming at work is almost 100% Perl, and has been for several years.

      You may think Perl is perfect. I don't. I am forced to admit that Perl is practical, and so I use it. Note the difference. Not all the world is Abigail, or Perl. Didn't you just say, in this very thread, "Think for yourself"? I am thinking for myself, and you are criticizing me for it. I suppose "there is more than one way to do it" really means "there is Abigail's range of doing it" and anybody who uses less as a means of improving the quality of the code, is guilty of limited thought. Sheesh.

Re: Re: Think for yourself.
by zengargoyle (Deacon) on Oct 06, 2003 at 05:43 UTC
    my @L = map { fix($_->[4]); fix($_->[8]); [ @$_[0,2,3,6,4,8] ] } grep { @$_ == 10 and ($_->[7] eq 'IP') and ($_->[9] eq 'local') } map { [ split ] } <F>;

    i think map in void context is just fine. if i decided to place my data in a hash for later lookup i just might do so at the end of the first map (instead of returning an array of arrays). i'm sure i wouldn't try and re-craft the code to use a for just to appease.

    much in the same way i use the 'useless' cat in my shell pipelines.

    $ cat foo.txt | fgrep blah

    it's much easier to decide to add more files to the cat (try that with <file ). or to replace the cat with another command that generates the data. why on earth would i continuously rewrite my commands when i can up-arrow and add easily to the beginning?

    $ fgrep blah <foo.txt | consolidate | dump $ preproc <foo.txt | fgrep blah | consolidate | dump $ additional <foo.txt | preproc | fgrep blah | consolidate | dump # vs $ cat foo.txt | fgrep blah | consolidate | dump $ cat foo.txt | preproc | fgrep blah | consolidate | dump $ cat foo.txt bar.txt | additional | preproc | fgrep blah | consolidat +e | dump $ real_stream | additional | preproc | fgrep blah | consolidate | dump

    i'll keep my useless cat and my map in void context thank you much. they're my artifacts of iterative development.

      I don't get it. You haven't used map in void context. Also, I'm not convinced that you haven't purposefully written your code inefficiently just to prove that map is useful. Why do you have the intermediate grep when an if in the for loop would do just fine? Sure, copying lists around is *fairly* cheap, but we come to my original point: Did you actually take a step back before designing your code, to ensure that it works best? Or did you just string map and grep together until it worked the way you wanted it to?

        Iterative development is a style where you write something and then modify it in a series of small iterations until it does what you want.

        Which means that he did indeed string maps and greps together until it worked the way he wanted to. As part of a deliberate coding style.

        I respect that style because it sometimes is mine as well. I've seen it be particularly popular among people who believe in some or all of; test-first development, dynamic programming techniques, and rapid prototyping.

        Proponents will claim that it produces more robust code in less development time. They will not claim that it produces the fastest code in the world, but then again there is no need to optimize what is already fast enough...

      $ fgrep blah <foo.txt | consolidate | dump $ preproc <foo.txt | fgrep blah | consolidate | dump $ additional <foo.txt | preproc | fgrep blah | consolidate | dump # vs $ cat foo.txt | fgrep blah | consolidate | dump $ cat foo.txt | preproc | fgrep blah | consolidate | dump $ cat foo.txt bar.txt | additional | preproc | fgrep blah | consolidat +e | dump $ real_stream | additional | preproc | fgrep blah | consolidate | dump
      First of all, you're using a shell that's not braindead. Take the time to absorb its expressiveness.
      $ < foo.txt fgrep blah | consolidate | dump $ < foo.txt preproc | fgrep blah | consolidate | dump $ < foo.txt additional | preproc | fgrep blah | consolidate | dump
      Yes, that's valid code, go ahead and try. And you still don't need to edit more than one place to add multiple files.
      $ < foo.txt fgrep blah | consolidate | dump $ < foo.txt preproc | fgrep blah | consolidate | dump $ <(cat foo.txt bar.txt) additional | preproc | fgrep blah | consolida +te | dump $ real_stream | additional | preproc | fgrep blah | consolidate | dump
      You don't need crutches in bash. If you need them, something is wrong with your tools.

      Makeshifts last the longest.

        i couldn't make your

        <(cat file ...)
        example to work, but i've seen the nice bash funcionality in the man pages...

        sadly i can rarely use it. most of my co-workers are stuck in csh hell not even willing to go to tcsh for tab-completion and arrow-history, much less bash despite my constant proselytization. we still have old Solaris boxes without bash that will never have bash (but have Perl 5.003 or so). so it's sh/csh compatible only for me...sigh

        that and the whole Linux vs Solaris with all of the different versions of commands that do slightly different things keeps me going to Perl for anything complex.

        when all our boxes are Solaris 9 with bash i promise to study it more.

Re: Re: Think for yourself.
by hardburn (Abbot) on Oct 06, 2003 at 14:15 UTC

    (i.e. intimate implementation knowledge of the language)

    Reading the latest perldelta is hardly "intimate implementation knowledge".

    They did not *want* Perl to be officially implemented to encourage such a bad style.

    Perl has never cared about discouraging "bad" style. If you want that, you'd probably enjoy Python or Java. It's a little late for Perl to start doing the same.

    After all, Perl is the language that encourages people to use operations like "tr/a/a/" to count the number of a's in a string.

    Thanks, I didn't know about that one :)

    ----
    I wanted to explore how Perl's closures can be manipulated, and ended up creating an object system by accident.
    -- Schemer

    Note: All code is untested, unless otherwise stated