So how the heck do you explain this?
-
My son and I often have interesting discussions. Last night was no exception. So I being the geek I am often try to steer the discussion to programming and logic problems. Yesterday we were discussing variable assignments. Something I have notice with other "normal" people. My son is fairly normal even after my influence. (Must be mom). So I as talking about let a=2 and let b=3 So if we add a to b we get what? responses from son ranged from "ab" or "c" I then went into the whole memory address thing where a is just a name for a pointer to a memory address area where the value of "a" is stored. Soon as I asked for the value of "a". His response. "The value of "a" is always "a" right?" *sigh* no "a" is just the name for the pointer to the memory the variable name we use for then storing that value we will use later. "Well why not just type in 2+3 if you are going to add 2 and 3 together?" Ideas? I didn't get anywhere.
To err is human to really mess up you need a computer
Algebra is a topic that comes later in a child's life because it is a hard concept to grasp. Then you try to tie in the mechanics of a computer that I've seen adults struggle to comprehend. No wonder you are feeling a little under water right now. A computer program ties a process with values that are unknown until supplied. Basically, algebra coded in a computer. This is a tough sale for any newbie. A=2 AB=10 What is B? You have to explain AB is shorthand for A*B, he has to understand multiplication and division, he has to understand substitution, he has to understand the wonder of being able to figure out the value of B without ever being directly told what it is and the processes he followed to find out what B is without ever being directly told what it was. Then, that you could do the same thing with computers. You start too young you may turn him off to math for good.
-
All of your statements are true, and I agree with them as well, for the most part. However, my kid chooses to be what they want, not me. If you need to explain something to someone, and it is turning out to be work, then it may not need to be explained. Frankly, variable assignment discussions with anyone, including engineers, is just boring. :)
Although I agree with what you say, I feel like it is too early to conclude the kid is not into programming yet. In fact, the question it asked is absolutely relevant - why would someone have to know all this stuff for memory addresses and so on, if s/he cannot see for any use of this. I mean, if the kid is given an example - for instance to have some formula, that must be evaluated for a bunch of different values, then it would start making more sense to think of all the same operations that otherwise would be too repetative as a single formula with different digits(values). My point is that the kid just needs a good example, and I am willing to think when he grows older, he will understand this better - not only why and how it works, but when it is used and why.
-
My son and I often have interesting discussions. Last night was no exception. So I being the geek I am often try to steer the discussion to programming and logic problems. Yesterday we were discussing variable assignments. Something I have notice with other "normal" people. My son is fairly normal even after my influence. (Must be mom). So I as talking about let a=2 and let b=3 So if we add a to b we get what? responses from son ranged from "ab" or "c" I then went into the whole memory address thing where a is just a name for a pointer to a memory address area where the value of "a" is stored. Soon as I asked for the value of "a". His response. "The value of "a" is always "a" right?" *sigh* no "a" is just the name for the pointer to the memory the variable name we use for then storing that value we will use later. "Well why not just type in 2+3 if you are going to add 2 and 3 together?" Ideas? I didn't get anywhere.
To err is human to really mess up you need a computer
Perhaps you are expecting him to run before he can walk? Teach him the basics of algebra and then a + b = 5 should be intuitive. I know we live in an age where logic supposedly triumphs, but teaching things to young people so that they become intuitive makes life a lot easier down the line. When I started writing applications at 13/14 I didn't have any problems at all with such statements because I already had a basic understanding of algebra, hence defining and manipulating variables was already second nature. After all, the use of such variables in computer science was based on mathematics, so why not teach things in the order they happened?
-
My son and I often have interesting discussions. Last night was no exception. So I being the geek I am often try to steer the discussion to programming and logic problems. Yesterday we were discussing variable assignments. Something I have notice with other "normal" people. My son is fairly normal even after my influence. (Must be mom). So I as talking about let a=2 and let b=3 So if we add a to b we get what? responses from son ranged from "ab" or "c" I then went into the whole memory address thing where a is just a name for a pointer to a memory address area where the value of "a" is stored. Soon as I asked for the value of "a". His response. "The value of "a" is always "a" right?" *sigh* no "a" is just the name for the pointer to the memory the variable name we use for then storing that value we will use later. "Well why not just type in 2+3 if you are going to add 2 and 3 together?" Ideas? I didn't get anywhere.
To err is human to really mess up you need a computer
Try this - write down the math problem in this fashion: 1. 2 + __ = 5 - What is the answer? (3) Then: 2. __ + 3 = 5 - What is the answer? (2) Then: 3. 2 + b = 5 - What is the answer? (b = 3) Then: 4. a + 3 = 5 - What is the answer? (a = 2) Then: 5. if a = 2, then a + 3 = 5, and if b = 3, then 2 + b = 5 Then: 6. if a = 2, and b = 3, and if a + b = c, then c = ? What does "c" equal? If he doesn't get it by this point, then he just isn't ready for simple algebra, and should go back to playing with clay (nothing wrong with this, btw - he just may not be mentally ready). Keep the problem handy, and try it again in a year. Good luck.
-
My son and I often have interesting discussions. Last night was no exception. So I being the geek I am often try to steer the discussion to programming and logic problems. Yesterday we were discussing variable assignments. Something I have notice with other "normal" people. My son is fairly normal even after my influence. (Must be mom). So I as talking about let a=2 and let b=3 So if we add a to b we get what? responses from son ranged from "ab" or "c" I then went into the whole memory address thing where a is just a name for a pointer to a memory address area where the value of "a" is stored. Soon as I asked for the value of "a". His response. "The value of "a" is always "a" right?" *sigh* no "a" is just the name for the pointer to the memory the variable name we use for then storing that value we will use later. "Well why not just type in 2+3 if you are going to add 2 and 3 together?" Ideas? I didn't get anywhere.
To err is human to really mess up you need a computer
Your 'test program' makes the mistake to immediately define all inputs, and your son immediately optimized away the need for variables (good job! ;-) ) By providing the inputs, you immediately nixed the reason for writing the program, and your son understood that (clever guy! ;P ) Maybe you've started it all wrong: you basicaly asked your son to play the role of the computer/debugger. Instead he played the role of an interpreter, that's why he doesn't understand the hassle of 'a' and 'b'. It would be better to first confront him with an actual problem that introduces the idea to use an abstract container (a variable). E. g. evaluate football results from a list of matches. Sometimes you need to do repetitive calculations, and that is where variables come in handy...
GOTOs are a bit like wire coat hangers: they tend to breed in the darkness, such that where there once were few, eventually there are many, and the program's architecture collapses beneath them. (Fran Poretto)