6 ms·

> it's sad that some well-intentioned people make them skip what cannot be skipped. I don't see this as a move to skip learning English terms for programming c

> it's sad that some well-intentioned people make them skip what cannot be skipped. I don't see this as a move to skip learning English terms for programming concepts, it's a move to reorder. Starting with Python requires kids to start learning computational thinking simultaneous with learning the English terms for computational constructs. Sure, there aren't many terms to learn, and sure, in some cases (but far from all!) the English word isn't a great mnemonic even for English-speaking children, but neither one of those facts is a good explanation for why teaching a few foreign-language words isn't just accidental complexity in the early stages! And if it's accidental complexity, why not put it off for later? The whole premise of Hedy is to gradually add complexity in levels, and yeah, that means that throughout the design (not just in the localization) there are some aspects of each level that become redundant as you move on to later levels. But if that's what you're criticizing, you're not criticizing just the fact that it's localized, you're criticizing the entire pedagogical philosophy of Hedy and of most educational institutions. Educators in general prioritize breaking a concept down into manageable chunks, even if that means teaching some things in a way that isn't perfectly applicable in the real world. Hedy does that for programming, and if you don't like it then your beef is with the entire educational philosophy, not the localization.

Chris2048 2y ago
> simultaneous with learning the English terms for computational constructs Very often these are the terms for those things. Much like things named after their inventors, or discoverers; novel concepts often borrow the word of origin of its inception. What would you call "Currying" in another language? So I guess you could rename keyboard, with <key>-<boards> with words for each coming from your native language, but you'd still be following the convention of 'form' - that the buttons are "keys" (which in other languages may not have the same meaning where a 'key' I believe is piano terminology derived from French "clé"), and its container is a "board". Unless your language has a handy word that is a perfect fit for the concept of "keyboard", it seems like unnecessary work for the sake of it. Even English borrows 'loan'-words, and Japanese even has a separate alphabet for them. > neither one of those facts is a good explanation for why teaching a few foreign-language words isn't just accidental complexity in the early stages b/c you aren't really teaching a foreign word b/c the words still need further context in English, and that is a good reason IMHO, even if you disagree. You could teach ASM mnemonics ('mov', 'div', 'cdq'..) which are also derived from English terms, and I doubt it'd be much different given how abstract the relationship to the words is, and how unusual the terms (e.g. "execute" an action isn't that common in English, outside of CS, or perhaps the military). > gradually add complexity in levels ... you're criticizing the entire pedagogical philosophy of Hedy and of most educational institutions. > Educators in general prioritize breaking a concept down into manageable chunks ... if you don't like it then your beef is with the entire educational philosophy It isn't clear to me that 'English" terms are a layer of complexity on top of local terms. I'd say you are teaching jargon either way, neither of which is clearly easier to learn - I could just as well argue that using native words could cloud the issue and create misunderstandings if they don't match the programmatic meaning well.
- ejplatzer 2y ago
  Have you looked at the content of the lessons? We're not talking about Currying and modular arithmetic. We're talking about "print", "ask", "is", "forward", "turn", "random". None of these are jargony, and the Hedy examples are carefully curated and designed to hide the mismatch between where these terms come from and the extent of their meaning in programming. The point of Hedy is not to localize programming, the point is to break down the process of learning the absolute fundamentals of programming into bite-sized, completely simple chunks that students can explore, mess around with, build silly and cool things, without having to worry about the minutiae and quirks of real computers. That's why they introduce an "ask" statement that assigns a temporary, invisible variable that can only be used by immediately putting an echo statement afterwards - because they're building up to variable assignment, but they want to show the concept of input first.

Chris2048 2y ago

> simultaneous with learning the English terms for computational constructs Very often these are the terms for those things. Much like things named after their inventors, or discoverers; novel concepts often borrow the word of origin of its inception. What would you call "Currying" in another language? So I guess you could rename keyboard, with <key>-<boards> with words for each coming from your native language, but you'd still be following the convention of 'form' - that the buttons are "keys" (which in other languages may not have the same meaning where a 'key' I believe is piano terminology derived from French "clé"), and its container is a "board". Unless your language has a handy word that is a perfect fit for the concept of "keyboard", it seems like unnecessary work for the sake of it. Even English borrows 'loan'-words, and Japanese even has a separate alphabet for them. > neither one of those facts is a good explanation for why teaching a few foreign-language words isn't just accidental complexity in the early stages b/c you aren't really teaching a foreign word b/c the words still need further context in English, and that is a good reason IMHO, even if you disagree. You could teach ASM mnemonics ('mov', 'div', 'cdq'..) which are also derived from English terms, and I doubt it'd be much different given how abstract the relationship to the words is, and how unusual the terms (e.g. "execute" an action isn't that common in English, outside of CS, or perhaps the military). > gradually add complexity in levels ... you're criticizing the entire pedagogical philosophy of Hedy and of most educational institutions. > Educators in general prioritize breaking a concept down into manageable chunks ... if you don't like it then your beef is with the entire educational philosophy It isn't clear to me that 'English" terms are a layer of complexity on top of local terms. I'd say you are teaching jargon either way, neither of which is clearly easier to learn - I could just as well argue that using native words could cloud the issue and create misunderstandings if they don't match the programmatic meaning well.

ejplatzer 2y ago
Have you looked at the content of the lessons? We're not talking about Currying and modular arithmetic. We're talking about "print", "ask", "is", "forward", "turn", "random". None of these are jargony, and the Hedy examples are carefully curated and designed to hide the mismatch between where these terms come from and the extent of their meaning in programming. The point of Hedy is not to localize programming, the point is to break down the process of learning the absolute fundamentals of programming into bite-sized, completely simple chunks that students can explore, mess around with, build silly and cool things, without having to worry about the minutiae and quirks of real computers. That's why they introduce an "ask" statement that assigns a temporary, invisible variable that can only be used by immediately putting an echo statement afterwards - because they're building up to variable assignment, but they want to show the concept of input first.