Beefy Boxes and Bandwidth Generously Provided by pair Networks
Perl Monk, Perl Meditation
 
PerlMonks  

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

by mr_mischief (Monsignor)
on Oct 28, 2008 at 18:41 UTC ( #720064=note: print w/ replies, xml ) Need Help??


in reply to Re^3: If you believe in Lists in Scalar Context, Clap your Hands
in thread If you believe in Lists in Scalar Context, Clap your Hands

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?


Comment on Re^4: If you believe in Lists in Scalar Context, Clap your Hands
Re^5: If you believe in Lists in Scalar Context, Clap your Hands
by ysth (Canon) on Oct 28, 2008 at 18:53 UTC
    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.
      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?

Re^5: If you believe in Lists in Scalar Context, Clap your Hands
by JavaFan (Canon) on Oct 29, 2008 at 11:37 UTC
    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.

Log In?
Username:
Password:

What's my password?
Create A New User
Node Status?
node history
Node Type: note [id://720064]
help
Chatterbox?
and the web crawler heard nothing...

How do I use this? | Other CB clients
Other Users?
Others rifling through the Monastery: (7)
As of 2014-12-18 02:47 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?

    Is guessing a good strategy for surviving in the IT business?





    Results (41 votes), past polls