learning to program
One of the first things that you need to do if you want to learn to program is to look at the connections between syntax and trees and nested parentheses and semantics. We speak to one another (and write to one another) so fluently that it's not obvious that natural language is in some important sense tree-shaped. Someone who has never studied linguistics might be distracted by the (less important) sense in which it is line-shaped - in time (if we are speaking or gesturing) or possibly space (if we are writing).
The tree diagram is nice to have in mind, but it is not terse - it takes a huge amount of visual space. (Oriented) trees are isomorphic to sequences of balanced parentheses - ((()())(()())) is like a tree with seven nodes. If we have words labeling each node of the tree, then on the balanced parentheses side we get something like this: top(left(ll(), lr()), right(rl(), rr())).
It is nice to be able to walk back and forth. One direction is from ordinary language to trees to balanced-parentheses representing trees in order to generate (a starting point for) code. The other direction is from at-first-inscrutable formal text to trees and from trees to some natural-language pronunciation of the formal text in order to read and have at least a stab at understanding code that someone else wrote.
After that basic step, there are a lot of "next steps". One important next step is learning to learn - how to search for information in an archive, how to learn how something works by experimenting with it, how to feel more subtle emotions about your own ignorance than simple despair or simple overconfidence. Another important next step is learning about how the world is put together - How did this text get onto this screen? How are parsers typically constructed? How does the internet work? What is a von Neumann computer? A third important next step is learning abstraction techniques. The first abstraction is procedures - I think staying away from objects and classes is a good idea for a while (and there are plenty of other abstractions beyond those). However, it might be that all of those can be learned "accidentally" while trying to complete various programming tasks.
It's sad that there are not more diverse fun learn-to-program domains; there is drawing, including subvariants of turtle graphics and vector graphics similar to PostScript or Processing. There is the console interface. There are innumerable kinds of tank battles. There is Core Wars. I don't know of any fun database-backed-business domains, even though they would be really educational. There don't seem to be lots of bioinformatics or nano/biotech oriented games - there's FoldIt and Organic Builder and SpaceChem.
The tree diagram is nice to have in mind, but it is not terse - it takes a huge amount of visual space. (Oriented) trees are isomorphic to sequences of balanced parentheses - ((()())(()())) is like a tree with seven nodes. If we have words labeling each node of the tree, then on the balanced parentheses side we get something like this: top(left(ll(), lr()), right(rl(), rr())).
It is nice to be able to walk back and forth. One direction is from ordinary language to trees to balanced-parentheses representing trees in order to generate (a starting point for) code. The other direction is from at-first-inscrutable formal text to trees and from trees to some natural-language pronunciation of the formal text in order to read and have at least a stab at understanding code that someone else wrote.
After that basic step, there are a lot of "next steps". One important next step is learning to learn - how to search for information in an archive, how to learn how something works by experimenting with it, how to feel more subtle emotions about your own ignorance than simple despair or simple overconfidence. Another important next step is learning about how the world is put together - How did this text get onto this screen? How are parsers typically constructed? How does the internet work? What is a von Neumann computer? A third important next step is learning abstraction techniques. The first abstraction is procedures - I think staying away from objects and classes is a good idea for a while (and there are plenty of other abstractions beyond those). However, it might be that all of those can be learned "accidentally" while trying to complete various programming tasks.
It's sad that there are not more diverse fun learn-to-program domains; there is drawing, including subvariants of turtle graphics and vector graphics similar to PostScript or Processing. There is the console interface. There are innumerable kinds of tank battles. There is Core Wars. I don't know of any fun database-backed-business domains, even though they would be really educational. There don't seem to be lots of bioinformatics or nano/biotech oriented games - there's FoldIt and Organic Builder and SpaceChem.