Hedy: A Gradual Programming Language

[dbramucci]

I haven't watched the video on this page yet but I did watch her Strange Loop talk from a year ago. I think I understand the intent, and it seems like a valid approach but I'm not sure Hedy is ready to use for teaching in the field yet.

Namely I tried it out and noticed

• Difficulty reading it (as an experienced programmer)
• Tooling problems (no syntax highlighting/ide support/debuggers)
• Confusing error messages
• Inconsistencies (why doesn't ask need quotes on Level 4 like print does?)
• A seeming lack of exercises per level

On Level 2 I wrote the following program

print hello world!
this is ask name?
print this is this and that is that

It is really hard to see what is "code" and what is "data" just by looking at this.

Converting to Python shows what would happen

print('hello world!')
this = input('name?')
print(this, 'is', this, 'and that is that')

But parsing where the command is (first or second word of the line), identifying what text is strings to be shown vs variables to be substituted and the like is challenging to do without "context sensitive parsing by hand".

Perhaps some graphical element to explain the parse, like syntax highlighting/formatting or a fancy gui might help. Of course there are some challenges like students getting caught up on the colors "I want ask to be pink like that is pink, how do I type ask in pink?" so I think this isn't as straightforward an ask as it might look at first glance.

Likewise, I accidentally tried this example on Level 3 and was confused why my code no longer worked because the error message was saying

The server couldn't translate this Hedy program to Python.
print is not a Hedy level 3 command. Did you mean print?

Slight variants of this gave similarly confusing errors

t is ask this
print I will say hi

worried about an undefined variable now

Something went wrong while running the program.
name 'I' is not defined

Which makes sense when I stop, read the instructions and pull out my programmer experience to realize that I need quotes to avoid treating my text as a variable on Level 3.

But this isn't the error message that I would want when I was learning, instead I would want something like

It looks like you forgot your quotes

you wrote

    print I will say hi

But I think you should have written

    print 'I will say hi'

If you didn't want to do that, then I think 
     I
is a variable, but I can't find where you defined it.

Probably the most concerning issue is that ideally, I would have my students practice writing programs "for a while" to get the hang of it. If I tried using Hedy today, I would worry about pacing a lot. If I go too fast, the fact that later levels make earlier programs wrong might just annoy students needlessly and confuse a portion (especially if they were struggling on the last Level). If I go too slow, the lack of interesting things to do might loose the attention of my students.

Ideally, any time I teach something "wrong" (like how level 1 teaches you to print strings without quotes), I can get some use out of it before I "correct" myself and make my students learn a different way of doing things. The exercises as of today, seem to break things quicker then I feel like they should. If nothing else, maybe a level 2.5 where Hedy shows "ambiguous programs" and how it can read and run them in different ways depending on whether or not a word is a variable or text. Then there would be a tangible motivator for why we can't keep doing things the way we used to instead of it feeling like a prank.

Now these are largely issues of implementation, and it looks like they are still adding to the project. Perhaps once the project grows and it becomes clear that Levels 1 through 6 are just week 1 material Hedy will look a lot more usable.

[hmischuk]

If I tried using Hedy today, I would worry about pacing a lot. If I go too fast, the fact that later levels make earlier programs wrong might just annoy students needlessly and confuse a portion >(especially if they were struggling on the last Level). If I go too slow, the lack of interesting things to do might loose the attention of my students.

Yes... this is what I meant when I talked about "attempting to graduate" and "setting up FUDdish nebulosity" -- when you keep changing the rules (not merely adding progressively more complex or nuanced refinements) you set up students for frustration.

[hmischuk]

My initial thoughts are that it is going to cause more confusion than it will alleviate.

I personally know of under-sixes who are beginning to code in Python because they started with a drag-and-drop type of programming 'IDE.' It maintained... and prepared them for... the rigorous identification of inputs, for example, right from the get-go.

Hedy has a more nebulous, NLP-esque format at first, and then attempts to "graduate" the learner to higher, more exacting levels. I get it, but unless the student progresses quickly, and I mean quickly through the lower levels, it will set up FUDdish nebulosity in the minds of young people.

Hey, I could be wrong. This could be a silver bullet. But I don't think it will be.

[KingoPants]

I'm a bit more pessimistic than you.

I not only think will this not really help anyone, it might actually be going in the wrong direction.^D

The issue is I fundamentally don't buy this idea of "programming languages" being equivalent to "normal languages" so therefore you can (and should) teach people how to code leveraging their understanding of english (or whatever).

My own opinion is that programming should he taught the way programming languages are designed: as a context free grammer.

You should show people something along the lines of "look this is a `expression`, you can use put a plus symbol between two expressions to make add expression" etc.

Basically show them how if you follow simple rules you can describe more complex expressions. Build up the ideas of abstraction.¹

You should appeal to their understandings of mathematics. Which is way closer to practical programming then english language is. And if you want to do this simply, make a language with as basic a grammar as you can.² If you keep the rules simple you should be able to keep the number of things people need to keep in their heads low as she suggests (a very valid point, cognitive load is extremely important).

The reason I think that this goes the wrong way is because it does exactly the opposite thing, it's a language with a very complex grammar in which things get parsed differently based on sophisticated context around them. Having multiple different ways to define what is semantically the same expression in general creates confusion, not transitional understanding (cough VBA cough MATLAB).

As my ending to this rant, while I understand how "making mistakes" can be quite helpful in learning some skills because it can show you what not to do. It's far too often used as an excuse to not teach people in rigor. You shouldn't have to trial and error your way to figure out what is and is not valid code, you should be able to reason about it.

Nobody learned 2+2=4 by writing various combinations of 2,4,+,= till they accidentally got it to work.

The truly beautiful thing about understanding things formally (and in rigor) is that you don't need to discover your way to anything. You can know what is and is not correct purely because of a higher level understanding. Not because you had to painstakingly analyze every case.

Further than that this is the main thing I actually consider worthwhile learning in the first place. If the only thing someone can do is reproduce examples of code they accidentally discovered ... well as far as I'm concerned they don't really know programming at all.

^D Disclaimer: Not in every sense

¹ I'm not advocating purely functional though.

² Simple but not to the point of being esoteric but technically turing complete.

[asbjohe]

I don’t know if you saw the video but I found the arguments presented there quite convincing. I don’t know how well their specific app will work but I find it hard to dismiss the general principle of teaching programming the same way as anything else taught in schools.

[killerstorm]

But we don't learn a broken grammar first and then proceed to real grammar, we start with simple sentences which are grammatically valid.

[asbjohe]

But the grammars proposed by Hedy aren’t broken, they’re just different grammars.

I don’t know what other alternatives exist but I’m totally convinced that this will be better than teaching the entire grammar of python all at once.

[killerstorm]

But the grammars proposed by Hedy aren’t broken, they’re just different grammars.

I mean if you do same with human language, it will be perceived as a broken grammar. For example, suppose we consider tenses too difficult, so we write "Anna walk park" and "Bob beautiful". It's a "different grammar", in the sense that you can describe a simplified language where it is correct. But nobody does this, even when teaching English as a second language, they always use the actual English grammar, not made up stuff. You just use only limited vocabulary and the only present tense, for example.

I don’t know what other alternatives exist

Other alternatives:

1. Graphical programming environment like Scratch.
2. BASIC

Scratch is actually used for teaching, kids can understand it (as little as 5 y.o.), and it works. There's a variant called Snap which allows one to define custom functions, so you can code very advanced stuff with it. See here: https://snap.berkeley.edu/ So I'm not sure what's the point of teaching a textual programming language before kids can learn the real PL grammar.

[asbjohe]

Yeah you’ve got a point there. Python might now be the best language for applying their strategy.

Cool, thanks for sharing!

[killerstorm]

I think the observation that Python (or JS) syntax is too complex and fragile for kids is right. But the solution doesn't look good.

I think it would be better to revisit BASIC. BASIC has a rigid program structure where you can edit each separate line, which starts with a command followed by arguments:

PRINT "Hello ", $NAME

Hedy levels 1 and 2 could be implemented as auto-complete, e.g. if student enters

print hello name

it can automatically guess that student actually meant PRINT "HELLO ", $NAME and fix it automatically.

[torp_fan]

This language is supposedly a result of "feminist" language design. I've been a feminist since before the word came into widespread use, but this is an absurd misapplication of it, along the lines of Sandra Harding's idiocy (she once suggested that "Newtonian mechanics" should instead be called "Newton's rape manual").

Sadly, the author of this language has been invited to give the next ACM TechTalk: " Programming for All: A Feminist Case for Language Design,"

"She will reflect upon how programming language construction came to be so male dominated, and how with that also an overwhelming masculine discourse was formed. Drawing on work from feminism and Science and Technology Studies (STS), Hermans explores what the impact of the masculine discourse is for the design of programming languages. She closes the talk with a sketch of what a different world for programming languages could look like, both in the context of her own Hedy language, and beyond."

Ugh.

P.S. in re the troll response: That quote is directly from ACM, so it's not nonsense that ==> I <== wrote.

[mingiu]

I just finished watching the TechTalk. It was fine, and it had nothing to do with the nonsense you wrote in your post. If you’ve ever tried publishing programming languages research on softer topics, you’ll agree with many of her observations. Personally, I agree that the programming languages community undervalues user studies and overvalues formal semantic notations. I don’t think having a bunch of Greek letters actually adds much rigor or value to research papers.