Re^4: If you believe in Lists in Scalar Context, Clap your Hands

[BrowserUk]

That's the obvious answer.

Outside of women's fashion, I don't see much wrong with the obvious :)

Beyond the obvious, because a simpler story makes for easier learning.

For the proof of that, you'd have to read the quotes, and preferably the whole chapter they were drawn from. He makes the case better than I ever could. In particular, see the "French air-traffic controller" example to see how the ridged application of correctness can take a disastrous toll on productivity.

The 'no such thing' model just doesn't stand up to either the novice users hands-on perceptions: print scalar ('a','b','c');, even if that perception were technically flawed--which by your own testimony it isn't--or the reality.

If you're going to go with a known-flawed model, then go with one that fits the users perceptions, and allow them to become aware of and compensate for it's imperfections, as the need arises. Rather than a model that contradicts their perceptions, and requires them to make a huge leap of (either acquired or actual), knowledge, in order to become comfortable with it. Especially as they will have to unlearn either at some future point.

[ysth]

All models are known-flawed, though. But certainly in any kind of learning environment, the particular learners need to be taken into account. I happen to think that anyone willing to debate lists in scalar context falls on the thirsty side. That or the argument for argument's sake side. (Don't look at me like that.)

Isn't much of learning the challenging of perception/preconception?

[mr_mischief]

Yes, much of learning is challenging the perception and preconception.

This is much like those firmly in the "there's no such thing" camp seem to preconceive that everyone exposed to Perl understands "operand", "operator", "side effect", "right associative", the difference in CS between "assigns" and "returns" and the difference of either from the mathematical "yields" (which are not so different in e.g. Lisp as in Perl), and more.

The "no such thing" camp can easily claim conceptual simplicity when they assume an existing foundation upon which those three concepts that keep getting tossed around are based. Three concepts on top of three or four other concepts one must explain first totals more like six or seven concepts.

Please don't assume that I don't understand those terms based on the fact that I say some people don't. That assumption in these discussions has become quite annoying.

Most of the conceptual baggage in the "rules and exceptions" abstraction come after the rule about the last element being returned. Most of the conceptual baggage for the "no such thing" abstraction that more closely resembles what actually happens inside the interpreter comes beforehand. When someone wants to learn one new thing, teaching them six or seven to take their place is not always the best way to handle that.