I saw Felienne Hermans give a talk on Hedy at Splash! but that wasn't recorded sadly, but here is a presentation too a much larger audience https://www.youtube.com/watch?v=j4eSjA6btE8 that I hope covers the same material.
It is a wonderfully amazing project. I don't know if the video goes into it yet, but when you see how truly egalitarian the project is, you are both proud and ashamed of humanity. Proud that Felienne made this project and all the lives she is improving, but ashmed that it took us this long. Lets make up for it by making everything we design with the same affordances. Lets democratize access to the future.
You might recognize Felienne from her research on Spreadsheets which I feel was a thing here around 2010 https://www.youtube.com/watch?v=0CKru5d4GPk It feels like that was the start of resurgence in respect for Spreadsheets.
In the video I saw, and of course it is by the Hedy team, about Hedy, but it showed kids very much being excited that the keywords were in their language. There are a lot of kids in the world and meeting them where they are is important.
I grew up French. Never had any issue remembering English keywords. It's not like "for" really flows naturally as an indication of a looping construct.
Edit: I sounded overall negative about this, but I didn't meant to be. I really like the tutorial, and the `ask` and `echo` constructs. I will show it to my son.
I'm French too, and when I was young, I learnt the Basic language before learning English (by reading Basic programs already available on our computer).
So I was able to write FOR … THEN … ELSE blocks without even knowing what the keywords meant (I just know what they did to the program). One day, I explained to my father what I was writing, and I read out loud FOR … "TEN" … "ELCE" (with a strong French accent), and he corrected me by pronouncing the words correctly ("FOR … THEN … ELSE"). I was shocked: "how do you know?" (he knew nothing about Basic or even programming).
I learnt that day that "for", "then" and "else" were not just keywords in the Basic language, but they were actually real words in English.
Still, it's nice to engage with folks on their own terms, and not just blindly assume they'll want to work in English all their life.
I kind of miss the early 2000's, where a bunch of pretty well-known French and Belgian academics were publishing source code in their own languages (#define to remap keywords and all)
A programmer not working in English is kinda useless imo. EVERYTHING is written in English source code. If you don't know English you are going to have a very bad time.
I am a native Swedish speaker and I have had a hard policy since I was a teenager to have all electronics set to English and not Swedish. Why? Because the translations are lossy at best. Often you need to understand both English and Swedish AND have a creative mind for word games to understand what the hell something means.
Example: My daughter had an Android smart watch. One menu option in settings was "omkring". This makes no sense. But if you translate it to English it can become "around" hmm, still nonsense.. oh, but it can mean "about" as in "around and about".
Translation is a fools game. It builds Babels Tower all over again. It's bad enough that we have multiple programming languages that only sometimes interop.
Okay, but are you speculating that we will all switch to many native languages instead? That seems unlikely. The lingua franca may change, but nothing suggests it will not be English within the educational timeframe of any child born today.
> it's really a pretty recent state of affairs. A quarter century at most
And? Powered flight is barely 100 years old. For most of the world, ubiquitous sanitation, access to running hot water, electricity, medicine beyond voodoo and superstition - are all barely 100 years old, give or take quarter century. For most of the world - the rest of the world got it much later, or in some places, not at all.
Very little in human affairs is an immutable laws of the universe. Most of it is arbitrary, path dependent, frozen in place as we built more things and made more choices on top of past ones, instead of endlessly bickering about which random result would've been most fairest.
It so happened that English became lingua franca, and we've built the last 70+ years of technology on top of it. Do you want to tear it all back down, and call for a World War II rematch, all for the sake of a dice re-roll on which language we name our "for loops" in? Why the hell does it matter?! English won. Time to move on. Build up, instead of tearing down.
EDIT: also, FWIW, languages evolve. English of 2025 isn't all the same as English of 1945, much less that of 1865. That evolution accelerates with globalization, as every culture contributes their bit to the global whole. See the "Internet slang" or various pidgins that popped up in the high-throughput port areas around the planet; this is the sign of things to come.
> a pretty recent state of affairs. A quarter century at most
When I started programming in 1980 there wasn't even a hint that anyone used anything other than English. The first non-English thing I saw was a message from a Prolog compiler (in perhaps 1983) telling me that I had an "erreur syntactique", IIRC.
More significantly, from 1988 to 1991 I worked on a EU Esprit research project, with Dutch, Italian and French partners. They all coded exclusively in English, even the French partners.
Even into the early 90s a lot of codebases had their comments in other languages. Less common for variable/class names to be in other languages, but there is a reason that Java et al adopted unicode identifiers in the 90's (albeit with fairly little uptake).
So what? What's your point? If something occurs that shifts the language of tech to something else in the future, so be it, but as of now, it is English.
There have been many lingua francas in history, often domain specific. In the early 20th century, French and German had become the languages of international scientific discourse. Before that, Latin was the language for academic work and international communication in Europe. If you wanted to get involved, you had to learn the language. That's always the case, because a common enterprise needs a common language.
And today, the degree of international collaboration is so high, and the cumulative literature so great, that it will be more difficult to even make a shift.
(And trust me: programming language keywords in a language other than your own are not an obstacle for anyone.)
I've a few things to say about this. First is that the translations have to be good. As you've said, Android fails at it, sometimes spectacularly (think "free space" = "liberty space" etc) and so do many other apps that apparently use Google Translate or pay some random guy on the Internet to translate it for them. You can have good translations, but it means hiring an actual (professional) translation team.
As for the ambiguous terminology, this is where the quality of your translation team really shows. When Windows was first translated to Slovene, for example, the team took special care to find the correct terminology (sometimes inventing phrases along the way) and use it consistently. Again, not something machine translations or some random guy for $5/hr on Fiverr would do.
The second is that this all depends on where you're from and what's your goal when using a computer. If you're doing it to become a programmer, then yes, there's no way around English. But for classroom use, I'd argue a localized approach is much better because it directly exposes the "tone" of programming to the students even if they don't intend on ever doing it again in their life. Otherwise they're just learning "FOR x IN...DO..." to pass an exam and not really thinking what it actually means. Again, here I have the "non-coder" kids in mind. You also have to keep in mind that the further you go from Germanic languages, the weaker the similarities to your language become.
> I am a native Swedish speaker and I have had a hard policy since I was a teenager to have all electronics set to English and not Swedish. Why?
The base reason is that Scandinavian teenagers can learn English by sheer osmosis from Anglo culture. (That is not the case in many other places.) Then it makes perfect sense to:
> Because the translations are lossy at best.
Since (my reason at least) is that I can troubleshoot problems using the English Internet corpus. And I don’t need to bother with multiple terms.
Granted I was older before I committed to this practice.
Practical angle: so let's add another datapoint! The same is the case in Poland.
Seriously though, it's just a consequence of history. Computers and software were imported to everywhere around the world rapidly; no country wanted to put themselves at economic disadvantage by blocking sales of hardware and software until they 100% up to specs regarding consumer products being fully explained and operable in native language (in fact, I suspect such regulations came about after computers became a thing in any given place).
> Since (my reason at least) is that I can troubleshoot problems using the English Internet corpus. And I don’t need to bother with multiple terms.
For me it's more of the latter. Translations love to screw terminology up, introducing multiple distinct terms for the same abstract concept, and using them inconsistently (often the result of multiple, independent, half-assed passes at translating the user-facing text, manuals, etc.).
English was the language software authors most likely spoke; English is the language of programming and software industry. English is the language almost all software targets first and foremost, due to market/user population size. As a consequence, most care is put into English in the user interface, it's the one considered canonical, it's the one in which the thing was designed (whether the desigers were native English speakers or not); English is the one where user-facing text is most likely to be consistent and corresponding 1:1 with language used in other programs, as well as with code powering it, etc.
Every other language is a translation, most likely done as an afterthought, as cheaply and quickly as possible (there's little incentives to do otherwise - as long as English text is done well, users will manage). If you understand English, running software in anything but English is setting yourself up for failure.
Scandinavians have small language bases, speak a Germanic language, and don’t have to learn a second non-English language, c.f. the Swiss for example.[1] Both the lack of material in their own languages plus the shared English lexicon and I guess grammar helps motivate them to become at least bilingual (in my experience not more than that for the most part).
Similar tendencies can be seen in other European areas. But it seems to be less pronounced as you move outside of the Germanic-speaking parts of Northern Europe.
You don’t have to move far away from the Germanic-speaking Northern Europe to find adults who struggle with English. Including young adults.
Now this is apparently for kids. Certainly kids younger than teenagers have amazing language acquisition abilities. But they also might have less motivation and exposure to English. Now maybe Northern Europe kids have such exposure these days that the current English-dominated programming as we all know it is a mere triviality for them. So scratch those. Not for them. I would still be surprised if there aren’t a large number of kids worldwide that localized programming would help.
[1] Minorities like the Sami could be exceptions here.
Nice, I was unaware of this. Take OCaml for example, it was primarily developed by the French if I recall
OCaml was written in 1996 by Xavier Leroy, Jérôme Vouillon, Damien Doligez, and Didier Rémy at INRIA in France
Yeah, but they didn't write keywords in French, they went straight to `let`, `rec`, `if`, `then`, `else`... Because they're just keywords, they could just be punctuations; so as long as you don't go full brainfck.
The comments were quite often in French, however! Until relatively recently, the OCaml compiler would also sometimes emit error messages in French in some obscure cases.
How long ago was this "relatively recently"? When I translated all the remaining French comments in the OCaml compiler nearly 10 years ago, there were already no warnings nor error messages in French.
Note that this is an error message from the ocamldoc tool, and not an error message from the OCaml compiler itself. Funnily enough, looking that the repository history, this French error message was introduced in the very first version of ocamldoc in 2002 and went undetected (or unreported) for 9 years. Thanks for the historical tidbit!
I'm sure there is, somewhere in the deep recesses of the Internet, a camlp4 or camlp5 syntax extension to replace `let`, `rec`, `if`, `then`, `else` with `soit`, `réc`, `si`, `alors`, `sinon` :)
For the anecdote, my first introduction to programming (and to computers in general) was in french schools with Thomson TO7, and the language used was Logo, with french keywords. But I agree, english keyword are not really the difficult point when learning to program (for countries with latin alphabet)
I tried this a while ago with my scout group, I expected them to take a while per lesson, but they flew through the lessons in no time, drawing all sorts of patterns and making little games
That is one of the coolest results from Hedy, that these engaging learning paths have a constant acceleration to them, so before you know it, you are juggling while riding a unicycle. You undertand something to the core when you have built it yourself.
In a way it is a perfect (ugh) example of constructivist learning theory, Hedy itself is a constructivist learning exercise in how to teach.
Lego Mindstorms were inspired by Seymour Papert, himself the creator of the Logo programming language and whom he took inspiration from Piaget the psychologist whose work on feedback loops creating core knowledge.
This isn't really new, there have been projects like this since forever. Microsoft used to ship one with Office, even. I wish they had published something about why they stopped doing it, maybe that would prevent people from repeating the same mistakes.
I was subjected to one of those translated programming languages 20+ years ago: they are traps two weeks in you realize you can't do anything without either learning a different programming language (with english keywords) and reaching for external libraries that will define english identifiers and often even have english documentation.
I wish I could get back every minute I spent with it and could reinvest it into learning english.
I don't know the one that shipped from Microsoft, but I'm going to assume it's goal wasn't to teach people how to code but rather empower non-programmers to code. Starting from that, I don't see the two would be similar.
Also Excel functions are translated based on your region. Which I find annoying, because most learning resources and references are in English, and English function names don't work in other regional settings.
The localizers went too far, converting the language keywords to somewhat appropriate language-specific versions.
I guess once they shipped a version with the keywords translated, they decided to was too expensive to fix/go back and limped along with this major footgun.
I know several programmers who don't speak any english and can understand the things well enough.
I think this is a valid project and while most programmers I know eventually understand a bit of what the identifier of english mean, the concepts are much better explained in their native language. They can much better translate it later when moving to a "serious" programming language or even to Excel or something like that.
Excel functions are also translated, so stuff like that is really helpful even if you aren't going to become a programmer.
fy $choice;
fy $continue;
fy @bad = <damn stupid nutcase>;
ailadrodd {
$choice = prydlon "Type something, like a number, or a string: ";
dywedyd "You typed in ｢" ~ ($choice ~~ unrhyw(@bad) ?? "*" x $choice.golosg !! $choice) ~ "｣";
a-roddwyd $choice {
pryd "dragon" {
dywedyd "which is 'draig' in Welsh"
}
pryd unrhyw(@bad) {
dywedyd "wash your mouth with soap"
}
pryd IntStr {
dywedyd "which evaluates to an integer ", $choice
}
pryd RatStr {
dywedyd "which evaluates to a rational number ", $choice
}
rhagosodedig {
dywedyd "which does not evaluate to a number "
}
}
$continue = prydlon "Try again? If not type N: "
} hyd $continue eq unrhyw(<N n>)
And for OG Perl, Damian Conway gives us classical Latin!
use Lingua::Romana::Perligata;
adnota Illud Cribrum Eratothenis
maximum tum val inquementum tum biguttam tum stadium egresso scribe.
da meo maximo vestibulo perlegementum.
maximum comementum tum novumversum egresso scribe.
meis listis conscribementa II tum maximum da.
dum damentum nexto listis decapitamentum fac
sic
lista sic hoc tum nextum recidementum cis vannementa listis da.
dictum sic deinde cis tum biguttam tum stadium tum cum nextum
comementum tum novumversum scribe egresso.
cis
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.
It seems good for beginners. Less scary than BASIC, simpler than Python, and they even have a turtle mode. I don’t know who the audience is but I would have enjoyed that as a kid.
I really like that it can be used in different languages. Does the whole file have to be in one language, or can you change whenever? Can you have some lines of arabic inside an english file?
At the top left is a control panel that toggles base language for the language keywords. Or what it appears to me. Is that what you are looking for? You could try the exercise and see if it supports both.
It looks like you can definitely program entirely in Arabic with English inside of Hedy, I am not sure if any of the exercises are declaring new keywords
Dang it, I had this idea in my head forever, good to see someone else do it. I also thought about being able to disable features of the language, like classes, so teachers can focus on specific concepts in specific lessons.
My project Easel (https://easel.games/about) is also trying to be a good first programming language for teenagers!
So many projects try to innovate teaching programming by lowering the barriers, but not enough effort trying to increase the fun, so that is what I'm trying to do
I tried Heddy with my children. It worked great at first. It's really easy to get started with. Every level, the language changes slightly to introduce more concepts. That worked great for my younger son, but it confused his brother. Code that was correct in one level, suddenly gives errors in the next. In the end, we stopped using Hedy. I now teach them Python instead. It's harder at first, but at leastthe things they learn, won't change.
Experimented with something like this for a while. Translate a kind of plain language into Javascript. Once that is done then alternative languages can be used, translated into the plain language, then into Javascript. The problem I came into when trying to build even a small web application this way was all the common interfaces such as built into Node. Translating the language is a solid start, but real world usage means translating or at least accessing all the terminology and data types and interfaces for whatever stack is being used.
I was around 9 and didn’t speak English at all when I first met a computer with ROM BASIC in it.
My struggles were with understanding the structure and my daily driver was making games. BASIC was sort of harder to get compared to e.g. Pascal cause it was less structured. English was not an issue at all. And print/input/print loop gets boring immediately. You need graphics, and sounds, and a library of these, and algorithms that make it move. I had to imagine that circles were characters and SOUND 50, 2 were the effects.
I remember two instant-games environments - Gambas and Löve2d, but there should be much more now.
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.
At https://www.hedy.org/learn-more many of the listed 'research' items are bachelor's theses supervised by the creator of Hedy, with topics such as 'creating Syntax highlighting for Hedy'. To me this comes across as padding and disingenuous.
I've pretty much concluded after a few decades that "learning" programming languages are a bad idea. If your language doesn't give students all the tools necessary to build a production program, you're sending them down a path that ends in a dead end. Sure, you can learn loops/ifs/functions in whatever language, but those concepts are a means to an end. Students don't start learning a programming language because they want to learn loops/ifs/functions, they start learning a programming language because they want to build something--a website, a video game, a tool that spams their friends' emails with fart jokes. If your language can't do all those things, it's not empowering students to do the things that got them into programming in the first place.
Multilingual programming is a great idea, but it needs to be a feature in a production-quality general-purpose programming language, not in a learning language.
I've been working on a programming language interpreter for a while, and I'm thinking about how I'd implement this. Here are my thoughts on a rough design:
All the keywords in the language should be in a "language pack" for each of the supported natural languages. These should map one-to-one to some central language. When you write your code, you write it in your native language, and then run a tool that translates the code into the central language. The central language code, not your native language code, is what you commit to git.
When a programmer checks out the repository, the first thing they do is run a tool which translates the code into their native language using the language pack. This is why it's important that the mappings be one-to-one.
The tricky part here is variable names also need to be translated. This is an easier problem than translation of natural language usually is, because variables are going to mostly nouns, but it does mean that you can't have the typical /[A-Za-z_][A-Za-z_\d]*/ variable names--variable names need to be limited in some way to words which exist in the language pack. This creates a mess for language maintainers, but it's similar to maintaining time zone information in a standard library.
One upside to the central language design is that bad translations don't have to be forever. The central language has to be reverse-compatible, but the translations don't, because when the user updates their language pack all they have to do is re-generate their native langauge source to get the better translations.
The central language doesn't have to be human-readable, but it's not terrible if it is a natural language. However, I think it should not be English: English developers of the language should be dogfooding the translation system.
Ideally you'd want your editor to display code in your natural language, translating to the central language in real time and only ever writing to disk in the central language, because we don't want be keeping natural language and central language files in sync. Vim/emacs/atom/etc. could do this with a plugin, but this definitely is not a trivial problem.
Language packs should contain some standard formatting rules that make sense for the language, similar to `go format`, but there's no reason users couldn't configure the translation tools to use their preferred formatting.
> Students don't start learning a programming language because they want to learn loops/ifs/functions, they start learning a programming language because they want to build something--a website, a video game, a tool that spams their friends' emails with fart jokes.
Generally students learn a programming language because they are told by their teachers that they have to.
And thus these kinds of programming languages aren’t really for curious students. They’re to make teachers lives easier. Particularly for schools where teachers might not even know how to program themselves.
Some definitely do. Those tend to be the more successful examples of beginner languages
For example, look at Scratch’s website. They’re not talking to students directly. The way their site is composed is addressing the parents and educators rather than the students.
I saw Felienne Hermans give a talk on Hedy at Splash! but that wasn't recorded sadly, but here is a presentation too a much larger audience https://www.youtube.com/watch?v=j4eSjA6btE8 that I hope covers the same material.
It is a wonderfully amazing project. I don't know if the video goes into it yet, but when you see how truly egalitarian the project is, you are both proud and ashamed of humanity. Proud that Felienne made this project and all the lives she is improving, but ashmed that it took us this long. Lets make up for it by making everything we design with the same affordances. Lets democratize access to the future.
You might recognize Felienne from her research on Spreadsheets which I feel was a thing here around 2010 https://www.youtube.com/watch?v=0CKru5d4GPk It feels like that was the start of resurgence in respect for Spreadsheets.
Aren't all the SIGPLAN conferences recorded now? At any rate, her talks were recorded:
https://www.youtube.com/watch?v=IrUh5AgIYKE
https://youtu.be/-Br66SUjsdQ?t=12103
(I was also at SPLASH24 and thought she gave great talks. :) )
I wonder how much projects like Hedy appeals to adults over kids.
Egalitarian, multilingual coding sells well to parents. Children, so I hear, just want to make Minecraft mods or Roblox games.
Seems like a tension between the customer and the user.
In the video I saw, and of course it is by the Hedy team, about Hedy, but it showed kids very much being excited that the keywords were in their language. There are a lot of kids in the world and meeting them where they are is important.
I grew up French. Never had any issue remembering English keywords. It's not like "for" really flows naturally as an indication of a looping construct.
Edit: I sounded overall negative about this, but I didn't meant to be. I really like the tutorial, and the `ask` and `echo` constructs. I will show it to my son.
I'm French too, and when I was young, I learnt the Basic language before learning English (by reading Basic programs already available on our computer).
So I was able to write FOR … THEN … ELSE blocks without even knowing what the keywords meant (I just know what they did to the program). One day, I explained to my father what I was writing, and I read out loud FOR … "TEN" … "ELCE" (with a strong French accent), and he corrected me by pronouncing the words correctly ("FOR … THEN … ELSE"). I was shocked: "how do you know?" (he knew nothing about Basic or even programming).
I learnt that day that "for", "then" and "else" were not just keywords in the Basic language, but they were actually real words in English.
Precision: Of course, I meant "FOR" and "IF THEN ELSE" separately (the way I wrote it might wrongly suggest there is something like for-then-else).
Still, it's nice to engage with folks on their own terms, and not just blindly assume they'll want to work in English all their life.
I kind of miss the early 2000's, where a bunch of pretty well-known French and Belgian academics were publishing source code in their own languages (#define to remap keywords and all)
A programmer not working in English is kinda useless imo. EVERYTHING is written in English source code. If you don't know English you are going to have a very bad time.
I am a native Swedish speaker and I have had a hard policy since I was a teenager to have all electronics set to English and not Swedish. Why? Because the translations are lossy at best. Often you need to understand both English and Swedish AND have a creative mind for word games to understand what the hell something means.
Example: My daughter had an Android smart watch. One menu option in settings was "omkring". This makes no sense. But if you translate it to English it can become "around" hmm, still nonsense.. oh, but it can mean "about" as in "around and about".
Translation is a fools game. It builds Babels Tower all over again. It's bad enough that we have multiple programming languages that only sometimes interop.
> EVERYTHING is written in English source code
That's not some immutable law of the universe - it's really a pretty recent state of affairs. A quarter century at most
Okay, but are you speculating that we will all switch to many native languages instead? That seems unlikely. The lingua franca may change, but nothing suggests it will not be English within the educational timeframe of any child born today.
> it's really a pretty recent state of affairs. A quarter century at most
And? Powered flight is barely 100 years old. For most of the world, ubiquitous sanitation, access to running hot water, electricity, medicine beyond voodoo and superstition - are all barely 100 years old, give or take quarter century. For most of the world - the rest of the world got it much later, or in some places, not at all.
Very little in human affairs is an immutable laws of the universe. Most of it is arbitrary, path dependent, frozen in place as we built more things and made more choices on top of past ones, instead of endlessly bickering about which random result would've been most fairest.
It so happened that English became lingua franca, and we've built the last 70+ years of technology on top of it. Do you want to tear it all back down, and call for a World War II rematch, all for the sake of a dice re-roll on which language we name our "for loops" in? Why the hell does it matter?! English won. Time to move on. Build up, instead of tearing down.
EDIT: also, FWIW, languages evolve. English of 2025 isn't all the same as English of 1945, much less that of 1865. That evolution accelerates with globalization, as every culture contributes their bit to the global whole. See the "Internet slang" or various pidgins that popped up in the high-throughput port areas around the planet; this is the sign of things to come.
> a pretty recent state of affairs. A quarter century at most
When I started programming in 1980 there wasn't even a hint that anyone used anything other than English. The first non-English thing I saw was a message from a Prolog compiler (in perhaps 1983) telling me that I had an "erreur syntactique", IIRC.
More significantly, from 1988 to 1991 I worked on a EU Esprit research project, with Dutch, Italian and French partners. They all coded exclusively in English, even the French partners.
YMMV.
Even into the early 90s a lot of codebases had their comments in other languages. Less common for variable/class names to be in other languages, but there is a reason that Java et al adopted unicode identifiers in the 90's (albeit with fairly little uptake).
So what? What's your point? If something occurs that shifts the language of tech to something else in the future, so be it, but as of now, it is English.
There have been many lingua francas in history, often domain specific. In the early 20th century, French and German had become the languages of international scientific discourse. Before that, Latin was the language for academic work and international communication in Europe. If you wanted to get involved, you had to learn the language. That's always the case, because a common enterprise needs a common language.
And today, the degree of international collaboration is so high, and the cumulative literature so great, that it will be more difficult to even make a shift.
(And trust me: programming language keywords in a language other than your own are not an obstacle for anyone.)
I've a few things to say about this. First is that the translations have to be good. As you've said, Android fails at it, sometimes spectacularly (think "free space" = "liberty space" etc) and so do many other apps that apparently use Google Translate or pay some random guy on the Internet to translate it for them. You can have good translations, but it means hiring an actual (professional) translation team.
As for the ambiguous terminology, this is where the quality of your translation team really shows. When Windows was first translated to Slovene, for example, the team took special care to find the correct terminology (sometimes inventing phrases along the way) and use it consistently. Again, not something machine translations or some random guy for $5/hr on Fiverr would do.
The second is that this all depends on where you're from and what's your goal when using a computer. If you're doing it to become a programmer, then yes, there's no way around English. But for classroom use, I'd argue a localized approach is much better because it directly exposes the "tone" of programming to the students even if they don't intend on ever doing it again in their life. Otherwise they're just learning "FOR x IN...DO..." to pass an exam and not really thinking what it actually means. Again, here I have the "non-coder" kids in mind. You also have to keep in mind that the further you go from Germanic languages, the weaker the similarities to your language become.
> I am a native Swedish speaker and I have had a hard policy since I was a teenager to have all electronics set to English and not Swedish. Why?
The base reason is that Scandinavian teenagers can learn English by sheer osmosis from Anglo culture. (That is not the case in many other places.) Then it makes perfect sense to:
> Because the translations are lossy at best.
Since (my reason at least) is that I can troubleshoot problems using the English Internet corpus. And I don’t need to bother with multiple terms.
Granted I was older before I committed to this practice.
> (That is not the case in many other places.)
Practical angle: so let's add another datapoint! The same is the case in Poland.
Seriously though, it's just a consequence of history. Computers and software were imported to everywhere around the world rapidly; no country wanted to put themselves at economic disadvantage by blocking sales of hardware and software until they 100% up to specs regarding consumer products being fully explained and operable in native language (in fact, I suspect such regulations came about after computers became a thing in any given place).
> Since (my reason at least) is that I can troubleshoot problems using the English Internet corpus. And I don’t need to bother with multiple terms.
For me it's more of the latter. Translations love to screw terminology up, introducing multiple distinct terms for the same abstract concept, and using them inconsistently (often the result of multiple, independent, half-assed passes at translating the user-facing text, manuals, etc.).
English was the language software authors most likely spoke; English is the language of programming and software industry. English is the language almost all software targets first and foremost, due to market/user population size. As a consequence, most care is put into English in the user interface, it's the one considered canonical, it's the one in which the thing was designed (whether the desigers were native English speakers or not); English is the one where user-facing text is most likely to be consistent and corresponding 1:1 with language used in other programs, as well as with code powering it, etc.
Every other language is a translation, most likely done as an afterthought, as cheaply and quickly as possible (there's little incentives to do otherwise - as long as English text is done well, users will manage). If you understand English, running software in anything but English is setting yourself up for failure.
Scandinavians have small language bases, speak a Germanic language, and don’t have to learn a second non-English language, c.f. the Swiss for example.[1] Both the lack of material in their own languages plus the shared English lexicon and I guess grammar helps motivate them to become at least bilingual (in my experience not more than that for the most part).
Similar tendencies can be seen in other European areas. But it seems to be less pronounced as you move outside of the Germanic-speaking parts of Northern Europe.
You don’t have to move far away from the Germanic-speaking Northern Europe to find adults who struggle with English. Including young adults.
Now this is apparently for kids. Certainly kids younger than teenagers have amazing language acquisition abilities. But they also might have less motivation and exposure to English. Now maybe Northern Europe kids have such exposure these days that the current English-dominated programming as we all know it is a mere triviality for them. So scratch those. Not for them. I would still be surprised if there aren’t a large number of kids worldwide that localized programming would help.
[1] Minorities like the Sami could be exceptions here.
Nice, I was unaware of this. Take OCaml for example, it was primarily developed by the French if I recall
Yeah, but they didn't write keywords in French, they went straight to `let`, `rec`, `if`, `then`, `else`... Because they're just keywords, they could just be punctuations; so as long as you don't go full brainfck.The comments were quite often in French, however! Until relatively recently, the OCaml compiler would also sometimes emit error messages in French in some obscure cases.
How long ago was this "relatively recently"? When I translated all the remaining French comments in the OCaml compiler nearly 10 years ago, there were already no warnings nor error messages in French.
Most recent I remember was in 2011: https://github.com/ocaml/ocaml/issues/5419
Note that this is an error message from the ocamldoc tool, and not an error message from the OCaml compiler itself. Funnily enough, looking that the repository history, this French error message was introduced in the very first version of ocamldoc in 2002 and went undetected (or unreported) for 9 years. Thanks for the historical tidbit!
I'm sure there is, somewhere in the deep recesses of the Internet, a camlp4 or camlp5 syntax extension to replace `let`, `rec`, `if`, `then`, `else` with `soit`, `réc`, `si`, `alors`, `sinon` :)
There's a difference where you use this.
Learning language - fine, use whatever language you want
Excel - spreadsheet logic breaking when you open it with a different locale - horrible
I’m a native English speaker, but I have several dev friends from Latin America.
I remember asking them whether it would be useful if they could use Spanish words in their syntax, and they all pretty much said the same as you.
For the anecdote, my first introduction to programming (and to computers in general) was in french schools with Thomson TO7, and the language used was Logo, with french keywords. But I agree, english keyword are not really the difficult point when learning to program (for countries with latin alphabet)
I'm opposite: I thought the multi-lingual aspect seemed nice but the echo command immediately bothered me
Hedy is great for learning programming to kids.
I tried this a while ago with my scout group, I expected them to take a while per lesson, but they flew through the lessons in no time, drawing all sorts of patterns and making little games
That is one of the coolest results from Hedy, that these engaging learning paths have a constant acceleration to them, so before you know it, you are juggling while riding a unicycle. You undertand something to the core when you have built it yourself.
In a way it is a perfect (ugh) example of constructivist learning theory, Hedy itself is a constructivist learning exercise in how to teach.
Lego Mindstorms were inspired by Seymour Papert, himself the creator of the Logo programming language and whom he took inspiration from Piaget the psychologist whose work on feedback loops creating core knowledge.
This is an example of how to search using phind https://www.phind.com/search?cache=pti09n13qtsxahmn5zra8yjk
This isn't really new, there have been projects like this since forever. Microsoft used to ship one with Office, even. I wish they had published something about why they stopped doing it, maybe that would prevent people from repeating the same mistakes. I was subjected to one of those translated programming languages 20+ years ago: they are traps two weeks in you realize you can't do anything without either learning a different programming language (with english keywords) and reaching for external libraries that will define english identifiers and often even have english documentation. I wish I could get back every minute I spent with it and could reinvest it into learning english.
I don't know the one that shipped from Microsoft, but I'm going to assume it's goal wasn't to teach people how to code but rather empower non-programmers to code. Starting from that, I don't see the two would be similar.
Also Excel functions are translated based on your region. Which I find annoying, because most learning resources and references are in English, and English function names don't work in other regional settings.
I have no idea how this got through management.
The localizers went too far, converting the language keywords to somewhat appropriate language-specific versions.
I guess once they shipped a version with the keywords translated, they decided to was too expensive to fix/go back and limped along with this major footgun.
I know several programmers who don't speak any english and can understand the things well enough.
I think this is a valid project and while most programmers I know eventually understand a bit of what the identifier of english mean, the concepts are much better explained in their native language. They can much better translate it later when moving to a "serious" programming language or even to Excel or something like that.
Excel functions are also translated, so stuff like that is really helpful even if you aren't going to become a programmer.
here’s some raku lang in welsh… https://github.com/finanalyst/rakuast-L10N-CY
And for OG Perl, Damian Conway gives us classical Latin!
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.
This is an excellent point and goal.
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:
https://news.ycombinator.com/item?id=42840778
> 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!
In Czech none of the keywords are localized. Seems like an unstable interface if language keywords change depending on the state of translation.
> 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.
Have you lived under a rock for how many years?
AI
The best learning tool, "stepping stone" for kids. And they're already familiar with it when cheating on their homework.
"Please don't post shallow dismissals, especially of other people's work. A good critical comment teaches us something."
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.
I don't care about appearing stronger, it's just not very nice to say "have you been living under a rock". We tend to do better than that on HN.
I wasn't saying that AI is not here. It is, and it is very important. Happy to have a proper discussion about that.
> Happy to have a proper discussion about that.
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.
Is that problem huge? Don't think so.
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.
It seems good for beginners. Less scary than BASIC, simpler than Python, and they even have a turtle mode. I don’t know who the audience is but I would have enjoyed that as a kid.
https://en.wikipedia.org/wiki/Logo_(programming_language)#Tu...
a lot of memories !
https://corecursive.com/hedy-with-felienne-hermans/
I really like that it can be used in different languages. Does the whole file have to be in one language, or can you change whenever? Can you have some lines of arabic inside an english file?
You can select the language drop down and follow one of the tutorials
https://www.hedy.org/hedy#story
https://www.hedy.org/hedy/10?language=ar&keyword_language=ar...
At the top left is a control panel that toggles base language for the language keywords. Or what it appears to me. Is that what you are looking for? You could try the exercise and see if it supports both.
It looks like you can definitely program entirely in Arabic with English inside of Hedy, I am not sure if any of the exercises are declaring new keywords
Ah, thank you, that answers my questions =) Looks good!
Love the mission!
My project Glicol (https://glicol.org/) also has some classroom practice for sound 101
But I think what children need most is to provide very simple to complex examples for modification.
The bigger worry is that other things, like Instagram, become more appealing than learning to code.
Related. Others?
Hedy: Textual Programming for the Classroom - https://news.ycombinator.com/item?id=40095336 - April 2024 (1 comment)
Hedy: Textual Programming for the Classroom - https://news.ycombinator.com/item?id=39713141 - March 2024 (1 comment)
Hedy – a programming language created by a CS teacher to teach kids coding - https://news.ycombinator.com/item?id=38509871 - Dec 2023 (1 comment)
Hedy: Textual Programming for the Classroom - https://news.ycombinator.com/item?id=34274831 - Jan 2023 (1 comment)
Hedy: A Gradual Programming Language - https://news.ycombinator.com/item?id=33252427 - Oct 2022 (1 comment)
Hedy: A gradual programming language for education - https://news.ycombinator.com/item?id=30850420 - March 2022 (1 comment)
Hedy is a gradual programming language that helps kids to learn Python - https://news.ycombinator.com/item?id=26944418 - April 2021 (48 comments)
Hedy – A Gradual Programming Language - https://news.ycombinator.com/item?id=26761487 - April 2021 (1 comment)
Hedy: A Gradual Language for Programming Education - https://news.ycombinator.com/item?id=25249471 - Nov 2020 (17 comments)
No comments but From Burnout to Breakthrough is a conversation with the creator of Hedy https://news.ycombinator.com/item?id=40582437
Dang it, I had this idea in my head forever, good to see someone else do it. I also thought about being able to disable features of the language, like classes, so teachers can focus on specific concepts in specific lessons.
My project Easel (https://easel.games/about) is also trying to be a good first programming language for teenagers!
So many projects try to innovate teaching programming by lowering the barriers, but not enough effort trying to increase the fun, so that is what I'm trying to do
I tried Heddy with my children. It worked great at first. It's really easy to get started with. Every level, the language changes slightly to introduce more concepts. That worked great for my younger son, but it confused his brother. Code that was correct in one level, suddenly gives errors in the next. In the end, we stopped using Hedy. I now teach them Python instead. It's harder at first, but at leastthe things they learn, won't change.
Experimented with something like this for a while. Translate a kind of plain language into Javascript. Once that is done then alternative languages can be used, translated into the plain language, then into Javascript. The problem I came into when trying to build even a small web application this way was all the common interfaces such as built into Node. Translating the language is a solid start, but real world usage means translating or at least accessing all the terminology and data types and interfaces for whatever stack is being used.
I was around 9 and didn’t speak English at all when I first met a computer with ROM BASIC in it.
My struggles were with understanding the structure and my daily driver was making games. BASIC was sort of harder to get compared to e.g. Pascal cause it was less structured. English was not an issue at all. And print/input/print loop gets boring immediately. You need graphics, and sounds, and a library of these, and algorithms that make it move. I had to imagine that circles were characters and SOUND 50, 2 were the effects.
I remember two instant-games environments - Gambas and Löve2d, but there should be much more now.
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.
https://www.youtube.com/watch?v=8vjEnkQdaHM&t=2s
Sorry, my mind makes weird jumps and pulls up movie references
I really like this idea, going from something extremely basic and gradually building into python. I am very interested to see if this goes anywhere.
> Hedy also works on phones and tablets.
You shouldn't go mention that to the kids, it only gives them ideas...
Tisk tisk using my location information to decide on the webpage language instead of my preferred headers.
At https://www.hedy.org/learn-more many of the listed 'research' items are bachelor's theses supervised by the creator of Hedy, with topics such as 'creating Syntax highlighting for Hedy'. To me this comes across as padding and disingenuous.
shameless plug: python in bulgarian (or whatever you put in those translation tables). Well.. from 2012:
https://github.com/svilendobrev/smok
For what it's worth, my kids really like this project.
This is as bad as dubbed movies instead of the original audio with subtitles if you ask me.
And no, I'm not a native English speaker.
I've pretty much concluded after a few decades that "learning" programming languages are a bad idea. If your language doesn't give students all the tools necessary to build a production program, you're sending them down a path that ends in a dead end. Sure, you can learn loops/ifs/functions in whatever language, but those concepts are a means to an end. Students don't start learning a programming language because they want to learn loops/ifs/functions, they start learning a programming language because they want to build something--a website, a video game, a tool that spams their friends' emails with fart jokes. If your language can't do all those things, it's not empowering students to do the things that got them into programming in the first place.
Multilingual programming is a great idea, but it needs to be a feature in a production-quality general-purpose programming language, not in a learning language.
I've been working on a programming language interpreter for a while, and I'm thinking about how I'd implement this. Here are my thoughts on a rough design:
All the keywords in the language should be in a "language pack" for each of the supported natural languages. These should map one-to-one to some central language. When you write your code, you write it in your native language, and then run a tool that translates the code into the central language. The central language code, not your native language code, is what you commit to git.
When a programmer checks out the repository, the first thing they do is run a tool which translates the code into their native language using the language pack. This is why it's important that the mappings be one-to-one.
The tricky part here is variable names also need to be translated. This is an easier problem than translation of natural language usually is, because variables are going to mostly nouns, but it does mean that you can't have the typical /[A-Za-z_][A-Za-z_\d]*/ variable names--variable names need to be limited in some way to words which exist in the language pack. This creates a mess for language maintainers, but it's similar to maintaining time zone information in a standard library.
One upside to the central language design is that bad translations don't have to be forever. The central language has to be reverse-compatible, but the translations don't, because when the user updates their language pack all they have to do is re-generate their native langauge source to get the better translations.
The central language doesn't have to be human-readable, but it's not terrible if it is a natural language. However, I think it should not be English: English developers of the language should be dogfooding the translation system.
Ideally you'd want your editor to display code in your natural language, translating to the central language in real time and only ever writing to disk in the central language, because we don't want be keeping natural language and central language files in sync. Vim/emacs/atom/etc. could do this with a plugin, but this definitely is not a trivial problem.
Language packs should contain some standard formatting rules that make sense for the language, similar to `go format`, but there's no reason users couldn't configure the translation tools to use their preferred formatting.
> Students don't start learning a programming language because they want to learn loops/ifs/functions, they start learning a programming language because they want to build something--a website, a video game, a tool that spams their friends' emails with fart jokes.
Generally students learn a programming language because they are told by their teachers that they have to.
And thus these kinds of programming languages aren’t really for curious students. They’re to make teachers lives easier. Particularly for schools where teachers might not even know how to program themselves.
> And thus these kinds of programming languages aren’t really for curious students. They’re to make teachers lives easier.
I very much doubt that the creators of these languages are thinking of their creations this way.
Some definitely do. Those tend to be the more successful examples of beginner languages
For example, look at Scratch’s website. They’re not talking to students directly. The way their site is composed is addressing the parents and educators rather than the students.