Experiment: Duby
OK, local variables, neat trick…but maybe you’re wondering, “What’s the point?” Legitimate question, but it’s kind of hard to see the point without considering what it would be like without local variables. It’s like if you’d never seen a seatbelt, and I’m here telling you all about the different tension mechanisms, how it connects to the car, and the different kinds of latches, and you’re all, “And the point is…?” Well, imagine a world without seatbelts. You get in a wreck. You fly out the window. You die.
The negative consequences of programming without local variables are certainly not as dramatic, but neither are they as easily explained. To get a feel for life without locals, let’s imagine a fake language called Duby (for Dumb Ruby).
Duby is just like regular Ruby, except that all variables live in the same scope (that is, they have the same visibility). There’s no idea of local or global. Let’s say we wanted to make a method to square a number:
def square x |
puts(x * x) |
end |
Now we’ve used the variable x here, but we’re just using it as a placeholder. What I mean is, we could just as well have used y or my_fabulous_number; it should make no difference, right? The whole point is to say that the square of something is just “something times something.” That’s the abstraction that methods provide. In this particular case, no matter what variable you are squaring, “the square of something” simply means “something times something.” That’s what you’re trying to say when you define this method.
Now let’s say, in Duby, you wrote this:
x = 5 |
square x |
Now at this point, assuming you defined square like we did earlier, then x is pointing to 5, before and after we called square. No problem.
And what about this program (again, in Duby)?
my_number = 5 |
square my_number |
Basically it’s the same program, just with a different variable name. Now my_number is pointing to 5. But what about x? What is it pointing to?
I guess it would also have to be 5. In order to use the square method, the value passed into it (5, pointed to by my_number) needs to be assigned to x (that is, have x point to it) before you can run the x * x code. So, x is 5. So far, so good.
Now consider this code:
x = 10 |
my_number = x / 2 |
square my_number |
In this case, my_number is half of x (so it must be 5), but that means x must also have been set to 5 when we called square, even though we had just set it to 10. And this is the big bad: calling the square method displays the squared value, but it also has the nasty side effect of resetting x to be whatever was passed in. This is Just Plain Wrong. I mean, x used to be 10! Now it’s 5! This is insane.
What if we don’t want any of our variables to be changed? What if we just want to display the square of whatever number we pass in? Can we get around the problem of the unintended side effects? Maybe.
We could start defining all of our methods like this:
def square liauwechygfakcuewhalcufe |
liauwechygfakcuewhalcufe * liauwechygfakcuewhalcufe |
end |
And we could just hope that we don’t use liauwechygfakcuewhalcufe anywhere else in the program, but that hardly seems ideal. ☺ I’m not going to write code like that, and neither should you. Can’t we do better than this?
What if the x used in the square method was a different x, a totally private x that we use only for the square method; it doesn’t mean “the x you were using.” It’s just a temporary name for this value. It’s just a local variable.
That’s exactly what Ruby does. (And just about every other programming language.)