Software development has its lexicon derived from English. Not learning it does exactly zero favor to kids. On the contrary: their time is wasted, they will need to learn it anyway, and it's sad that some well-intentioned people make them skip what cannot be skipped.
And the mistake seems to be repeated every 5-7 years. One can gather a whole cemetery of such initiatives, the earliest dating back to 70s I believe
You are evaluating this as a tool that is intended to train people up to being professional software developers.
It's not!
It's instead intended to give every child in the world, regardless of inclination, some first-hand experience in programming computers. Some of these may go on to become professional software engineers, and if they do it will be time enough to become proficient in the common lexicon. Even if they don't, at least they've gotten a better understanding of these machines that inescapably pervade our lives. And kids that wouldn't have thought they'd have an interest in programming get an easy-entry exposure and may decide to pursue it professionally after all.
Given that that's the audience, the goal is to take away any barrier to the essential skill to learn, which in this case is writing instructions for an unthinking machine.
Kids that already know they love programming and are/were willing to do whatever it takes to learn it (i.e., probably nearly everyone on this forum, including myself), are not the audience! Those kids will make it one way or another. Hedy is for all the other kids out there.
I've always thought that one of the better things we could do is to make programming not specialized; e.g. Excel-as-a-programming-language has arguably done more to bring programming to the masses than any other "real" language, and perhaps THAT's the goal.
I'm sorry, but you are building on a false premise. If you goal is to lure children unmotivated to learn programming you'd better be distributing sweets. Or (if you ask a Far Eastern, or Eastern European mom) threaten those brats with punishments. Replacing "for" for "voor" is not even a barrier removal as much as you seem to believe. Because "for" in programming has a separate meaning, and you'll spent the same amount of time explaining how it works whether it "for", or "voor". Except that programming-for can be useful for farther studies, and programming-voor is much less so. I answered here in a longer comment if you are interested:
> 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.
> 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.
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.
Hedy is designed for use in classrooms, and reaches many kids who otherwise would not have tried programming at all. See it as a stepping stone towards programming rather than a great language.
Disclaimer: I've been involved with the project (in a tiny way), and am a fan.
I see what you mean, and I don't enjoy criticizing the initiative, but I volunteered as a programming teacher for several years, and my experience makes me believe you are on the wrong track completely. English has never been the major obstacle to teaching programming.
1. English is taught widely, and they need it anyway.
2. The lexicon to master is pretty short.
3. Kids naturally learn words. Say, with moderate interest in K-pop a European teen can remember Korean names, sometimes even in Korean script.
4. "For" in programming is not the same word as "for" in natural language. You may be under illusion that when it's in a local language, it will be easier to digest, but it's not. You need to explain its separate meaning anyway. And when you did it not in Programming English - sorry, you simply missed the opportunity. You spent roughly the same amount of time to create a redundant word-slot in student's memory.
5. "Tried" is not a valid metrics for success here. One could as well offer free cookies, and number of tries would be growing. But that elephant in the room will look at us without approval!
I agree that localization might not be the biggest hurdle, but that's also not the biggest selling point of the language. It's a gradual language (the syntax grows which each level), it's fun, and designed for classrooms so teachers can help kids easily. I disagree with you, because I think the localization does more good than bad. It's not like these kids are becoming "career hedy programmers". There are only a couple of levels, after which they will hopefully continue to learn other languages. I'm happy to agree to disagree.
My main struggle with BASIC at 10yo was its non-strict SQL-looking structure. Maybe that’s me specific, but this gradual thing would be even more confusing, cause it gives nothing rigid to pattern match against. The big part of it is demystification and regularity. I only started programming when I got Turbo Pascal (and god bless BGI). Before that it was all muddy waters.
I was very confused by the complex structure of Pascal (in Delphi). I think everyone has their own way of struggling with their first language.
I have doubts whether the gradual language is confusing or sensible to the average brain. Only time and competition in these kinds of educative tools will tell.
But, there is one thing I'm very sure of: the more kids that get to experience the joy of creatimg something by programming, and the more kids that get to experience the feedback loop, the better!
> 5. "Tried" is not a valid metrics for success here.
A key insight. Feels like the usual human confusion over activity and output. Activity metrics bias for participation / attention at the top end of the funnel, whereas Output metrics assess the end: the quality & quantity of production. The first is visible, immediate, plays to human bias, whereas the second is much farther off and usually less interesting to the general public.
Applied to kid coding, adults like seeing many kids doing work socially, whereas the few kids who stick with it aim for genuine, even selfish, creation.
It's not a bad initiative, just one that seems to cater mostly to the ideals of the teachers and the parents.
I'm sorry you feel your work is easily dismissed. You may believe that quoting "the rules" would make you appear stronger, but more often than not it would have the opposite effect: make you look weak. Nothing about my argument is shallow; it's a concise recognition of reality in education: ChatGPT is here, and it's here to stay. New capabilities will include generating, running code, and beyond.
If this were your intentions, you would have done exactly that. So far you have produced 0 statements on AI beside empty affirmations "AI is very important." We can do better than that on HN.
I don't know about the US, for the first serious second languages courses in France happen sometimes at the very late primary school, or early secondary school.
But you might want to teach very simple programming concepts before that.
You end up using programming as "applied math" and "applied reading / writing".
It's okay. Not all of them will learn programming. Just like it might be usefull to call some angles A in math class, before we learn enough greek to call them omega like all Physical Engineers.
And if they get serious, yes, they will learn english.
(Now that I think of it, I'm pretty old, and I grew up during the "Computer Science for all" years, so I had some very early english and some very early LOGO classes taught the same year. And I'm pretty sure the LOGO went first. Ooooh, memories.)
Agree with most of that. yet, I think there is a lot of value in intuitively understanding the 'fors' and the 'ifs' in a way that's different than a combination letters.
Always reminding yourself that 'if' means 'jezeli' (or paste if in your lang) before writing is an extra cognitive load, quite annoying for a kid in the age of dopamine disruption.
Moreover, in the age of LLMs every child can have an infinitely patient assistant explain them how to do things in any mainstream language. Even before LLMs, the ability to Google something was proportional to the popularity of the language. When we teach children math, we do not teach obscure boutique notation, we teach what everyone knows, even though there are alternatives that would certainly work better for teaching.
>When we teach children math, we do not teach obscure boutique notation
Actually, you do. There's a reason you teach kids multiplication by aligning blocks into groups and things like that, rather than jumping straight into rote algorithms.
And the mistake seems to be repeated every 5-7 years. One can gather a whole cemetery of such initiatives, the earliest dating back to 70s I believe