[1] We don't substitute for the occurrence of balance in the assignment statement because the name in an assignment is not evaluated. If we did substitute for it, we would get 25 = 25 - amount;, which makes no sense.
[2] The phenomenon of a single computational object being accessed by more than one name is known as aliasing. The joint bank account situation illustrates a very simple example of an alias. In section 3.3 we will see much more complex examples, such as distinct compound data structures that share parts. Bugs can occur in our programs if we forget that a change to an object may also, as a side effect, change a different object because the two different objects are actually a single object appearing under different aliases. These so-called side-effect bugs are so difficult to locate and to analyze that some people have proposed that programming languages be designed in such a way as to not allow side effects or aliasing (Lampson et al. 1981; Morris, Schmidt, and Wadler 1980).
[3] In view of this, it is ironic that introductory programming is most often taught in a highly imperative style. This may be a vestige of a belief, common throughout the 1960s and 1970s, that programs that call functions must inherently be less efficient than programs that perform assignments. (Steele 1977 debunks this argument.) Alternatively it may reflect a view that step-by-step assignment is easier for beginners to visualize than function call. Whatever the reason, it often saddles beginning programmers with should I set this variable before or after that one concerns that can complicate programming and obscure the important ideas.
3.1.3 The Costs of Introducing Assignment