PostHog is an open-source, all-in-one suite of product and data tools including product analytics, session replay, feature flags, A/B testing, and surveys.
From testing in product to analyzing user retention to running NPS surveys, PostHog supports it all. It is a single place to help you test, launch, and analyze new features to help you build a better product.
Front Matter is a CMS running straight in Visual Studio Code. Can be used with static site generators like Hugo, Jekyll, Hexo, NextJs, Gatsby, and many more.
Loving these projects and the interview? Subscribe to the free newsletter to receive the next issue!
🎙️ Interview with Felienne of Hedy - a language for children to learn programming
Felienne Hermans teaches CS at Vrije Universiteit Amsterdam
Hey Felienne! Thanks for joining us! Let us start with your background.
I have the, maybe traditional, backstory of “teaching myself how to program” when I was a preteen. Playing with BASIC, making silly programs for myself, making games. After high school, I went on to major in computer science. I used to work mainly in C# but for a few years I mainly use Python! I really like the freedom that Python offers to sketch your thinking.
What's an opinion you have that most people don't agree with?
Investing in explicitly memorizing syntax you use often is totally worth the effort. Of course you do pick up some things just by using code, but if you want to get more effective, learning syntax is a great (and easy) way to get better.
What’s your most controversial programming opinion?
There can never be meaningful guidelines for “readable code”.
Apart from the basic coding style guidelines, like using Camel case or using verbs in function names, what is readable depends too much on your personal experience and knowledge. Is a list comprehension inherently more readable than a for loop doing the same? It only depends on whether you have seen and used comprehensions before.
Readable code also depends on the task at hand. Is code duplication bad? It depends! If you are making a small change it is not helpful, but if you are trying to get a grasp of the whole code base, duplication helps because it is easier to find information. Are long methods bad? Yes if you are navigating the code base, no if you want to understand control flow.
What is your favorite software tool?
GitHub desktop! Having, I think, a reasonable understanding of how git works, I have tried and failed to deeply understand how to operate the git command line, but the basics just do not make sense to me. Many of the operations does do not align with my thinking about how stuff works. The UX, which I think we can certainly speak of for a command line too is just horrible, and made only for people who have already drunk liters of the kool aid. Like why is “checkout” making a new branch? There is no logic!
GitHub desktop places a usable UX over git, with revolutionary ideas like a button that is called “new branch” for making a new branch. I don’t get why people still prefer the command line for simple things, for I would say 90% of the tasks, you can use Desktop. (of course I sometimes use the command line for very complex merge conflicts but that is really limited to a few times a year).
What is your favorite book and why?
Let/s limit this to books about programming! Certainly “Working in Public” has made a huge impact on me recently. It gave me vocabulary for the things I was struggling with in managing Hedy. The book talks about how open source has changed from projects that were, in essence, clubs in which people knew each other, because the burden of entry was high (which of course in itself was very problematic too!) to projects that are more performances, in which a small group of people work “in public” and a large group of casual contributors dip in and out of the project, because with GitHub everyone can so easily open issues and pull requests, without really knowing the project.
If you had to suggest 1 person developers should follow, who would it be?
Grady Booch, most well known as the creator of UML, but nowadays both fighting AI nonsense on Twitter, and standing up for diversity and inclusion in the field.
Why was Hedy started?
As with most projects I think, to solve my own problem! I was teaching middle schoolers programming (aged 12), and they found Scratch and other block-based languages to be too childish, they wanted a “grown up” language. That is of course very fitting for that age group; teenagers want to do stuff that adults do too. However, textual languages like Python or JavaScript are made to work with as a professional, they are not made to learn with. Just outputting something like “hello” already requires brackets and quotation marks, which for novices is very distracting. You can’t really learn about the concept of printing, without also learning a lot of syntax. And for more advanced concepts like conditionals or loops, the syntax is even weirder. Many of the kids in my class would eventually learn how to type “for i in range(4):” but they did not really grasp repetition as an idea.
And, the error messages were so cryptic, especially for non-English speakers that I was teaching. What is a “Syntax error”, why is this “indent” “unexpected”. I had to run around all the time to put out small syntax fires, rather than talk about the cool things that kids could achieve with programming.
So I thought… What if I make a programming language that works in small steps? First we teach a concept, and then we slowly add the syntax. So first print hello, and then print “hello” and then print(“hello”). In the winter of 2019 I made the first prototype, just to be used in my class.
After a year, 100.000 Hedy programs had been created, and we had received several translations like Spanish and French, so I knew I was onto something! Fast forward to today when we have about 400.000 people on the site monthly, and are available in 47 languages, including non-latin languages like Simplified Chinese and Hindi and right to left languages like Arabic and Urdu. In terms of open source, we have over 350 contributors to date, and we merge about 75 pull requests a month. So it has been quite a ride!
How does Hedy work?
We have a really cool (hand drawn) overview of the architecture in our Wiki:
It summarizes what we do: The basic idea of Hedy is that we allow learners to write code using the Hedy syntax, in a web page. The code page, and other web pages, are rendered by Flask (a Python web framework), using templates in Jinja.
When running Hedy code from the webpage, the Hedy code is converted (transpiled) into Python on the server side, using the Lark parser framework. The transpiled Python code is sent to the front-end and run in the front-end using Skulpt, a Python interpreter written in JavaScript.
Why did you pick Python?
I chose Python because I knew Python, and because the Hedy learning trajectory leads to Python. This is also why we transpile to Python, because it is close to Hedy. In retrospect, this was maybe not the best move, because it means we have to rely on Skulpt to execute the Python in the browser. I really hope browsers will implement running Python so we can do that in a more direct way! (it is too late I feel for us to still switch to generation JavaScript directly).
Where did the name for Hedy come from?
Hedyis named after Hedy Lamarr! She is most known as a movie actress, but she was also an inventor, who helped develop the “frequency hopping” algorithm that you use everyday, since it is in Wi-Fi routers!
Who, or what was the biggest inspiration for Hedy?
Kids in my classes that were struggling with error messages, especially the girls who would come in a bit nervous already into programming class. If they first thing you then see is “SyntaxError, unexpected EOL” it is easy to think you are not smart enough to be good at computers.
Are there any overarching goals of Hedy that drive design or implementation?
Yes, we have even documented our design goals for the language: https://github.com/hedyorg/hedy/wiki/Hedy-Language-Design! There is sometimes a trade off and to be honest we have sometimes sinned a bit against the design, because you want to have a language that is simple, but you also want kids to build cool programs that they are excited about. So some early levels add concepts (like sleep and clear screen) that are maybe a bit early in the learning trajectory but add depth.
What is the most challenging problem that’s been solved in Hedy, so far? And what was the most surprising thing you learned?
Everything to do with localization, specifically for non-Latin languages. Did you know Arabic numerals (0, 1, 2, ..9) are not used in Arabic? I certainly did not know that before I started working on the Arabic version of Hedy. There were so many things to think about! The use of accents is another interesting issue, in French, repeat is “repété”, but what if a kid uses “repete”? Is that a syntax error or should it be allowed?
English is a really simple language in terms of spelling, and therefor in PL design, a lot of concepts from other languages have not been considered. Like, we have the concept of “case sensitivity” but not of “diacritic sensitivity” to decide between “repété” and “repete” because English does not have accents. While localizing Hedy I ran into so many issues I ended up writing a paper about it: felienne.com/archives/7668.
If you could teach every 12 year old in the world one thing, what would it be and why?
What we are trying to do with Hedy is teaching all kids that programming can be learned. Many kids without prior programming experience, often girls and kids without a computer at home, feel programming is scary and not for them. Existing solutions don’t really address that well. Visual programming languages like Scratch don’t “scaffold”; they don’t tell you where to get started and how to approach things. Textual languages on the other hand, like Python or JavaScript start with throwing error messages around before kids have a chance to figure out if programming is for them, or even what programming *is*.
We teach them that even though, like with all subjects, some kids go fast and some so slow, some reach far and others just take a steps, everyone can do a little bit of programming!
If I gave you $10 million to invest in one thing right now, where would you put it?
Hedy! We have so many things to explore still, improving error messages, helping teachers get better insights into what kids are doing and where they are struggling, using a combination of parsing and AI to translate programs from one natural language to the other so that all kids can learn from each other!
What are you currently learning?
Managing a large open source project. Hedy was never really meant to be a large project and in the beginning I really did not know how to manage it, in various ways! I did not really look at code in depth, when people submitted PR’s I mainly looked at whether it was working, and whether the code was not terrible, but I did not look at whether the style fit the project, or whether the
What have you been listening to lately?
In terms of music? Bob Dylan, always. The thing about Dylan’s music is that there is a Dylan album for every mood, he has old school blues, but also stuff more leaning towards gospel, jazz, and pop. So whatever you are in the mood for, Dylan is the way to go.
How do you separate good project ideas from bad ones?
One answer to that is that I am a teacher, and I teach with Hedy myself, so I often have a feel for features that could help teachers. As a maintainer, I also have a lot of contact with other teachers that use Hedy, on our Discord channel with regulars, and in workshops we give to new teachers. But sometimes we still invest in “the wrong” features because they are interesting to build, or because we think something will be helpful while it is not.
What’s the funniest GitHub issue you’ve received?
I am not sure if this is really funny, but there was someone who made an issue (github.com/hedyorg/hedy/issues/1908) about quotation marks in my LICENSE file. I kindly asked him to bugger off after this issue/PR. It was interesting because I told him stuff like this was really overwhelming for maintainers, and after a while he replied saying that he has muted the repo since he was also overwhelmed with activity from it.
But looking back at this interaction, it is nice to observe that I have grown so much as a maintainer. Nowadays, I would not even accept such a silly PR and tell people a lot earlier that this type of behavior is harmful. We now also have strong community guidelines about unwanted suggestions, and a Discord server where we hang out with each other to joke about this kind of stuff.
What is your typical approach to debugging issues filed in the Hedy repo?
For errors about the Hedy language, I almost always start with writing a test and see if I can reproduce the error from a test. If I get there, I know fixing it will be doable. We are really big on TDD like development for the language part. See that it breaks, fix the test, see that no other tests are broken and then try to improve. We have a lot of manually written tests for the language, but we also have a test set of about 10.000 programs created by kids previously, which we also shouldn’t break with new changes (or at least not unintentionally).
What is the release process like for Hedy?
Every merge to main goes to our test environment, where we sometimes invite teachers to try out stuff, and where we also manually test some front-end features to see if all goes well and looks well. Usually we deploy the test environment to hedy.org every Friday late afternoon. This makes sense for us since then our traffic is lowest since schools are out :)
Although every core contributor could do this, in practice I am always the one doing this (I am not even sure they know they could, haha!)
Is Hedy intended to eventually be monetized?
It is meant to be free and open source. I think it is quite wicked actually that schools spend so much money on software (and other digital materials!) while there are so many people that would build software and materials for free. I am happy that may tools for programming (code.org, Scratch, us) are showing that software can be both useful and user friendly and also free for schools.
We are funded mainly by government subsidies from the Dutch government and occasional donations on GitHub (which are nice, of course) and a lot of volunteer effort!
What are you most proud of?
Hedy definitely helped me in my career, because it got me the award for best CS researcher of the Netherlands (a small country, but still). But I think the best moment was when after schools were closed because of Covid, in the summer of 2021 I saw kids working with Hedy in real life, for the first time. Seeing the product come to live, to really see kids interact with it, was mind-blowing!
How do you balance your work on open-source with your day job and other responsibilities?
It is a bit hard to say because as an academic, it is not so well defined what my job is. Certainly inventing new things is my job, so a big part of Hedy is just what I am supposed to do.
What is the best way for a new developer to contribute to Hedy?
Be excited about what Hedy is! Our docs explain that our most successful contributors fall in love with the idea, goals and philosophy of Hedy first, and look around to see where help is needed. Less successful contributors find small issues that bug them and submit pull requests without looking at issues that we created.
If you start to love Hedy, join a bi-weekly contributors meeting. I think one of the best things I have done for my own enjoyment is start to have online meetings with regulars. It eases further (so often written) communication so much if you get to speak to each other, and we laugh a lot about silly ideas and plans and mistakes. It really created a team feeling and I am surprised I don’t see this more often in OS projects. It is so worth the hour I put in every two weeks!
What motivates you to continue contributing to Hedy?
The emails we get from people all around the world telling me their teaching has gotten so much better with Hedy, that their students are learning more and having more fun! It really shows we are on the right track.
Are there any other projects besides Hedy that you’re working on?
None at the moment, because:
Do you have any other project ideas that you haven’t started?
I have been forever dreaming about a better refactoring tool (one to perform “cognitive refactorings” as I outline in my book) but I know I will never build that, it is too much work on top of everything. Throwing it out here so maybe someone else will haha!
Where do you see software development heading next?
GPT and Copilot and the like of course is an interesting development that has people reflect on their practice a lot. If done well they can really improve productivity, I recently used GPT to explain to me how to use a certain API, and it was impressively helpful, it really saved me a lot of search time! But it can also generate senseless stuff, or code with subtle bugs that are hard to spot. So I hope we will invest less in the hype and more in the “if done well” part. I certainly believe in GPT for code more than for text, because it can be executed, so many (not all!) errors are caught early on.
Where do you see open-source heading next?
I don’t know. “Working in Public” does paint a bit of a bleak picture in which the small number of maintainers will not be able to keep up with all contributors and users needing their attention. And I fear for a world in which that attention will also have to be split with “smart” bots that auto generated PR with an issue text as prompt! That is a dark side of GPT I see, sadly.
Do you have any suggestions for someone trying to make their first contribution to an open-source project?
Find an issue you think you can do (maybe look for things labeled “good first issue”) and then reach out to the maintainers as documented in the docs. Some people want to get an email or a Discord message, others state that you can just go for it, but look at the preferences and follow these! That gives you the best chance of getting positive feedback.
Loved this interview? Receive more like these every week by subscribing for free!
Interested in sponsoring the newsletter or know of any cool projects or interesting developers you want us to interview? Reach out at osh@codesee.io or mention us @ConsoleWeekly!
