How Feminist Programming Has Already Happened

Exploring how feminist ideals are represented in existing languages

I’d like to start with a confession. I’m a white male software engineer who has had what many would call a privileged upbringing. This is also the first time I’ve attempted to explore an emotionally sensitive subject in public, so please try to accept any specific words or phrases that offend you to be accidental, rather than an attack, the overall message is important here. Comments are welcome, abuse is not.

Recently, a blog on the HASTAC site by Arielle Schlesinger became quite well publicised in social media. I originally dismissed it, because of the academic-ese register of the post, I’m horribly prejudiced against articles that are written in this form. The basic proposal seemed to be around trying to find ways to develop a new programming language that’s more in tune with various feminist ideals.

A few days passed, then some people posted what I’m going to call a poorly-judged adolescent joke about the topic, in the form of a C library to introduce various fallaciously feminist terms into a program. This got me thinking about the original proposal again in more depth, and I started to wonder if some of these ideals are already creeping into programming languages, and where these developments could be taken further.

Unfortunately, the examples I could come up with are few, but their impact on programming and the way people think about concepts has been huge.

Ducks

Arielle proposes:

“a feminist programming language […] built around a non-normative paradigm that represents alternative ways of abstracting”

In the feminist language I’ve been exposed to, normative is used to talk about prejudicing. ‘Boys like action toys while girls like dolls’ would be a (crude example of a) normative concept in modern society.

Traditional programming languages, in my opinion, lead the developer to think in terms of normative statements. In fact, this sort of thinking fundamentally underpins traditional object-oriented design. Here’s an example (in Java):

import toys;
class Person {}
class Boy
{
 Toy buyToy() {
  return new ActionFigure();
 }
}
class Girl
{
 Toy buyToy(){
  return new PinkDoll();
 }
}

The traditional engineer’s mentality loves this, there’s no room for doubt, you can statically analyse the code and understand exactly what’s going on simply, and there’s no room for error. Boy > Action Figure, Girl > Pink Doll

Unfortunately this way of thinking is flawed, because inevitably a situation will occur where these rigid rules don’t apply, and suddenly all sorts of hacks have to be added to handle all those annoying pesky non-normative requirements that people have.

More modern languages, especially Python, promote duck typing rather than type checking for this sort of thing. Duck typing is explained by the simple phrase:

If it walks like a duck, and quacks like a duck, then it is a duck.

Immediately feminist should see some parallels here, duck typing is all about defining things by their behaviours and self-ideals rather than abstract categories and rules.

The above code example written with duck-typing:

class Person(object):
  def buyToy(self):
    if self.likes_dolls:
      return Doll()
    else:
      return ActionFigure()
class Boy(object):
  likes_dolls = False
class Girl(object):
  likes_dolls = True

Nothing’s changed here, we’re still, from our position of privilege and dominance, claiming that all girls like dolls, but the code itself is indicating to a programmer that the underlying choice is more complex than just a gender one, and with Python being so dynamic, this can easily be changed on a per-instance basis:

jo = Girl()
jo.likes_dolls = False
print jo.buyToy()
>>  <ActionFigure 0xfeed00>

This has a strong, real-world impact on code quality, and drives the programmer to not be focussed on strong pre-defined categorical prejudices.

A lot of programmers, used to traditional inheritance, coming to Python for the first time hate this loss of control, they are used to explicitly controlling how things behave and interact, and learning to have a looser-grip on your logic leads to much more beautiful code, something that matches the feminist desire for breaking down normative thinking.

Mixins

Interestingly, to talk about mixins, you have to talk about classical inheritance, and object-oriented principals.

In my mind, the term classical inheritance makes me think of upper-class privilege, and hereditary peers, while object-oritented is not too dissimilar from objectivism. And while it’s quite cheap to draw these language-based similarities, it’s interesting that very similar arguments can apply both to the software and social versions of the words.

In the classical inheritance model, objects are defined in a (general) parent-child relationship. The rule is that if you inherit from something, then there must be an ‘is-a’ relationship. For example: A square is a shape, so the square class could inherit from the shape class.

If inheritance is your primary way of expressing abstractions, then this leads to horribly arbitrary categorisation. If you were to model people using this technique you might end up with something like this:

Imagine you’re writing a computer game, and you want a character that is a Fairy Princess, it would be entirely logical (in this model) to add that in like so:

Immediately it’s clear that this way of defining classes can be problematic. This has now forced all fairy princesses to be girls. Furthermore, all the code will be written expecting this relationship, so this normative statement becomes embedded in the soul of your game, and is later impossible to unpick properly. If at a later date, someone asks for a monster-fighting girl-elf who casts spells, adding that in is going to be hard.

Instead of forcing developers to define everything by what it is, newer language communities: Python, Ruby, (even Javascript?) often talk about mixins. This is, if you like, an extension to inheritance, whereby you define an object by the behaviours it implements, rather than a strict is-a constraint. Functionality is mixed-in to an object without placing other restrictions on it.

The above model might be implemented like so:

Here the model is much more complex, but the is also more accurate, and doesn’t impose (too many) arbitrary judgements about what is-a really means. Subsequently adding in a girl elf hunter is easy, because attributes can be selected in to a new class very simply:

This diagram is getting quite complex, but the fact that this sort of thing is even possible using mixins is critical here. I’ve left in the skip() method on Girls to show that even ‘aware’ developers can make assumptions and mistakes easily.

Dynamic Inheritance

Dynamic inheritance is still something of a black-art in most programming languages, and represents the front-edge of what I’m classing as the ‘feminist programming’ frontier.

Python is the only language I know with language-level support for this. Ruby allows for dynamic class generation, and Java has some inspection methods that allow for doing this, but Python really has the nicest interface here.

The basic problem is that class relationships are traditionally static. The developer defines what behaviours and attributes each type of thing should inherit. This is arbitrary and normative. Even using mixins requires a set of relationships to be hard-coded into the software.

In the game above, to allow people to chose whether their fairy was Female or Male based on preference, you’d have to remove the Genders from the inheritance/mixins and probably end up with lots of if/else statements or switches in the code.

With the __new__ method in Python, inheritance and mixins can be selected dynamically at creation time. This allows for the Fairy to be created with the user-selected behaviours and actions dynamically at run-time, and removes the need for a programmer to have to select such things based on arbitrary decisions:

This segues nicely into the last topic I want to cover: Logic. If you’ve got a function that is deciding if the character should be a Boy or a Girl, what happens if there is no correct answer? What happens if the __new__ method only identified the character as Human, rather than defining it as a Boy or Girl? This is also possible in the model above, it requires some careful programming to support, but we’ve reached a situation where the language allows us to define objects in terms of predefined categories, or choose not to adhere to these limited concepts.

Feminist Logic

From the original article:

the following are the four main groups a programming language can fall into: imperative, functional, object-oriented, and logic.

Apart from imposing arbitrary categories on languages, this statement intrigued me. How could logic be made more feminist? There may be scope for some work here, but my gut feeling is that there isn’t much.

I’m going to take logic here as meaning boolean operations. All current languages (that I know of) resolve most logic statements to boolean operations.

In C, if you have a boolean operation on two values (let’s ignore pointers here), then the inputs and possible results are very simple, 1 or 0

In dynamic languages, however, things get more interesting. Typically a variable is a reference to a dynamically generated value. This allows for the possibility for a boolean variable to be true, false, or not a valid reference. These three states have some interesting implications.

The javascript terminology is probably best here, it’s untyped, so this argument is a bit nebulous, but there are actually four probable options for a Boolean type: true, false, null, and undefined. These different values are used in contexts, and can be good for adding nuance, and subtlety to otherwise black-and-white situations.

Let’s look at the implications of this with an example:

function query_gender(person) {
 if (person.gender == "male"){...} // Person identifies as male
 if (person.gender == "female")... // identifies as female
 if (person.gender === null).. // gender explicitly not defined
 if (person.gender === undefined)// concept doesn't apply here
}

This might be slightly tenuous, but I think this added complexity in javascript is pretty closely aligned with some of the feminist thinking around. Having an explicit True/False is quite often just a bit too simplistic to allow for usefully handling all situations.

Socially, True and False are opinionated words. There are all sorts of normative assumptions tied to them, and their use can arguably be opressive.

Python provides the standard defaults to you, but doesn’t presume to enforce what True actually means. So you could quite easily define a function:

def never_fail():
  False = True

Then any future references to False will return something that equates to True. This approach is filled with flaws and caveats (early-binding etc) but the fact that Python is so unopinionated as to allow you to do this is great. A complely facaecious example might be:

class Person():
  def promote(self):
    if self.is_male is False:
      self.salary *= 1.1
    else:
      self.salary *= 2

This code might be part of a performance-management system where promotions for male staff equate to a doubling of salary, whereas female staff get a much smaller increase.

You could call code this with True and False redefined to rectify such an imbalance:

try:
  temp = False
  False = True
  Jane.promote()
finally:
  False = temp

Joking aside (I wouldn’t recommend anyone redefining True and False in a language, doing so is likely to cause chaos!), this ability shows the fact that the normal values and implications of the terms True and False may have different values in different contexts and circumstances, and Python doesn’t stand in the way of you expressing that.

Summary

I really feel that Python is a great case-study for how feminist concepts could be applied in software development. It does a great job of allowing non-opinionated code, which aligns it nicely with challenging normative strictures.

There are ways that this could be taken further, for example, changing an instances base class dynamically at runtime is one area where work could be done to encourage new ways of thinking about problems.

The concepts explained here may not be as radical as some people might hope, but looking at the places where Python differs from other languages should help to kick-start the debate nicely.

If you enjoyed reading this, please recommend it, so others can enjoy it too.

Thanks