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
In reply to Re^12: Scalar context of slice (rules)
by tye
in thread Scalar context of slice
by thenaz
| For: | Use: | ||
| & | & | ||
| < | < | ||
| > | > | ||
| [ | [ | ||
| ] | ] |