by 0x54MUR41 on 1/27/25, 5:11 AM with 96 comments
by sitkack on 1/27/25, 8:54 AM
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.
by keyle on 1/27/25, 9:58 AM
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.
by ragebol on 1/27/25, 7:08 AM
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
by EdiX on 1/27/25, 2:47 PM
by librasteve on 1/27/25, 2:00 PM
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>)by broken-kebab on 1/27/25, 11:16 AM
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
by JTyQZSnP3cQGa8B on 1/27/25, 8:40 AM
by Piraty on 1/27/25, 9:45 AM
by voidUpdate on 1/27/25, 9:00 AM
by chaosprint on 1/27/25, 6:01 PM
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.
by dang on 1/27/25, 8:04 AM
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)
by thrance on 1/27/25, 9:28 AM
by BSTRhino on 1/27/25, 11:09 PM
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
by wruza on 1/27/25, 4:15 PM
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.
by m0llusk on 1/27/25, 8:48 PM
by tijl on 1/28/25, 11:07 AM
by lo_zamoyski on 1/27/25, 8:03 PM
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.
by rickydroll on 1/27/25, 4:58 PM
Sorry, my mind makes weird jumps and pulls up movie references
by zoezoezoezoe on 1/27/25, 2:51 PM
by gdevenyi on 1/28/25, 1:46 AM
by zombot on 1/28/25, 5:55 AM
You shouldn't go mention that to the kids, it only gives them ideas...
by svilen_dobrev on 1/27/25, 5:36 PM
by 33a on 1/27/25, 3:44 PM
by nottorp on 1/27/25, 1:12 PM
And no, I'm not a native English speaker.
by oerdier on 1/29/25, 5:09 PM
by kerkeslager on 1/27/25, 5:17 PM
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.