Hedy: Textual programming made easy
hedy.org
hedy.org
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.
https://www.youtube.com/watch?v=IrUh5AgIYKE
https://youtu.be/-Br66SUjsdQ?t=12103
(I was also at SPLASH24 and thought she gave great talks. :) )
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.
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 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)
OCaml was written in 1996 by Xavier Leroy, Jérôme Vouillon, Damien Doligez, and Didier Rémy at INRIA in France
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.
That's not some immutable law of the universe - 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.
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.
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.)
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.
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.
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.
Learning language - fine, use whatever language you want
Excel - spreadsheet logic breaking when you open it with a different locale - horrible
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.
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.
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
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
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.
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.
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>) 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.
cisAnd 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
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.
Disclaimer: I've been involved with the project (in a tiny way), and am a fan.
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 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!
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.
AI
The best learning tool, "stepping stone" for kids. And they're already familiar with it when cheating on their homework.
I wasn't saying that AI is not here. It is, and it is very important. 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.
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.
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.
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.
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.
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.
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.)
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
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.
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)
Your take might be different, you probably have something to add to the https://www.hedy.org/ project.
We really gotta get all the good ideas in our head out into the world. What other ideas do you have?
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
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.
But in the end, it is a starter language and it looks like your kids started!
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.
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.
Sorry, my mind makes weird jumps and pulls up movie references
You shouldn't go mention that to the kids, it only gives them ideas...
And no, I'm not a native English speaker.
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.
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.
I very much doubt that the creators of these languages are thinking of their creations this way.
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've met mres, talked to him 1 on 1, and that guy is definitely wants to empower curious students. He probably isn't opposed to making teachers' lives easier, but if you talk to him about what he's trying to do, what he's excited about, that's clearly not it.
I'm so tired of talking to confidently incorrect people on this website. It is okay to not know things. It is okay to not have an opinion. When you form uninformed opinions and then smear them all over the internet, you're doing harm. Stop. You don't have to say every thought that comes into your head, and you should not.
Like, you just accused a whole team of people who has poured countless hours into something they hope will help students of not caring about students. How does that not bother you?
Well yes. Because if a website is marketed at teachers then it's hard to argue that some of these projects aren't marketed at teachers.
I don't understand why you find that such a controversial point to make.
> I've met mres, talked to him 1 on 1, and that guy is definitely wants to empower curious students. He probably isn't opposed to making teachers' lives easier, but if you talk to him about what he's trying to do, what he's excited about, that's clearly not it.
You've misunderstood me. I'm not saying these tools don't benefit students as well nor that the developers of these languages don't also have students in mind. Just that it's the teachers who introduce students to them rather than students who seek them out.
Most of the time, if a student already knows enough about computers to understand the concept of a programming language, it's because they want to do something useful with it rather than just playing. And then they'll likely have already discovered proper languages like Javascript or Python. Or maybe even something more low-level.
Teaching languages are usually picked up by students only after someone (namely an educator or parent) has introduced that student to them.
For example, you don't decide you want to build a robot, or website, or computer game, or whatever and then find training material to build it in some random teaching language. Just in the same way how you wouldn't find any training material online for doing it in COBOL or FORTRAN. All the material online will be focused on established general-purpose languages.
So students don't discover learner languages just by accident. They generally discover them through educators or parents.
> I'm so tired of talking to confidently incorrect people on this website. It is okay to not know things. It is okay to not have an opinion. When you form uninformed opinions and then smear them all over the internet, you're doing harm. Stop. You don't have to say every thought that comes into your head, and you should not.
I've worked with several teachers to set programming curriculums at a few schools. I got this exposure because my wife is a teacher, as is most of her family. But the end result is I know quite a bit about how programming is taught in schools and which programming languages are picked because I've been the one to define that. And I don't get good at defining this without understanding what kids already know and what they want to learn.
That all said, I'm not going to pretend to be an expert on this topic. But I certainly have a great deal more insight than you think (this is a great lesson in who you shouldn't make assumptions about other people).
> Like, you just accused a whole team of people who has poured countless hours into something they hope will help students of not caring about students. How does that not bother you?
Good grief, where did I say the developers of these tools don't care about students?
You moan about other people HN and yet you're the one making low-quality comments here.