in reply to Re^11: Scalar context of slice (vs grep)
in thread Scalar context of slice

Your references to rules of thumb and "baby Perl" would make sense here if we had a simple model that worked okay and I offered a much more complex model that worked better.

I'm not trying to force the whole of Perl into anybody's head. I only just recently brought up one more piece of Perl: list assignment. Before that, I was only talking about the original subject matter, slices and map/grep. And I have yet to see how my proposal is the most complex one. I simply propose that operations choose what to return in a scalar context. I don't add complexities about "this is a list" or "that returns a list" or "these are like subroutines" or "those don't build a list on the stack behind the scenes and so they don't really 'return a list'" or "these can't be easily replaced by user code". So we have several complex models that don't work except for a few cases and a cleaner, simpler model that doesn't run into those problems.

I am pointing out that there is complicated and imprecise baggage being thrown around and some might wish to stop complicating their thinking and explanations and discard it, especially because it will lead them and/or others astray as it has before. A better analogy than Newton or "baby Perl" would be comparing the idea that the world is flat and is held up by four elephants positioned at each corner and those are standing upon a giant turtle vs. the idea that the world is a ball floating in space.

Sure, trying to get the point across to somebody who believes the world is flat isn't as simple as "um, the world is a ball floating in space. got it?" So the explanation of "no, it is simpler than that. really." can take some work and, depending on what arguments are thrown up against it, can get complicated. The difficulty in demonstrating that the simpler explanation is more accurate or even to convey how it is actually simpler is a separate complexity.

I'm not sure of the harm

The harm has been explictly stated and then echoed by you; the idea leads to incorrect conclusions ("which may not hold when you dig a little deeper"), leads to mistaken expectations, confusion, wasted time, etc. That can certainly be an acceptable cost... if there is some gain. The gain in the examples you offer is the gain of much greater simplicity.

other than annoying you

Please don't try to tell me my emotional state based on some text you read that never mentioned emotions. But at least you've made a self-fulling prophecy. You have managed to annoy me now.

I know from my history of interacting with you that ETOOMUCHMAGIC [...] appears to be one of your pet peeves.

I've certainly mentioned ETOOMUCHMAGIC before. But telling me what is a "pet peeve" of mine I also find quite presumptuous and dismissive. I'll also note that your assessment that this is somehow ETOOMUCHMAGIC rather badly misses what I mean when I use that term anyway.

You are certainly free to choose to dismiss what I am trying to explain as a mere emotional response to some pet peeve. What a waste of my time that would be. Somewhere I got the impression that on rare occasions, people would come together to discuss nearly any aspects of Perl in an attempt to better understand it. I wonder where that place was.

- tye        

Replies are listed 'Best First'.
Re^13: Scalar context of slice (rules)
by mr_mischief (Monsignor) on Oct 09, 2008 at 19:22 UTC
    I'm sorry for annoying you. You can be annoying to me sometimes, too, both of which are beside the point. I'm sorry for making assumptions about your line of thought, but you've done the same to multiple other people in this very thread1,5. All of that is beside the point.

    The point is that you have what you say is a very simple way to describe the situation. merlyn in the same thread very simply stated that explanation and linked to a pointer in one of his columns. Your nodes have not been simply pointing out that explanation, but actively criticizing the explanations of others. merlyn managed to promote the same view of the problem without all the drama.

    You appear -- and I'm trying hard not to assume this so please correct me if my interpretation of your writing is incorrect -- you appear to be saying that anyone on PerlMonks should be assumed to be ready for the most straightforward explanation2, and that we should backpedal and teach them how to be ready for that knowledge when explaining things if their personal frame of reference does not prepare them for it. The opposite assumption is being made by others -- that if someone asks a question which appears to be towards a beginner's thinking that one should try to teach the next rule and exception up the chain3. What proof does either side have? Do you have support for the superiority of your stance or the supposed harm done by the other? Are you so sure what you infer4 about the concept (sorry, "meme") presented by FunkyMonk is in fact inferred by others and is actually harmful?

    Footnotes in the readmore... they discuss the noted issues at a little more depth.

      I'm sorry for making assumptions about your line of thought, but you've done the same to multiple other people in this very thread

      Communicating without assumptions is laborious, perhaps impossible. I was annoyed at you for stating assumptions about my emotional state, especially in a dismissive manner.

      You appear -- and I'm trying hard not to assume this so please correct me if my interpretation of your writing is incorrect -- you appear to be saying that anyone on PerlMonks should be assumed to be ready for the most straightforward explanation

      It appears that you may be way over-thinking this. I saw an explanation given that included unnecessary complication and that complication also had the distinct disadvantage of having lead other people into problems. I pointed out the conflict in this added complication. The author didn't understand. I tried to highlight the trouble with it a different way. Not much to this.

      When points were expressed to refute my assertions about these conflicts or to criticize the accuracy of my explanations, then I responded to them. Several other criticism and arguments were also thrown in that I tried to mostly ignore. The assertion of there being advocation of "there is one true abstraction" was one such tangential point made and I already noted that I have not been proposing such. So, no, I'm not proposing "one true explanation" to be used for any PerlMonk.

      As for the rest of your post above, I have read it. It mostly convinces me that you did not "get" most of my points (which, just to be clear, is not something I would choose to blame you for) and so futher discussion seems unlikely to result in an increase of understanding between us so I will likely choose to not spend more time on such.

      - tye