The Life Cycle of Programming Languages

A few weeks ago, Twitter discovered the unbearable whiteness of the Rust team.

Photo after photo on the team page displayed grinning white cis dude after grinning white cis dude. Along with everyone else, I noticed its homogeneity; but I also noticed how many names were familiar — from other, older FLOSS languages and frameworks.

Structurally, Rust and Ruby aren’t that much alike. So why were so many old-guard Rails people on that team page?

A Brief History of Rails

Photo CC-BY jnyemb, filtered.

Rails, a popular Ruby-based web framework, was born in 2005. It billed itself as an “opinionated” framework; creator David Heinemeier Hansson likes to characterize Rails as “omakase,” his culturally appropriative way of saying his technical decisions are better than anyone else’s.

Rails got its foothold by being the little outsider that stood against enterprise Java’s vast monoliths and excesses: programming excesses, workflow excesses, and certainly its excesses of corporate politesse. In two representative 2009 pieces, DHH described himself as a “R-Rated Individual,” who believed innovation required “a few steps over [the line].” The line, in this case, was softcore pornography presented in a talk of Matt Aimonetti’s; Aimonetti did not adequately warn for sexual content, and was largely supported in his mistakes by the broader community. Many women in Ruby continue to view the talk’s fallout as a jarring, symbolic wound.

At that point, estimates put the number of women in the Rails community at at most 3%. Nowadays, that number has doubled to 6% — still pathetic, but reflective of more dialogue around inclusion in programming. Over my years in the community, I’ve gone from being the only woman at DC’s Ruby meetup to one of a few, and Ruby has gone from being the new rare shiny to being a solid, mature language that enterprise apps can be written in. Even the government uses it.

Now in Rails-land we talk about diversity and dependency injection, just like Java was doing around the time we formed.

The Life-Cycle of Software Objects

Photo CC-BY Julia Folsom, filtered.

Stage 1 – TOO SMALL TO SUCK

Each new programming language is a little rebellion. Any new language or framework must differentiate itself from existing projects — if I already know Backbone, Ember’s gotta sell me on why it’s better enough to justify the learning curve. Even when new technologies’ marketing isn’t as overtly oppositional as Rails’ was, they call by their very nature: come over here, where the grass is greener. All software is broken, and most working engineers spend their days running up against their frameworks’ failures; young open source projects promise to fix these failures by implementing radically different paradigms.

Technical affiliations, as Yang and Rabkin point out, are often determined by cultural signaling as much or more than technical evaluation. When Rails programmers fled enterprise Java, they weren’t only fleeing AbstractBeanFactoryCommandGenerators, the Kingdom of Nouns. They were also fleeing HR departments, “political correctness,” structure, process, heterogeneity. The growing veneer of uncool. Certainly Rails’ early marketing was more anti-enterprise, and against how Java was often used, than it was anti-Java — while Java is more verbose, the two languages are simply not that different. Rails couldn’t sell itself as not object-oriented; it was written in an OO language. Instead, it sold itself as better able to leverage OO. While that achievement sounds technical on the surface, Rails’ focus on development speed and its attacks on enterprise architects’ toys were fundamentally attacks on the social structures of enterprise software development. It was selling an escape from an undesirable culture; its technical advantages existed to enable that escape.

Stage 2 – THAT NEW FRAMEWORK SMELL

After the maintainers of a new project have convinced enough people to throw in with their wild little plan, it starts to pass through its alpha and beta stages; it starts to accrete edge-cases, as people use it for more real-world projects and rough up its initial theoretical purity. Throw in a good Series A or three, and all of a sudden it’s a real project, suitable for attracting money. Adoption accelerates — the project now sits in the sweet spot of “young enough to be cool” and “mature enough that I can kindof justify it to my boss.”

It develops a community of users, as opposed to a community made solely of founding developers. Unless the maintainers try real hard this community will be made up of cis, straight men, usually white. (As Ruby’s creator is a Japanese man, Ruby is notable in that its early core was composed primarily of cis, straight men from two racial groups.) People from privileged backgrounds are disproportionately represented in open source, for many reasons – privileged people are more likely to have free time to do OSS work in; open-source communities are often hostile to marginalized people; the list goes on. These early adopters set the tone for a community in ways that are often difficult to later change – the friendships and shared assumptions and war stories that make up the social fabric of software development are powerful.

Stage 3 – AWKWARD TEEN YEARS

Next the project will reach its adolescence, which is when it starts to matter. Enough real-world products will make use of it that learning the technology becomes less optional: people learn it for their jobs, or for the jobs they want to have. Since the community of people employed as programmers is more diverse than the community of hobbyist open-source hackers, the community’s diversity will improve on a percentage basis. The increased number of people in the community also means that the absolute number of people from non-dominant groups will increase: 6% of 100 is 6, but 6% of 1000 is 60. These two factors, combined, set up an environment with enough heterogeneity that it’s possible for marginalized people in that community to talk to other marginalized people in that community — and frequently, they’ll compare notes on the challenges of being in the minority. These quiet, solidarity-building discussions are an essential precursor to the more active work that’s typically needed to achieve a truly diverse community. Without solidarity, and consciousness-raising, marginalized people can barely have — let alone win — the difficult fights about codes of conduct, and intra-community abuse, and straight-up discriminatory behavior that are a sadly essential part of diversity-in-tech work.

In recent years, the Rails community has been going through this stage.

Stage 4 – LUMBERING DINOSAURS

Unfortunately, the world of software engineering moves fast enough that we have few models for true language or community maturity — by the time something’s moved past its adolescence, another, newer project can credibly accuse it of senescence. Java and PHP arguably sit in the “mature” category now, and their communities are certainly more diverse than Ruby’s, but I know very little about their communities — because in some corners of the Ruby community, even admitting that you know PHP risks ostracization. PHP is that thing that WordPress theme developers use, after all. The only way to get less cool would be to use Microsoft.

The rockstars move on. Once you’ve made your name on one project, you’re trusted on others; the same names and faces begin to reappear on the team pages of new, nascent languages, and the life cycle begins again.

Starting All Wrong

Photo CC-BY Han Cheng Yeh, filtered.

When frameworks are small, and you can move fast, it’s nice: you get to feel like a revolutionary. You get to feel a brand-new team coalesce around you, a team whose culture easily fits yours. You aren’t beholden to, and responsible for, the community members who are as yet a twinkle in your eye. The reality of maintainership on a mature framework is equal parts tedious drudgery and soothing panicked strangers. In early frameworks, you still get to write code. You can focus on the theoretical purity you don’t have time to achieve in industry code. You talk to friends new and old, just like you, about immutability, or union types, or whatever the theoretical foundation of your framework is. You don’t need to talk about diversity. There aren’t any women yet to get irritated at you for avoiding the subject.

Serial “early adopters” mythologize the early days of languages. New programming language communities are “graded” in the public eye based on how cutting-edge they are: our pattern-matching capabilities associate white men with the cutting edge, especially if they’re talking about monads. In “Country Clubs on the Web,” nina de jesus points out the tech press’s willful refusal to recognize the size of Pinterest’s and Tumblr’s userbase and mindshare, asking whether the cachet of platforms like Medium and Svtble is truly due to superior content and curation, or whether it’s instead due to the whiff of exclusivity that comes from erasing women, PoC, and queers. “Early adopters” seem to count more if they fit our stereotypes of “early adopters” — in other words, if they’re white men.

A little while ago I was investigating the Haskell-based web language Elm. Elm’s a cute little language; when it grows up, it wants to be a single-language FRP solution for highly-interactive web applications. It has neat ideas, and I want to be able to throw myself behind it… but. In its purest form, Elm reimagines web programming as something graphical, and abandons the underlying textual structure of the web. In doing so it forgets one of the most important things the web’s textual semantics give us: easy screenreader accessibility. I imagine that I could probably backdoor accessibility into Elm apps, but not only does the Elm documentation fail to stress the need, it fails to even mention the possibility. All Googling “elm language accessibility” gets you a is a high-minded vision statement about making web programming more accessible to beginners.

In this context, it’s obvious that Elm’s apparent failure to a11y stems from its creators’ lack of exposure to people who need assistive technology. They’re solving the problems they know about, and have to think about on a regular basis. The problems they don’t know about get pushed aside. Elm’s accidental contempt for coders and users with disabilities is reflective of “early adopter” communities’ accidental contempt for everyone who does not fit “early adopter” demographics. Each new project that thinks of diversity and inclusion and anti-harassment policies as questions for later — you know, after the ladies and the queers show up and start demanding them — dooms itself to making similarly fundamental, direction-setting mistakes in both the shape of its community and in the shape of the code itself.

in the middle of a discussion abt algorithmic bias, dude perhaps accidentally makes implicit point abt tech industry https://t.co/EhLqcajZXA

— [ kinda hi8us ] (@thricedotted) June 15, 2015

The Privilege to Chase the Shiny

I get it. I get it. If you’ve been doing Ruby for what feels like too long, and you’ve burned the hell out on what someone else’s bad monkeypatch can do to your day, I get fleeing to something newer and shinier, something where you don’t know what the flaws are yet and so can pretend they don’t exist.

I get wanting to fix these mistakes. I get wanting to fix them and thinking they are bred so structurally deep that the only way to fix them is to burn the whole language down and start over. The thing is — I’m a queer woman. I don’t get to only think that about the technology.

People grow, and I hope DHH has outgrown his history of punching down. But Rails culture is still broken around beer and bros and abrasiveness in ways that we are only just starting to fix. It is burned into Rails as deeply as the horrible impossible-to-cleanly-extend stringly-typed over-metaprogrammed legacy bullshit of 2004’s codebase.

It takes a whole lot of privilege to think of the latter as the worse mistake.

Fourteen years ago the authors of the Agile Manifesto said unto us: all technical problems are people problems that manifest technically. In doing so they repeated what Peopleware’s DeMarco and Lister had said fourteen years before that. We cannot break the endless cycle of broken frameworks and buggy software by pretending that broken, homogenous communities can produce frameworks that meet the varied needs of a broad developer base. We have known this for three decades.

But hey, Elm’s debugger time travels. That plays great on Hacker News.