Hedy: Textual programming made easy

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.

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.

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

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.

here’s some raku lang in welsh… https://github.com/finanalyst/rakuast-L10N-CY

  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>)

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

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://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?

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.

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.

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

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)

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.

> Hedy also works on phones and tablets.

You shouldn't go mention that to the kids, it only gives them ideas...

https://www.youtube.com/watch?v=8vjEnkQdaHM&t=2s

Sorry, my mind makes weird jumps and pulls up movie references

Tisk tisk using my location information to decide on the webpage language instead of my preferred headers.

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.

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.

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.

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.

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.

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.