I'm sorry if it read as if I thought you did jump on anyone. That was not my intention. I meant "you" in a plural number as those who have been holding up the explanation you offer as a group. I was not clear enough at that, and I apologize.
My issue in this debate isn't that people have a preferred abstraction, that they claim the issue is clearer without any abstraction at all, nor that they will state the advantages of one and the disadvantages of the other. My primary issue is that people seem to be overlooking the background necessary to understand the alternatives vs. the stated drawbacks of the abstraction at hand. My secondary issue is that those of us defending the use of what may be an unorthodox abstraction are being wrongly ascribed some firmly held wrong belief about how perl actually works.
I've been called dismissive in these two threads. That may be fair, but I'm not the only one here capable of that. It can seem that some of those who know how perl interprets Perl intimately are dismissive of all the education, training, and experience it took for them to get to that point. They expect that as a base level for useful discussion of syntax and semantics, which I think may show a disconnect between them and the people who depend upon this "rules and exceptions" abstraction for how Perl (with no mention of perl itself) deals with "lists" (in the plain English meaning with no idea of "list value" vs. "list context" vs. "syntactic sugar list of scalars").
I think some folks have been dismissive of abstractions that are too far from the interpreter (without, IMO, being too far from describing what can be said to be happening within Perl, the language). I also think some have made up their minds a bit too early about those of us who are suggesting a strictly imprecise abstraction can still be accurate enough within a certain mental model and have been discounting our statements because they don't immediately see the merit.
I think that some people are not willing to give up their mental model at a particular moment, even if they are willing to do so in the future. I think dismissing the idea that people really do prefer to build on a partly false model can be harmful. I think insisting to them that they learn from the question they are asking back down through a different set of basic ideas than what they have already learned can be counterproductive.
I think some monks have, probably unintentionally, been somewhat narrow-minded in thinking that because a model more accurately describes what actually happens that it is necessarily more useful to the person using the model. I think some of them could have been a bit more polite in stating their case, too. I'm sorry if I seemed to group you into those.
I do not think anyone, even Larry or Damian, knows how every single Perl programmer would best go through the learning process about the language. Sure, they can tell you what really happens in the code. They can tell you in what terms they think about it. They can tell someone what abstraction seems to be helpful to most people from their experience, or which matches their own ideas the closest. Yet if they would say that someone with a certain level of understanding will always be helped or always be harmed in gaining their next bit of understanding about using the language by one particular idea and point of view, then they would probably be wrong. Certain abstractions may help more people than others, but how does one know which helps a certain individual more without presenting more than one?
In reply to Re^20: If you believe in Lists in Scalar Context, Clap your Hands
by mr_mischief
in thread If you believe in Lists in Scalar Context, Clap your Hands
by gone2015
| For: | Use: | ||
| & | & | ||
| < | < | ||
| > | > | ||
| [ | [ | ||
| ] | ] |