A web page with a left, a right, and several footers. The left shows a text editor with colorful computer code, a yellow highlight, and a magenta highlight on top of it, indicating a selection of a “translate” statement that converts a list of symbols into a list of Phrases for display. The right shows a 5 by 5 grid of symbols, one of them fading in to the grid. The footers show a timeline, several file names, and navigation links and settings.
A Wordplay project. On the left, a program that makes a random list of letters that changes by one random symbol each second, and renders it as a grid. On the right, the rendered grid of symbols, mid-animation, and a timeline for time travel debugging.

Wordplay: an accessible, language-inclusive programming language for all

Amy J. Ko
Bits and Behavior
Published in
12 min readOct 31, 2023

--

TLDR: I’m proud to announce public beta of Wordplay, a new educational programming language for making plaful interactive typography (and many other things!) with code and data. We made it for the world, but particularly for adolescents, especially those who like emojis, words, and fonts, and want to bring them to life — and particularly for adolescents with disabilities and those who are not English fluent, who have so often been left behind in learning about computing. If you’d rather skip the background narrative below, just go to wordplay.dev and play! Or if you’re a computer scientist, and want to read the language specification, have fun! Tell us what you think and help if you can, because it’s only a fraction of the bigger vision described below, and we’re just getting started.

I’ve always had trouble claiming the identity “computer scientist”. There are of course the linguistic issues with the phrase; most computer scientists don’t really do science, they do engineering. And most of them aren’t really concerned with computers in the material sense, but the abstract sense. The German computer science “informatik” is also kind of strange, because most computer scientists don’t really care that much about information itself, but rather, processing it with algorithms, and storing it with data structures.

And yet, most of what has captivated me since I was an adolescent was the same stuff most computer scientists are captivated by. I have always been fascinated by the ability to give a machine instructions, and then have it do them, reliably, quickly, and sometimes, magically. I know the feeling of finally getting a program right, and in particular, knowing why it’s right, especially after hours, days, weeks, or months of struggle. If a computer scientist is a person that chases that particular kind of logical triumph, than I am a computer scientist.

But not all of that struggle is necessary, or good. And that’s generally where I part with the culture of computer science. So much of computer science as a discipline and a community glamorizes extraneous complexity — the “power” of having to spend hundreds of hours troubleshooting a Linux kernel to check your email reliably, the “hardcore” of memorizing hundreds of vi or emacs commands for that extra bit of editing speed, that “unifying” abstraction that explains everything, while also making everything unexplainable. The joys that some find in the “wizardry” of CS I generally find tedious. I’m here for what we make and what it means, not how we make it.

That simplicity aesthetic is was what drove me to human-computer interaction research, and what led to much of my work over the past 25 years to try to strip away all of the inessential work in programming. With many students and collaborators, I’ve invented a debugger that can be asked why questions, editors that were more than text, compilers that are nice to you, programming tutors that slowed down to explain things, curricula that slowed down to teach reading, ways of writing problem solving plans. Each of these ideas was fundamentally about taking the parts of programming languages, tools, and skills, and reducing them down to their core difficulties, and then building them back up with better scaffolding.

While I gave my attention to tools and thought, however, I blithely ignored some of the most significant parts of human experience: culture and bodies.

In culture, I overlooked language, meaning, and purpose. My English-speaking, western-minded, capitalist upbringing hid the world’s diversity from me. I learned what is obvious to the non-U.S. world: that 85% of the world does read English, that this dominant group speaks thousands of different languages, and have countless reasons for trying to learn to code, or for never having heard of it. It took me traveling the world as a researcher for two decades for me to realize the obviously rich cultural tapestry on our planet, and how much it is ignored and erased in the design of programming languages, tools, documentation, and communities.

In bodies, I overlooked ability, disability, perception, movement, and how our relationship to the world through our bodies can shape our experiences and interests, with code and everything else. Over the past two decades, I learned ~15% of the world is disabled in some way, and that I will likely be disabled some day (and very much am when I take my extreme prescription glasses off). And I learned that this diversity in our abilities are also ignored and erased in programming languages, tools, documentation, and communities, creating a world of computing that is often nearly or completely inaccessible.

In hindsight, I wondered how such a small, privileged group of Western, mostly white people managed to shape so much of computing, and through computing, so much of our modern world. And then I realized, thanks to the wonderfully rich community of social scientists in my Information School, that this was no accident. These are the intents of settler colonialism: power, domination, replacement. The white, Western, non-disabled world saw how computing might be a tool for capture, and built it up in its image, erecting walls that most could not climb. And they were rewarded immensely for doing so, at the expense of non-English speakers, people with disabilities, and their many intersections.

As I approached my 2022–23 sabbatical, I did not want to be part of this project any longer. But I struggled with what to do, if not colonize. I am not a white, straight, cis, Western man; but I do hold privilege, as a sometimes white-passing Western woman. I am not a capitalist; but I am a powerful tenured professor at one of the world’s great universities, with knowledge and opportunity. I am not disabled, nor an English learner; but as a trans and mixed race person whose childhood and ethnicities were victims of colonialism. And so while I did not come to these culture and ability gaps in programming as a savior, I did come as someone trying to imagine a different world, one in which all of our differences might be supported, celebrated, and empowered in computing. I wanted to know what that world might look like, and decided to spend my sabbatical making one version of it.

Of course, many have been engaged in this work already. My wonderful colleague Andy Stefik (UNLV), for example, has been exploring accessible programming language design with Quorum, understanding what makes code and tools more or less screen readable. The excellent Felienne Hermans (Vrije Universiteit Amsterdam) has been exploring multilingual programming language design with Hedy, understanding the entangled relationship between programming language and natural language syntax. And many before them, in and out of academic research, have explored more accessible editors, more lucid debuggers, more localized teaching. I am late to this party.

But I wanted to help, particularly at the intersection of language and ability, where most have not tread. And with my training in human-computer interaction and experience in education research, I knew that the right way to help would be to engage with people who live the intersection of language and ability exclusion every day, and co-design something with them. I pondered how to start, and a phrase kept ringing in my mind, “nothing about us without us”, with its origins in early democracy in Poland, and then disability activism in South Africa, and then the disability rights movement in the United States.

But I was not in a good place emotionally to do community work last year. I had just spent a grueling 6 years of tenure-track life doing administrative work and education reform advocacy, much of it during the heights of the global pandemic. I had just taken a much needed break from social media. And with a sabbatical starting, I examined what I needed most, and I knew in my heart that it was art, and not people. I needed time and space to rekindle my creative spirit, to make, and to do so freely, to follow my aesthetic and my values. And I knew that after doing that, I would revert back from artist to activist, grow a community of people who live at the intersection of language and ability exclusion, and collaborate with them to reinvision everything I got wrong.

And so Wordplay was born as art. I wanted it to be an expression of my love of words, of puns, of programming, and irreverence. I wanted to work within the creative constraints of mundane standards like WCAG 2.1 accessibility standards, Unicode, and the new Noto font, to see what kind of beauty might be wrought out of them and their global, universal values. And I wanted it to be an opportunity to work through all of the ideas about programming that I had bouncing around in my head since the early 2000’s, but never really got to play with, distracted by publishing, PhDs, and promotions.

And so I envisioned Wordplay not as something inherently new, but rather a pastiche of my aesthetics and others’. I wanted to synthesize many of the things that I’ve seen and learned over the past 25 years of scholarship about programming, accessibility, and natural language into something that was real and usable, but also embody some of the best ideas of decolonial visions of programming, but also some of the best ideas of programming language research as well. Here are some of the ideas on my palette:

  • Symbols have the meanings we give them, but also the meaning we carry with us, and this is the seed of ambiguity
  • Accessible editors require many modalities, and giving primacy to one always has inequitable consequences
  • Understanding code ultimately requires manipulating time, but we usually forgo that in service of the Holy Scripture of Speed
  • Learning is easier when feedback is immediate and teachers are encouraging, which is why conventional programming languages are so hard to learn
  • As useful as it is, mutable state is source of most debugging difficulties; if only there were a way to make immutability easy
  • Input over time is what makes programs interesting, but we rarely get to reason about either directly

The question was how to weave those ideas together into a coherent whole, and do so in a way that was global and accessible.

Here’s what I ended up with:

  • A strongly typed pure functional programming language with type inference and two types of values: immutable ones and those that are reactive, representing streams of external inputs such as time, frequencies, amplitudes, gravity, mouse clicks, keyboard presses, pointer movements, text/speech input, and more. When reactive values change, programs change, and voila, interactivity.
  • A syntax that is natural language free and global, with support for the world’s numerals, text delimiters, and every glyph in Unicode, including composite emojis, all correctly screen read in our editor (yet alas, not localized, because Unicode’s glyph descriptions are English only).
  • Immutable data types such as Booleans, text, numbers, lists, sets, and maps, but also tables to support learning about tables and queries. And spins on primitives, such as 1) text that allow them to have multiple language tagged translations for selection at runtime, 2) rich text to support markup in comments but also rich text output, 3) and unit semantics on numbers, to allow for more precise type checking and integrations with the sciences.
  • An hybrid code editor that can be used as blocks or text simultaneously, edited with a keyboard, a menu, drag and drop, and eventually speech and other inputs.
  • Instantaneous time travel debugging to any pointing a program’s past or future evaluations, enabled by immutability and reactive values, which capture all of the inputs necessary for low-overhead replay.
  • Bidirectional editing through a palette metaphor that allows for static manipulation of dynamic output, enabled by the replay afforded by time travel.
  • An eclectic cast of characters, each a reserved symbol in the programming language with its own personality that conveys its semantics.
  • A 20,000 word play about the co-dependent relationship between function ƒ, function evaluation (), and humanity, which teaches the core language concepts dramatically, with a healthy does of puns. This and the documentation constitute a kind of lore about the typographic characters in the world, their diverse personalities, and the language semantics associated with those personalities.
  • Infrastructure for localizing the entire IDE, all the APIs, and all of its documentation, and programs written in the language into arbitrary languages, locales, and scripts.
  • A new interactive typographic output paradigm consisting of a stage, groups, and phrases, supporting single styled poses, and sequences of styled poses, enabling animations and transitions.
  • Everything above aims to be WCAG 2.1 compliant, enabling all functionality to be accessed via modern screen readers.
  • Everything in a tidy zero-install web application package that works on screens big and small.

All of this sounds as if it might be a big mess of ideas. And so I approached it with a particular context in mind, to keep me focused: the classrooms of culture and ability diverse young adolescents that I have often taught in summers as part of Upward Bound. I wanted to make something that these wonderful 13-15 year olds — who come from all over the world as immigrants, refugees, or gentrification outcasts, speak all kinds of languages, have all kinds of ability and neurodiversity, and have all kinds of interests — that they would make fun of and fun with. Dancing poop emojis, uncivil interactive poetry, silly mashups of lyrics and inside jokes, unwinnable games. I want the computing in Wordplay to be so visible, but also so lucid, that youth could begin to see computation not as something to fear, but as a magic dust sprinkled atop their expressions to bring it life.

But I also made Wordplay for these students’ teachers: the secondary/middle learning facilitators who see computing like writing, a medium in which to learn and explore other ideas, in language arts, social studies, and perhaps science and mathematics. And computer science, if such classrooms can ever escape from their capitalist treadmill rhetoric. I want it to eventually be a platform in which teachers can orchestrate culturally responsive learning through language and expression. And I’m excited about collaborating with teachers to build it out to meet their orchestration needs.

Because neither of those groups are likely to be my core readers of this blog, here’s a bit of why you might want to check Wordplay out anyway. If you’re a programming language researcher, see it as an exercise in functional reactive programming language and tool design (what would make OCaml this kind of fun?) If you’re an human-computer interaction researcher, see it as an exercise in interactive anthropomorphized medium for typographic expression (what can be said that couldn’t be said before?). If you’re a computing education researcher, see it as platform that strips away all of the extraneous cognitive load of the popular languages we reluctantly teach (what parts of programming are left that are intrinsically hard?). And if you’re a multilingual and/or disabled programmer, see it as a glimpse of what other more mainstream programming languages could be someday. (And share what’s still broken, and maybe help us localize in your language, if you are able).

If you are a learner or teacher, there are many places you can start. The tutorial is a playful community allegory about a codependent relationship between functions and evaluations. You can look at our growing collection of examples in our galleries, which contain many examples curated by my growing local open source community, Wordplaypen. Or you could just go make a project and learn by doing with the integrated documentation. At some point, all three will probably be helpful. We have a Discord where you can post questions, offer feedback, and share your creations. You can find me there with my undergraduates answering questions.

Finally, this is a beta. Did I mention that this is a beta? Because it’s a beta. That means that it definitely has bugs, localizations aren’t complete, and the design of the programming language and platform is not necessarily final. We might lose your data, and the language might change, breaking your projects. I’ve spent the past month growing a community of more than 60 undergraduate open source contributors who are helping design, build, verify, curate, localize, manage, and more, and so we’re eager to hear and work on your feedback, and work towards a stable 1.0. And if you have any of these skills, join us a contributor. And if you don’t, but believe in our mission, consider donating. We’ll use the money you give to compensate all of the undergraduates currently contributing their volunteer labor for course credit, particularly those with disabilities, who are so often excluded in computing.

And what comes next? Community. It’s time to return to the commit I made before, and shift this from a personal art project to something not only informed by multilingual learners with disabilities, but led by them. I’m actively fundraising to support this work, and hope to explore all kinds of new power structures that place multimarginalized learners at the center of the project’s strategic plans and design goals. It’s time we figured out how to decolonize not only programming languages themselves, but how we manage their design and evolution over time.

On the other end of this 16 month art project, I’ve been pondering whether what this project means. I know what it means to me: it’s been cathartic to make something primarily as art, and as an expression of what computer science means to me. But now, as I give this art to the world as a starting point for greater things, I want to know what it means to others, and help it grow into something that is theirs. I hope you’ll join us in growing a platform that makes space in computing for everyone!

--

--

Amy J. Ko
Bits and Behavior

Professor, University of Washington iSchool (she/her). Code, learning, design, justice. Trans, queer, parent, and lover of learning.