One of the key insights that the HtDP curriculum was designed with was that industrial languages are a poor choice for learning programming. Think about how you learn math. No one drops all of arithmetic on you all at once. You learn one thing at a time. You learn addition first. Then you learn subtraction. You don't talk about negative numbers until you've mastered positive numbers. You need to build up mathematical knowledge piece by piece, layer by layer. Mathematicians are just people who are further along than others in some respect.
Now, some will say that all you need to do is walk through each basic construct in the language to build up understanding. There are two problems with this approach.
First, this misses the point of programming. The point of programming is to solve problems, not learn language features. Language features are instruments for solving problems and expressing their solutions. They're also a notion to help you reason about them.
Second, a full-fledged language will produce inscrutable error messages that will confuse the student. It prematurely drags in concepts that the student is not ready for.
So the HtDP curriculum works with a hierarchy of student languages that give the student the freedom to explore and experiment within a space that is well-defined, well-understood, confined, and comprehensible according to their readiness. Over time, the language of discourse is expanded.
English keywords are not the stumbling block. Plenty of young people pick up programming languages without knowing English. What poses the greatest difficulty from the perspective of the language is having access to the full language all at once. Also, never talk about the computer. Computers are to programmers what telescopes are to astronomers, to borrow from Dijkstra. In the HtDP curriculum, they ban students from talking about the computer, instead preferring "the compiler" or "the interpreter" or whatever. Implementation concerns are dealt with in later courses, because while practically useful, they are incidental to the basic act of programming.
This seems to align almost exactly with Hedy's methodology. The translation aspect of the curriculum is nearly an afterthought in comparison to how much work was put into developing simple lessons that teach one thing at a time, asking students to solve problems of increasing complexity using the tools as they're introduced.
Start with printing text, then add echoing input, then variables, then lists, working up pretty quickly to very simple shape drawing and graphics, and in a flash students have all the building blocks to make a fun little game or interesting experience.
Thank you, this really validates the Hedy approach. Everyone's talking about the multilingual aspect while ignoring the many other thoughtful design choices that have gone into the project.
Now, some will say that all you need to do is walk through each basic construct in the language to build up understanding. There are two problems with this approach.
First, this misses the point of programming. The point of programming is to solve problems, not learn language features. Language features are instruments for solving problems and expressing their solutions. They're also a notion to help you reason about them.
Second, a full-fledged language will produce inscrutable error messages that will confuse the student. It prematurely drags in concepts that the student is not ready for.
So the HtDP curriculum works with a hierarchy of student languages that give the student the freedom to explore and experiment within a space that is well-defined, well-understood, confined, and comprehensible according to their readiness. Over time, the language of discourse is expanded.
English keywords are not the stumbling block. Plenty of young people pick up programming languages without knowing English. What poses the greatest difficulty from the perspective of the language is having access to the full language all at once. Also, never talk about the computer. Computers are to programmers what telescopes are to astronomers, to borrow from Dijkstra. In the HtDP curriculum, they ban students from talking about the computer, instead preferring "the compiler" or "the interpreter" or whatever. Implementation concerns are dealt with in later courses, because while practically useful, they are incidental to the basic act of programming.