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.

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?

--
Online Fortune Cookie Search
Office Space merchandise

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.

Of course, it would be great if everyone could shed even that level of simplicity

In a word, "why"? Why would it be great if everyone learned what happens when perl interprets Perl even past that point? Why is that condition so obviously better than allowing people to get work done with a tool without understanding how the tool is built that you feel the need to say, "Of course"?

Isn't the point of having the tool so that the users don't need to think about the lower level while they are using it? Sure, it's beneficial for people who use a tool often for big projects to understand the tool and even to be able to improve the tool. However, most people who use a tool never build or modify the tool itself. This is not true of only software.

Do you drive? Can you adjust the valve timing on your car? Have you hung a picture? Have you ever made a hammer? Did you build your own kitchen cabinets or your own bed? Can you build and repair a refrigerator so that you can keep food cold?

Is the "operators provide context to their operands" pattern of thought really what all programmers are doing when they program in Perl, or is it something perl does for them so they don't have to worry about it?

Is the "operators provide context to their operands" pattern of thought really what all programmers are doing when they program in Perl, or is it something perl does for them so they don't have to worry about it?

Well, perl provides the context (to the operands), but it's something programmers have to consider. But that's not any different then that in $a + $b, perl does the addition, but the programmer has to consider the result, and realize that it's usually different from $a * $b.

Context is an integral part of Perl programs. perl will do the handling behind the screens, telling each operator/function which context it is in - but it's the programmer who has to consider the difference between having the operator/function in the various contexts in can be in.

In most simpler syntactic constructs, though, I think perl just does what the author of the code expects with the Perl they wrote. In the interests of maintainability, most of the more complex issues of context don't come up in most of the code I write or see from others.

There are a few immensely important idioms that make use of mixing expressions in list and scalar context in the same statement very useful, but if one thinks of them as "idioms", they're likely not to question the specifics. An idiom is something that doesn't necessarily translate directly to other languages by definition, after all.

We've been using contrived examples in which we're taking the length of static-length lists. They could have been arrays, but those arrays still could have had their lengths computed in a separate statement.

Knowing how the tool was built isn't the issue; knowing what it does is.

Is the "operators provide context to their operands" pattern of thought really what all programmers are doing when they program in Perl, or is it something perl does for them so they don't have to worry about it?

The former. Programming is arranging operators to do what you want and return what other operators need. If that's not what you (generic, not any specific individual) do when you program, you're just making stuff up and hoping it does what you want. And we see a lot of that here, and that's really the core of why I think the least specific model is worth challenging.
--
Online Fortune Cookie Search
Office Space merchandise

Programming is arranging operators to do what you want and return what other operators need. If that's not what you (generic, not any specific individual) do when you program, you're just making stuff up and hoping it does what you want. And we see a lot of that here, and that's really the core of why I think the least specific model is worth challenging.

That's an entirely fair reason to challenge it. If you honestly think it is impairing someone's ability to understand what they are actively doing, that's in fact a very good reason to challenge it.

Now, of course, I have my usual and obvious question: Why do you think modeling the language using the abstraction so many people seem to prefer actively hinders their ability to arrange the operators to do what they want (in that abstraction) and return what they need (in that abstraction)? Perhaps it does hinder that understanding, but I have yet to read a solid explanation of how it does or why.

BTW, what a car does is move you from place to place at a relatively quick pace in relative safety and comfort. How it does it is usually by taking in air, mixing it with a combustible liquid fuel, compressing the mixture, sparking that mixture to drive a piston which drives a crank which both moves the near end of the transmission (which also moves the piston to compress the next dose of mixed fuel and air upon the firing of another cylinder) and a cam which operates the valves to get rid of the exhaust. It uses oil to lubricate, water to cool, and antifreeze to keep the water from freezing. How much past gas, oil, water, antifreeze must a driver know?