Programming Languages and Rails Girls

On refactoring the social norm.

I’d like to start with a few stories of programming languages.

As we know, Rails is built on the Ruby language. Matz created Ruby by blending his five favorite languages together: Ada, Eiffel, Lisp, Perl, and Smalltalk.

I cannot cover all of them in this 20-minute talk, so let us start with Ada.

Ada comes first in this list not only because its name starts with an “A”, but also because it was named after Ada Lovelace, the world’s first computer programmer.

In 1842, Ada wrote a program for the Analytical Engine, the first general-purpose computer ever designed but not constructed until a century later. Ada was also the first to realize that computers are not limited to work with numbers; she envisioned that people would compose music and create art on a computer.

Ada’s mother, Annabella, was gifted in mathematics. Ada’s father, the great Romantic poet Byron, nicknamed his wife the “princess of parallelograms” because of her strict morality with a mathematical rigor.

Indeed, the art of computer programming is a blend of mathematics and poetry.

Like a mathematical formula, good programs are rigorous and correct. Programmers, however, work like poets — we are creative with our languages, we convey a sense of purpose in a concise way, and we inspire each other to carry on our work.

As Professor Dijkstra put it:

Besides a mathematical inclination, an exceptionally good mastery of one’s native tongue is the most vital asset of a competent programmer.

Both mathematicians and poets require a coherent vision to guide their work. The same principle applies to professional programming: Without a coherent vision and design integrity, sloppy programs quickly become unmaintainable, such that any attempts to fix a bug will introduce more bugs.

Professional programming is not the only kind of programming, however, or even the most popular one. For nearly twenty years, the most well-known language on the web has been JavaScript, a scripting language that’s easy to start with, but that also makes it very easy to write sloppy programs with a lot of bugs.

The distinction between scripting and programming languages dates back to the 1970s, with the introduction of the C language, a portable language that runs on almost any computer. Computer scientists in Bell Labs wrote hundreds of programs in C that worked together as a complex operating system, and they called it Unix.

Users of the Unix system were not expected to program in C. Instead they wrote shell scripts that were simple to write — mostly just a list of commands — but very difficult to maintain once they got complex.

Throughout the 1980s, the worldview was that there were programs written in complex and powerful languages like Objective-C and C++; and there were scripts written in simple but limited languages like sed and AWK.

The picture here is a linear spectrum with nothing in-between. If a script became too complex to maintain, people would just re-write it in a programming language like C++.

In 1987, Larry Wall said, “We can open up this spectrum and turn it into a space with two dimensions.”

He saw C’s strength as Manipulexity — the ability to manipulate complexity.

Shell scripts excel at Whipuptitude — the ability to whip things up quickly.

Perl was hatched in this newfound space, as a language that could do a little bit of both, and one that evolves by redefining its own vocabulary.

Over time, Perl evolved to be better at Whipuptitude than any shell scripts, and as good as C++ and Java at Manipulexity for all but the most complex programs.

With Perl, one could start with a sloppy script and, through refactoring techniques, gradually make it more rigorous and correct over time, without having to switch to a different language.

In the 1990s, a new generation of Perl-influenced languages appeared, such as Python, PHP, and Ruby. Each of them improved upon Perl toward their own domains; I consider Ruby the most flexible of the three.

In 2005, the Rails project combined Ruby on the server side and JavaScript on the client side into a full-stack web framework. For many people working with C++ or Java, Rails showed them for the first time that scripting languages can build web programs that are more complex, and of larger scale, than contemporary programming languages could.

Rails succeeded in part because of its use of meta-programming, which provided way to program the Ruby language itself into domain-specific languages such as ActiveRecord.

Since that time, popular frameworks such as jQuery and AngularJS have taken the same approach to JavaScript, allowing programmers to express our vision and design integrity with a re-programmed language that’s much more rigorous and safe.

In the 2010s, Rails adopted CoffeeScript, a Ruby-like language that compiles into “the good parts” of JavaScript, to complement its use of the jQuery framework. This is an extension of the meta-programming idea — changing a language by keeping the best parts of it.

People in the Perl community took CoffeeScript to create the Coco language, and people in the Haskell community took Coco to create LiveScript.

Nowadays, most of my programming is done in LiveScript, which allows me to express the same vision in a way that looks like Ruby, or looks like Perl, or looks like Haskell, whichever way that’s most appropriate for the poem, er, program.

Those are my stories about Rails and programming languages. For the next half of my talk, I’d like to talk about the Girls part in Rails Girls.

During the first half of the 20th century, people working for women’s rights have achieved a lot of legal victories, bringing equality in rights of voting, of education, of individual economy, of marriage and divorce to many people in the world.

However, this equality in law does not readily translate to equality in practice. As Simone de Beauvoir observed in 1949, many societies make women feel inferior not by law, but through the act of Othering in languages and in actions. Men are presumed as the default subject, and women are constantly reminded that they are the collective Other by the way they are treated, as a group different from the default.

In the 1970s, social workers and thinkers applied Simone’s thoughts and observed various socially-constructed expectations known as gender roles.

For example, a particular society may confine women into one of two primary roles: either as a Girl — an adorable object of desire, harmless and of inferior status; or as a Mother — a caretaker, provider of emotional support, and a reproductive agent.

What’s missing in this picture is, of course, the various destinies that each of us wish upon ourselves. We encounter social pressure whenever we happen to contradict one of the expected roles.

We can fix this problem by adopting the vision:

Biology should not determine Destiny.

In practical terms, it is helpful to re-introduce the concepts of scripts and programs, this time from the field of social studies.

Larry Wall said this in his 2007 talk on scripting languages:

Suppose you went back to Ada Lovelace and asked her the difference between a script and a program. She’d probably look at you funny, then say something like: “Well, a script is what you give the actors, but a program is what you give the audience.” That Ada was one sharp lady…

Here we see social scripts are actions expected of people to act according to their roles. In contrast, a social program informs participants what to expect from the norm, but does not dictate people’s behaviors the way scripts do.

As a concrete example, when I began my IT career as the webmaster of a small publishing house “The Informationist” in 1994, I worked both online via a BBS and in the office. Many of our staffs were openly LGBTQ and LGBTQ-supporting; it was a safe space for me to explore my gender expressions.

The press turned into a software company in 1995, when I became its CTO, and started participating in the global Free Software community.

While Taiwan’s software sector at that time was generally gender-balanced, it shocked me to find that male-dominant scripts were prevalent in online Free Software communities.

After a while, I learned that many women on forums and chatrooms used male-sounding nicknames, not because it was their preferred gender expression, but as a protection against harassment. This was obviously a problem.

In 1998, the Open Source movement started and I helped run a few startups in the Silicon Valley, China, and Taiwan. As I started attending conferences and giving talks, I couldn’t help but notice the lack of variety in gender expressions and in ethnic distribution.

For example, I heard the question “are you here with your boyfriend?” asked many times in these conferences, but not once “are you here with your girlfriend?” or “are you here with your partner?”— it was clearly a social script to make the recipient feel identified as an other — an outsider instead of a participant in the space.

After I returned to Taiwan to work on local open culture communities, I started consciously using the feminine pronoun in all my Chinese online writings, in an attempt to turn around the language’s othering aspect.

When we started organizing our own conferences in 2003, I also took efforts to invite only the most socially compassionate speakers from abroad, who helped establish a more relaxed atmosphere where people can enjoy a safe space.

However, as Open Source gained commercial popularity, sexualized practices of IT industries’ trade shows started to affect our conferences as well. One of these practices is promotional models, hired to drive interests to a vendor’s booth; another is offensive imagery in conference contents, including from prominent speakers in both Free Software and Open Source communities.

In 2009, Skud, a long-time fellow hacker in the Perl community, started to speak widely at conferences on this subject. She created Geek Feminism, a wiki-and-blog platform to list the issues and work together to improve them.

After a year’s work, participants in the wiki created a Code of Conduct template, a social program that sets the expected norms. Valerie Aurora and Mary Gardiner, two Geek Feminism contributors from the Linux community, formed the Ada Initiative in 2011 to support women in open technology and culture.

Between 2011 and 2015, with help from many contributors, the Ada Initiative worked with over 100 conference organizers to adopt the code of conduct program. I’m very glad to see the upcoming Rails Girls Summer of Code event among the list of adopters.

There are three main elements of such a program:

  1. Specific descriptions of common but unacceptable behavior
  2. Reporting instructions with contact information
  3. Information about how such policies are enforced

Together, they ensure a space where people can be aware of their own social scripts and their effects on each other — and refactor them into a more sustainable community with openness and variety as a coherent vision.

To me, the most enlightening bit is perhaps not in the code itself, but in its programming — the fine-tuning of a conduct that fits best with the local culture.

When we create a safe space for a community’s participants, to observe and decide our own social scripts, we can collectively program a social norm that is both rigorous and creative — just like the best formulas, poems, and programs.

In conclusion, I’d like to share two poetic fragments of mine with you:

I would like to know you
 not by your types,
 classes or roles — 
 — but by your values.


Saying “Life is what we make it to be”,
 is like saying “Language is what we make it to be” — 
 True, but not at once;
 — just one bit at a time.

Thank you.

(Source: CC0