Can Programming Languages be Feminist? with Felienne Hermans

In this episode, we talk to Felienne Hermans, Professor of Computer Science Education at Vrije Universiteit Amsterdam, about how feminism can reshape the way we think about programming and technology. She explains how exclusion is built into the very structure of programming languages, which often center on English and Western norms, making it harder for non-English speakers to participate. Felienne introduces Hedy, a free, open-source programming language that supports over 70 languages, including Arabic, to make coding more inclusive for children worldwide. We also explore what makes technology “good,” and how feminist thinking can help create tools that value diversity, creativity, and empathy, ultimately making technology more human and accessible for everyone.

Felienne Hermans is a Professor of Computer Science Education at Vrije Universiteit Amsterdam. Her research focuses on how people learn to program and how programming languages can be designed to support learning for everyone, regardless of age or background. She is the creator of Hedy, a gradual programming language for beginners, and author of The Programmer’s Brain, a book that helps developers understand how coding and learning work together. Felienne’s work combines computer science, education, and social awareness to make programming more inclusive across the world.

Reading List:

• www.felienne.nl and https://www.felienne.nl/english/

• A Case for Feminism in Programming Language Design https://dl.acm.org/doi/10.1145/3689492.3689809

• Framework for Localization of Programming Languages https://dl.acm.org/doi/10.1145/3622780.3623645

• The Programmer's Brain: What Every Programmer Needs to Know about Cognition https://www.felienne.com/book 

Transcript:

Kerry McInerney (00:57)

In this episode, we talk to Felienne Hermans, a Professor of Computer Science Education at Vrije Universiteit in Amsterdam. Felienne explores how discrimination shapes the field of programming and why we need feminism in programming language design. She explains what a programming language is, how they all have different personalities, and why it's so difficult for computers to deal with ambiguity and doubt. She also tells us about her experiences designing programming languages for children, and she dives into a specific programming language she made, called Hedy, which combats the lack of linguistic diversity in this field by allowing you to program in 47 different languages. We hope you enjoy the show.

Kerry McInerney (01:38)

Fantastic. Well, thank you so much for joining us. We're really genuinely so delighted to have you on the podcast. But could you just, for the sake of our listeners, introduce yourself, say a little bit about who you are, what you do, and what brings you to feminism, gender, and technology?

Felienne Hermans (01:53)

Absolutely. My name is Felienne Hermans. I'm a Professor of Computer Science Education at Vrije Universiteit in Amsterdam. And my research used to be, I want to say, about how to teach kids programming. That's also why I'm a professor of education. But in the process of designing programming materials and ultimately also a programming platform for children, I just ran into all these...first, it wasn't walls. I want to say walls, then first it was like little hurdles, and then just bigger hurdles, and then all these different forms of exclusion in the design of programming language systems that at one point I thought, well, I need feminism to understand this. And then when I understood feminism, I thought, no, now I need to tell people in the programming language design space about feminism. So last year I wrote a paper called “A Case for Feminism in Programming Language Design”.

Eleanor Drage (02:45)

Which is a fantastic paper, and we will link it with the episode at the end so that people can read. Now, for our big good robot question, what is good technology? Is it even possible, and how can perhaps good programming languages help us get there?

Felienne Hermans (03:02)

So I definitely think good technology and let's say, good programming languages are possible.  Initially, when I ran into these issues, let me give a small example. So one of the things we were trying to do is make programming languages not so dependent on English, because not everyone speaks English. And first, I did it for Dutch, which is my native language. And that was sort of easy because Dutch and English are very, very similar. But once we started to add languages more different from English, all these little things and later bigger things popped up.

And at one point, we go to Arabic because one of my best friends is from Palestine. He's like, “Wow, can we do this in Arabic?” And then I realized that no programming language can really deal with Arabic. Arabic has different numerals, for example, even though we call Arabic numerals, that's not what most people in Arabic cultures use.  And then if you just enter wahat, which is one in Arabic, wahat, wah, wahat in any programming language like Python C, JavaScript, doesn't matter, just errors out in a horrendous way. It has something like an invalid character or an invalid symbol, even though this is what people use. And then initially I thought, “Oh, I can fix this, right?” I thought, “Oh, better technology can exist just by programming.” So I spent a lot of effort and I made our whole system, it's called “Hedy” by the way, a free and open source programming platform. So I made it in Arabic, and I was like, “Oh, look, there, there, we fixed it, right?” But then I realized that a lot of people in our community were not so interested in fixing this problem. They were not so interested in hearing about the problem because "they" can "just" learn English. But maybe people don't want to learn English, and maybe people are just happier or more, it nourishes their soul more if they program in their own native language, which is even true for me in Dutch. So my own thinking has changed from, “Is good technology possible?”

First, my answer was “Yes, and I built it.” And now my answer is more, “Yes, it is possible, but it will require systemic change of the technology community and a change of being interested in things to being interested in people and cultures and the softer, sometimes described side.” So, yes, I'm still an optimist, but my solution has really changed because of my engagement with feminism.

Kerry McInerney (05:28)

That is just a really, really fascinating story. And I wonder how many people who kind of work now at the intersections of ethics and computer science have had a similar journey where they've been incredibly excited about the potential that computer science as a field has to offer and things like programming has to offer for the way it can really improve our lives, but then have also hit up against these walls of exclusion that have made them think twice about a lot of the norms of the discipline and the way that things are done. Before we dive a little bit more into your experiences, though, and also the kinds of solutions thinking about. I want to take a big step back and actually ask, what is a programming language?

Felienne Hermans (06:04)

That is a great question, and it's also part of the topic of my paper because what is a programming language is is not so easy to answer, right? So there are very, very easy answers like JavaScript, the language that the web is made of. Most people will say that it is a programming language. You use it to program websites or Objective-C, it's used to create iPhone apps. These are things, they are easy. But then, on the fringes, that are things that are harder to define. An example might be HTML, which is a programming language that's also used for the web, but not necessarily to describe what functionality a website has, but what it looks like. And there already, programmers would say, “That's not a website because it doesn't program functionality.  It's just to make it a little bit more pretty.” Whereas other people might say, “Well, it is a programming language because you use it to control a machine.”  And another example that many people might be super familiar with is spreadsheets. I would definitely say that spreadsheets are a form of programming. They have formulas, something like if,  sum if, or count if is in a spreadsheet, and if is one of the most basic building blocks of any programming language. However, then people from this programming language community will say, “No, that's not programming because it's too easy. Everyone can do spreadsheets, right? Your accountant is not a programmer, but they can do spreadsheets, or I don't know, volunteers at the church use spreadsheets, and they're not professionals in any way.” So what is a programming language? It's also very much this is what I say in the paper as well, a social construct where people who have the power of programming would like it not to be all too broad because then everyone can do it, and that will lower social status, and social status is cool.

Eleanor Drage (07:47)

Tell us about programming languages themselves because you said in this fantastic workshop that you held at the Computer Science Lab at Cambridge that programming languages have their own personalities. What does that mean, and why is that an issue?

Felienne Hermans (08:04)

Yes, this is very hard, probably to grok for people that aren't programming people that any programming language, to a certain extent is the same, right? They all have the same building blocks, like an if and something that can repeat. They're not different from each other. However, they are different from each other in very different ways than their specific capabilities. Their use might be different. Some programming languages offer you a little bit more freedom or a little bit less freedom. And that makes it different for you to express yourself because more freedom is nicer than you can spitball more, but then also it might be easier to make mistakes. Whereas less freedom might be safer, but might also be more constrained. And I think the best maybe comparison is materials for making art. Charcoal and paints can both be used to make pictures, but they have different aspects. They're more tolerant to mistakes. You might need more or less training to use different materials. So in that sense, also programming languages are also different.  And with those capabilities, also different communities are formed. So maybe people who like freedom more are a different kind of people with different types of goals and interests in life than people who like safety more. They might design different things.  And  I once read this tweet. I don't know who it's by. Maybe we can look it up.  It's something like… “This is what no sci-fi author could have predicted. People form clans around the languages they speak to the machine.” And I thought that was so beautiful because that is absolutely something that's happening in programming. People will identify with their programming language. They will have t-shirts like, “I'm a Java programmer”.  And they will have stickers on their laptops. There's a programming language called Rust. And people call themself, “ruststations” and they identify as that. They put this on t-shirts and tote bags, and laptops.  So it's not just a tool. It is a club that you get to be a member of. And then of course with any club will always come both community and exclusion. That's just how a club works.

Kerry McInerney (10:15)

This is so fascinating because again, I don't come from a background in computer science or in programming, but I feel like it's really interesting because we have in the arts and the humanities, certain kinds of clustering as well around certain philosophers or thinkers. And you say, “Oh, I identify with like this way of thinking about a problem.” And so it's a really, really interesting and quite funny to see the way that these sorts of divisions are operating, but at the level of the programming language. Something I did want to ask about was, you know, a core issue in AI ethics, something we're often thinking about is explainability. So, explainability can mean many different things to different people. So it can refer to being able to understand how a particular system made a decision. But, it also kind of poses this complex question of like, explainable to who. So, I think when we're talking about explainability, we're also talking about not only communication, but also this core question of education, is why I'm particularly interested in your perspective on this question, because I don't know very much about programming languages and explainability. So, are most of these programming languages very explainable? And if not, what do you think needs to be done in order to make them more explainable?

Felienne Hermans (11:21)

That is such a great question. So explainable is already a hard-to-capture word, but one interpretation in terms of programming language design that I can give is that as soon as you learn a programming language, you have to obey the programming. So when I was teaching 12-year-olds or 18-year-olds or even adults, if you teach them Python, this is the rule, right? So, for example, if you want to have text on the screen, you have to type print and then have to follow parentheses, and in between the parentheses have to follow quotation marks, and that's where the text goes in. And a lot of people then yearn for explainability. They say, “Why is this the case? Why round parentheses? Why not curly ones or rectangular ones or triangular ones or whatever, or why those things at all?” And the interesting thing is, if you want to penetrate the world of programming, you have to obey. And I know I have said this as a teacher, and I don't feel great about it, but I've said to those types of students, “Don't worry about it. Just do as I say, but not even as I say,  just do as the programming language designer has intended”. And of course, you can explain it because a lot of the things, there's some reasoning behind it, often historical, we do it like this because another programming language does this. So, you can explain it, but at that beginner's level, not so very valuable. And one of my friends who's a journalist, I spoke with her about this a while back. And she also said, “When I was in journalism school, I took a programming course. And it's just like, this was undoable to me because I was asking those questions of why, and a teacher would say, ‘Don't worry about it.’” And she said, “I'm a person who likes to ask questions.” This is why she's a good journalist. “So, if in this space of programming languages, questions asking and getting explanations for things. If that's not on the table in this field, I don't really have an interest in this field”. I thought, “Wow”, right? That is so true that the way of explanation, if you learn programming, is hidden from you, it's forbidden to ask for that knowledge. That's so much shapes who stays in the field, both the people that stay in and that drop out, but also the people that will not drop out will have a certain way of thinking, much more likely than a different way of thinking.

Eleanor Drage (13:50)

Absolutely. How can you trust something that doesn't give you an explanation for why it's asking you to do something? Which is why a really central part in lots of different faiths is doubt and asking why and being unsure before you can fully commit to something. Another really interesting thing that you look at, has lots of overlaps with my background in queer theory. Is thinking about the ambiguity of the world. The world isn't black and white. There's so much uncertainty. Even to ourselves,  we are growing, we are constantly becoming, we're not fixed. And these are staple ideas in the humanities, in social sciences as well, but particularly in queer theory, which is my background. And I love that you look at this idea, the problem of ambiguity, and of how we become as people and grow through our interactions with the world in your work in computer science. So, can you tell us, how does computer science deals with ambiguity?  And not very well, I hear from what you said. And how could it be different?

Felienne Hermans (15:08)

Yes, so I was going to say not very well, because in such a programming space, right, not only do you have to put brackets there, as soon as you express yourself, the program has to run, and computers run on binary logic. So if you want to express a vague idea, if you're like, “I don't know where this is going”, you cannot really express it in the programming language, for a little bit. But then, as soon as you want to run it, then the computer will say, “You have to make a decision. Is it this or this?” Otherwise, the computer cannot deal with it. And you don't really have the freedom to defer a decision. Like this data type, “I don't know, will it be a number or a string?  I haven't decided yet. I need to explore more.” And then that exploration cannot take place within the programming language. You could do it on a whiteboard, which programmers do, and you can talk and think. But as soon as you enter it into the computer, ambiguity is scratched. It is no longer available to you because the computer cannot deal with it. And there's actually some feminist work in the programming language design space that has looked at, can we make programming languages softer in any way, which is, think, even if you wouldn't build it, just an interesting way to think.

Eleanor Drage (16:33)

I love that you said soft because softness tends to be used in the pejorative to describe soft skills, women, soft labor, but versus hard science, hard skills, the hardness, the rigidity of programming languages. So when you say soft, what do you mean?

Felienne Hermans (16:56)

Yes, so it would be so interesting to explore, what would that look like, right? It's even hard to imagine what it would be, right? What would a programming language be that would allow for more ambiguity? And what you see in that space is that a lot of people push back. They're like, “No, but if you have ambiguity in a programming language, then it will crash, right? And then maybe it will run on the nuclear power plant, and then a mistake would happen, and it would have serious consequences.” And I'm like, “Yes, but we have programming languages that are perfectly designed to run nuclear power plants.” I would like, in addition to this, to explore what this would look like. And it's really hard both from a technology and from a cultural perspective to even ask this question because most people who participate in this field, as I was saying before, either by self-selection or by repeated exposure to 'everything in the world is black and white and zero and one and that's just what it is', that way of thinking of questions, of ambiguity, of being allowed differences of opinion and still working together in a project, that is just not something that's encouraged in computer science curricula and therefore culture. That, I feel in myself that I want to explore that question, but… I am also a product of this culture. So it's even hard for me to explore this because I don't know how to, but also I know people will get like upset and I won't get initial enthusiasm. I would have to do this alone, away from my field because they would get an error of, “I don't know how to deal with this.” That it's lingering in my brain, but I don't know how to push it forward because there aren't enough people who have a knowledge of programming, but also didn't have their brain destroyed by the way of thinking that  I've also been in for 20 years. So that's hard.

Kerry McInerney (18:57)

Yes, well, anyone who is listening to this podcast, if you are a programmer and if you are really, really interested in these questions, please do reach out to Felienne or reach out to us because one of the big goals with podcasts like this isn't simply to deliver information, it's to build communities. And Eleanor and I have now been running The Good Robot for a couple of years. And I think really the best thing that has come out of it is simply knowing that there are so many like-minded people who are really concerned about the exact kind of questions that you're raising, Felienne, around what does it means to try and do things like computer science. So please reach out, you can find us again through our website, through our social media channels.  But I actually now want to come back to something that you talked about a little bit earlier in this episode, which was, I guess, your first encounters with some of the limitations of this way of thinking. And for you, it was around language and translation, or specifically the kind of English-centricity of a lot of programming languages. And this aspect of your work really fascinates me in part because, in the field of AI, one of the most famous philosophical thought experiments about machine consciousness is the philosopher John Searle's Chinese Room Experiment. And the Chinese Room is still used quite widely today, along with Alan Turing's Turing test, to think about what it would mean for a machine to actually be able to think or actually be intelligent. But the central conceit of this entire experiment is the idea that Chinese characters are completely impenetrable. They're understandable. That this is a marker of extreme foreignness and untranslatability. And to the extent that John Searle, in an academic paper from the 80s, does refer to Chinese characters as sort of squiggle, squiggle, squiggle, squiggle, which you do think, you know, that hopefully would not go through peer review today. But I guess at that time we're still able to. Felienne, for those of you who are listening rather than watching, has done a kind of so-so hand movement. Unsure. Maybe that would get through peer review today.  But I wanted to ask you then about this question to do with language and translation. And so, you mentioned that you actually did manage to design a programming language that was suitable for the Arabic script. And so I want to ask you where do the challenges lie when it comes to creating a diversity of programming languages? Is it that there is, it's actually, this is easy, but there's a lack of political will and funding, or is it that there are technical limitations when it comes to design programming languages that require quite a lot of innovation to move forward? I guess I'm interested in this question: where do the barriers lie?

Felienne Hermans (21:20)

Yeah, that's a great question. So it's a bit of both of these things. There are technical challenges. What we found when we were designing this Arabic programming version of Hedy is that from your operating system, all the way through your browser, there are little things that aren't in order, which are very annoying. For example, some file systems might require documents to only have Latin letters, so only A to Z as we know them in Dutch or in English. So then, if you want to store a file, you're already in trouble. There's also rendering. So one of the small issues that I had also never thought about, but that we ran into, is that a lot of programming interfaces use a Monospace font. That means all letters have the same width. And this is really nice because then you can lay out your code very mathematically, because an L and an M will be the same width. However, that doesn't work in Arabic. Because characters,  even one character, can have different shapes. So then all the letters have different widths. So one of the systems that we were using in the editor, the part of our programming language in which you would type the characters, would have as a built-in assumption that all letters would be the same width. So then we tried to put in Arabic, and the cursor was just hopping around like it was a dance party. And then we had to switch out that entire element for another tool that actually done this. And it's not an inherent hardness, right? It is someone who built that with the assumption, and that assumption is only true for Latin languages. So there were all these little things, but sometimes I describe myself as like a recovering technologist. In the beginning, I thought this was all fixable. I can do this, right? If I just beat on this thing, it will work. And… It sort of did work. So it took us a few months, but then we got it done. And I'm not even a professional programmer, right? I'm an academic, and this is just one of my academic projects that got a little bit out of hand. So if I am an amateur programmer, if I can do this in six months, other people might also be able to do it. And some of the things are actually really easy.

Two years ago, I wrote this paper, it is called a Framework for Localization of Programming Languages, in which I describe in a lot of detail, this is something to do with numbers and word order, and grammar. If you also want to do this, here's how you do it. But then of course, this political will, exactly what you're describing, was the next issue, where it was so clear to me that if all those programming languages were managed in some large corporations or large teams of open source volunteers. If they cannot just allow people to literally add one plus one, then this is not because it's hard, even if it might be hard, a few weeks of work for a professional. That's just not something they care about or not something they know about. But then, even that says a lot about who rises to the level of being a decision maker about a programming language, as well as certainly not Arabic people, or if they do reach there, and then they aren't listened to.

Eleanor Drage (24:42)

Yeah, absolutely. You're totally right. It's the participatory element is so crucial, and that's the great contribution of feminist work in AI is also saying, who's building this and on whose behalf, so Catherine D'Ignazioa and Lauren Klein, who we had on the podcast, were pioneers of saying that to a public audience.

I just wanted to go back because I think the last question we've asked you, and I'm going to copy and paste this and put it back by the previous question. I've been doing the thing that we're all supposed to be doing in academia, but never have time to do, which is more peer reviews. And I was asked to do one on queer approaches to programming. It was a fantastic paper, and I hope that I'm not doing something bad by explaining it before it's been published. I don't even know who wrote it. But some of the examples that they gave as case studies of how ambiguity is erased from, and I think this wasn't in programming. So, for example,  they talked about the exploration of how colour is operationalised in Python and how namespaces separate concepts with potential overlaps in order to avoid ambiguities. Can you explain these things to me? 

Felienne Hermans (26:06)

Absolutely, yes, I also want to read this paper when it's done. Let's give an example of the concept of addition. So addition can mean many things. It can mean adding two numbers or, let's say, adding two colors. That's, blue and yellow make green. So that's an addition. So you can imagine that there's a function in Python called add, and you can give it two and five, but you can also give it yellow and orange, yellow and red. Now, this is not the same ad, and in some cases, Python can automatically figure out what it is, but in other cases, you need to add a namespace in front of it. So you can imagine something like color dot color color period add, and then you can give it colors, or you can say numbers or math dot add, and then you can give it two numbers. So, in case there are two different libraries, NumPy or SciPy, that people might be familiar with, that have the same functionality in them with the same name, you have to disambiguate them by saying, I want to have add from this side or from the other side. And you have to put that, that's the namespace. You have to put the namespace or the module in Python in front of it.  And I like that as an example, you can also just leave the function there, and as soon as there is a clash. I think what this ultimately leans on is the assumption that code is written once and executed without the author of the code being in the process. So the human is very much out of the loop. And you can imagine a system in which you just allow this ambiguity, and as soon as it runs, just a pop-up occurs and says, “Hey, here's an add, but I have this one or this one. Tell me which one you want that there's more in.” An iterative and more conversational interface that you use to communicate with a computer. But that's not the case. It has to run immediately without ambiguities on the first try. If I have to guess, I would have to look this up. But I would have to guess this is the history of running programs on a big mainframe in the 50s, where you would submit your program and the next morning you would get the results. So this...  Interactivity just wouldn't really be feasible. It would be technologically possible even in those days, but it wouldn't be organizationally feasible because everyone wanted to run their little scripts on the computers and they had to be scheduled in the night. So that I think this is one of the issues is that a program must be correct, and there must not be a dialogue with the user, and therefore it has to be this in a big way from the beginning.

Eleanor Drage (28:51)

That's the most amazing example. Concepts have to be separated out to avoid ambiguity.

Felienne Hermans (29:00)

Yes, because the computer otherwise doesn't know what to do. So you have to figure it out because the computer is confronted with this addition and doesn't know where to load it from, doesn't know what to do. And then here's also the focus of computer science, or computer science as a culture, on avoiding errors. Errors are bad because they blow up spaceships. This is what they teach you if you take an undergrad. There was once a spaceship, and it was blown up because of a computer mistake. Bad. So, imagine we would give the computer the power to pick one of the two. It might make the wrong decision, and then stuff could go wrong, right? The nuclear reactor might have a meltdown, and these things are bad. And it's much harder to talk about the other side of bad, right? Then, as a feminist, you have to make this argument, yes, but the lack of ambiguity is also bad. And then a computery person would say, “Yes, yes, is it bad? Is it bad like blowing up a spaceship?” No. Okay, so then it's not bad, right? It's very hard to contrast this type of error with, yeah, but then maybe it's not great if we have a whole field filled with people that don't know how to deal with ambiguity. Yeah, so what does that blow up?  You see how that's very hard to communicate.

Eleanor Drage (30:19)

Amazing. And does this relate to if this then that of workflows of flow diagrams, where things can't be both? You have to decide whether something is either one thing or another. this then that, if this then that, you go down the flow diagram.

Felienne Hermans (30:34)

Yes, in a similar way. Yes. You can imagine an if statement, we would call this a statement, where if it's not entirely sure, it would also give a pop-up. It would say, “Hey, this thing, I don't know how to deal with this. Do I do it like this, or do we do it like this?” But you also have to program that in advance. So you can always have an escape option. Like, if this doesn't know how to deal with it, but then that escape option is throwing an exception. So that’s the lingo that they use, right?

Eleanor Drage (30:40)

Right.

Felienne Hermans (31:03)

Throwing and an exception. So, it doesn't exactly fit the mold, then it's an exception. I know some of your other episodes, you also talked about this concept of a glitch, right? That's a glitch, something is broken, an exception. It must be covered up. It must be dealt with. It's not an opportunity to learn, right? It isn't like the program will stop and tell you, “Whew, whew, I got something that's very unexpected. Do you want to know what?” No, because there's this assumption that the program has to run independently of human interaction, it has to be dealt with. Then this is also sometimes in software, you get such an error message like an unexpected error has occurred. So now you will see this, now you've listened to this episode, this is very, very likely an exception where a system got input that it couldn't deal with, and this is unexpected. So an unexpected error has occurred. Bebop. I don't know what to do. The computer is stuck. You figure it out, pesky human.

Kerry McInerney (32:05)

Wow, thank you so much for this incredibly exciting and interesting, and enriching conversation that we've been able to have with you today. And I know that your work and your perspective have been really, really inspirational for people who have been trying to think about what it means to try and program differently, to have more inclusive programming languages, to approach the entire mindset of programming differently. And so yeah, I say thank you so much again for coming on the podcast. And for our listeners, where can they find you or your work if they want to dig more into what you're doing?

Felienne Hermans (32:35)

So there's www.hedy.org, where you can try my multilingual programming language. We currently support about 70 different languages, including Arabic, but many other languages as well. I have a Dutch newsletter. So, for people who read Dutch, this is felienne.nl. And I also have an English language website, but it's not as well-maintained as my Dutch one, and that's felienne.com.

Kerry McInerney (32:56)

Brilliant, well, also for our listeners, as always, we have a full transcript of every episode that goes out on our website, www.thegoodrobot.co.uk, and we'll have all these resources linked there as well, so that you can easily find them. But once again, Felienne, thank you so much.

Felienne Hermans (33:11)

Thanks for having me.

Edited by: Meibel Dabodabo