Tim's journal

Paul Hudak died of leukemia yesterday. Paul was a founding member of the Haskell Committee, and as such, instrumental in creating the programming language that shaped the course of my professional life for 15 years. He was the primary author of the "History of Haskell" paper (PDF), which is a beautiful look at the history of both a set of ideas and the set of people who nurtured and developed those ideas.

I didn't know Paul well, but of course, I took it for granted that he would be one of those people I would keep running into if I kept going to programming languages conferences. When you go to the same academic conference almost every year, you start thinking of the group of people you see there as a family of sorts... with, of course, closer relatives, more distant ones, and the few you awkwardly tiptoe around. In professional communities, as in families, you lose people, but it's never expected -- especially not when somebody is only 62. Especially not, in my case, when it's a person who I was riding a Ferris wheel in Sweden with seven months ago. I knew he had been seriously ill, but at the time I thought he seemed to be recovering. He was, as I recall, quiet, but over dinner, listened to my story of how I left academia without passing judgment on it or me.

I won't implore you all to thank people whose work has meant something to you for it while they're still alive, because after all, we all know why we don't usually do that. It's awkward. Instead I'll just quote from Paul's book The Haskell School of Expression (an intro to programming in Haskell through computer art and music):

Programming, in its broadest sense, is problem solving. It begins when we look out into the world and see problems we want to solve, problems that we think can and should be solved using a digital computer. Understanding the problem well is the first--and probably the most important--step in programming, because without that understanding we may find ourselves wandering aimlessly down a dead-end alley, or worse, down a fruitless alley with no end. "Solving the wrong problem" is a phrase often heard in many contexts, and we certainly don't want to be victims of that crime. So the first step in programming is answering the question, "What problem am I trying to solve?"

I've been down many of those endless alleys in my time as a programmer, but I think it's safe to say that I've avoided some of them because of the work that Paul did and inspired others to do.

Edited to add:
obituary
memorial article in the Yale Daily News; highlights:

“He is the most complete person I have ever seen, embodying qualities that you don’t believe can coexist … extremely kind, patient, gentle yet also super sharp, smart, and creative, and also highly eloquent, and totally cool,” CS professor Zhong Shao said. “He has made enormous impact on so many people in different walks of his life, but most of all, he, by himself, is the best role model which all of us all strive to become. He has certainly influenced me in a very profound way, not just career wise but also how to be a great person.”

and

"During his tenure as department chair from 1999 to 2005, Hudak made an important effort to expand the CS’s diversity, hiring four female senior female professors to a department that had existed for nearly three decades without a single tenured woman, according to CS professor Julie Dorsey."

Previous notes: ICFP, days 1, 2, 3.

These notes are about Friday, September 5. Thursday, I missed the whole day of conferencing and only went to the industrial reception in the evening. I hadn't planned to go to many talks on Thursday anyway, but I ended up spending Wednesday night (all of it) in the ER at Östra Sjukhuset, since I didn't know how else to get a relatively minor thing requiring antibiotics treated at night. (Since I didn't get seen till 5 AM, I should have just waited till the next morning!) So that meant sleeping till about 3 on Thursday.

On Friday, I'd been planning to mostly go to the Erlang Workshop and drop in on a Haskell Symposium talk or two, but I ended up doing the opposite, oops. Somehow, I always end up going to the "Future of Haskell" discussion, even in years when I'm not doing Haskell. I already talked about the discussion a little bit in my Ada Initiative fundraiser post; what Wouter said about being encouraging to newcomers was part of it. During the discussion part, somebody stood up and said "well, as far as I'm concerned, everything's fine because the Haskell community has been friendly to me and I've had a good experience." I'm probably being a bit unfair to him, but certainly the implication was that his good experience was a sign there was no problem, even if he didn't say so explicitly. I stood up and pointed out that the people we need to listen to are the ones who aren't in the room -- presumably, everyone who was attending the Haskell Symposium was there because they had a good experience with the community. I don't think I exactly said so, but further compounding things is that some of the specific people who have been particularly hostile to novices were in the room. If you have no idea what I'm talking about at this point, Gershom's "Letter to a Young Haskell Enthusiast" should be a good start. I'm motivated here by having friends who wanted to learn Haskell but gave up because people were hostile to them, and I hate that the response to that is for people to say their experiences were good -- that doesn't give me anything to tell my friends.

I also touched on this in my fundraiser post, but the fact that on day 2 of the Haskell Symposium, there were maybe 100 people in the room and (as far as I could tell) none of them were women, by itself, indicates that there's a problem. Arguments that women just aren't interested in Haskell, or aren't good at it, or prefer to do real-world things where they get to help people (unlike teaching and research, I guess?) have so little merit that they're not worth discussing. I know that the lack of women in the room was for a reason, which is that largely, women aren't finding the Haskell community -- or the functional programming community, or communities around programming language theory and practice more broadly -- welcoming. The fact that there are a few exceptions means that a few women who have an exceptional level of interest, talent, and (for some, anyway) privileges along axes other than gender have been able to make it. They should be listened to for the same reason that someone who runs marathons while wearing a 100-pound backpack knows more about running marathons than someone who runs marathons unladen. But it's not enough for a few exceptional women to be allowed in -- to paraphrase Bella Abzug, equality doesn't mean access only for the exceptional women, but for mediocre women to do as well as mediocre men.

Wouter made a comment about "encouraging women", and while we should, I wish people would spend less time saying "encourage women", and more time saying "don't be a jerk". Of course, neither imperative means much without further detail. As Gershom's letter reflects (indirectly), when I say that the community is unwelcoming to women, it's often not about overt sexism (though there is some of that), but rather, a very popular aggressive, adversarial, confrontational teaching style that many people apply to a broad range of interactions besides those that are understood as teaching situations. And it's not that women don't like to be or don't want to be aggressive -- it's that they know from lived experience that being aggressive and adversarial with men has consequences, and not good ones. This is the double bind: there is a very narrow range of allowable behavior for women in any grossly male-dominated subculture, and a very wide range for men. So besides just "encouraging women", men also need to approach intellectual conversations in ways that aren't about showing dominance... even when they're only talking to each other.

Here's the video of the entire discussion, which I think includes all the audience comments.

After lunch, I went to some of the Erlang Workshop talks. The first one was Amir Ghaffari on "Investigating the Scalability of Distributed Erlang". The talk didn't spend much time introducing Distributed Erlang itself, but rather, focused on running DE-Bench (the benchmark suite for it) on different number of nodes to see how well Distributed Erlang scales. DE-Bench lets you run tests synchronously or asynchronously, on one or all nodes. Ghaffari found that throughput drops off dramatically if you start using global operations (which, intuitively, isn't surprising). He also found that latency for global commands grows linearly in the number of nodes -- I wasn't so sure why that was true. He found that Riak didn't scale past 70 nodes at all -- at that point, an overloaded server process became the bottleneck. He concluded that everything about Distributed Erlang scales well except for RPC; not being familiar with Distributed Erlang, I'm not sure how much of a problem that is.

In the next talk in the same session, Chris Meiklejohn spoke on dataflow-deterministic distributed dataflow programming for Erlang. The talk was about using Erlang to build a reference implementation for CRDTs, as well as building a new language (that is, a subset of Erlang) for CRDTs. It was cool that Meiklejohn was implementing some ideas from Lindsey's work, both because I know Lindsey and because it was something I'd heard about before, so I had at least a moment where I got to feel smart ;)

Meiklejohn and colleagues' system, DerFlow, is state-based; CRDTs require something to grow monotonically, and in this case, it's state. Meiklejohn pointed out that for distributed systems, this is great, because unreliable networks mean that packets could get dropped, but never cause already-transmitted data to be forgotten. Proving correctness means proving properties over the lattice of choices; a choice is a particular sequence of messages received by a program. Their memory model is a single-assignment store: any given memory location goes from null (no binding), to variable (which means it's "partially bound"), to value (bound). If one node asks for something unbound, it will wait until it becomes bound -- so, deadlock can happen. I'm handwaving a bit in my explanation here, but fortunately, you can go look at the code yourself on Github!

Finally, I went to one last Haskell Symposium talk that I wouldn't have gone to if Ed Kmett hadn't recommended it, and indeed, it was worth going to: Atze van der Ploeg's "Reflection Without Remorse". The talk was cool, but at this point my brain was pretty fried and I bet the paper will be even cooler. van der Ploeg motivated the problem by talking about how a chain of list append operations gets evaluated depending on associativity -- depending on where you parenthesize, one way is a lot more expensive than the other. I think this is the same problem as the infamous foldr/foldl problem. The solution (that makes the cost of evaluation the same regardless of associativity) is to rewrite expressions in CPS form -- this looks to me a lot like the build operation from shortcut deforestation. If I'm not totally lost, I think during this talk, I finally understood why build is called build for the first time (and I did my undergrad and master's theses on shortcut deforestation) -- the build form represents building up a list as a continuation. Then you run into a problem with having to convert between list repreesntations and function representations and vice versa -- I think I actually ran into something similar in my master's thesis work that I didn't quite know how to handle, so if I'm in a mood for revisiting some ancient history, maybe I'll try to figure out if there's really a connection there or not.

So far, apparently, Okasaki already solved the problem -- just for lists -- in Purely Functional Data Structures. But you can actually generalize the problem to all monads, not just lists! That's where it gets really cool. The continuation monad transformer for monads (which I don't understand) is apparently another instance of the same problem. My mind started melting a little at this point, but the upshot is that you can do monadic reflection, where you have interchangeable continuation-based and concrete forms of a data structure and can alternate between building and reflection.

That's all for Friday -- stay tuned for my final ICFP-ish post, in which I'll summarize the CUFP talks.

It's usually a good thing when people talk about ways to increase women's participation in programming communities. I used to be active in the Haskell community, so normally, that the subject came up during the annual "Future of Haskell" discussion at this year's Haskell Symposium would be something for me to cheer about.

Sometimes, men talk about the gender disparity in tech communities as if there's some big mystery. I have to conclude that these guys haven't talked to women who currently work in computer science academia and the tech industry, or who did and then left. As someone who was perceived as a girl or woman doing computer science for 12 years, my solution to the lack of women in tech is:

Stop telling women that they aren't welcome and don't belong.

During the "Future of Haskell" discussion, Doaitse Swierstra (a professor of computer science at the University of Utrecht), suggested that a good way to increase the number of Haskell programmers would be to recruit one woman for every man in the room and that this would be a good thing because it would "make the meetings more attractive".

In other words: he followed a call for more participation by women with exactly the kind of comment that tells women that a space is unsafe for them.

Suggesting that more women would be welcomed at a conference because they would make it "more attractive" is saying that women are valued for how they look, not for what they do. If you've ever heard the words "objectification" or "hypersexualization" and not known what they meant, well, look no further than this comment for an example. And because many women see spaces where they are targets for the male gaze as spaces where they will be targets for more than just men's gazes, it's a comment that carries the underlying message that the computer science conference under discussion is not, in fact, a place where a self-protecting woman ought to be. It's not that Prof. Swierstra said any of this outright, of course. He didn't have to. English-speaking academicians are part of that subset of the world in which everyone comes pre-installed with the cultural programming that means a few words about the "attractiveness" that more women participants would bring to the Haskell Symposium evoke a whole world of stereotypes -- ones that limit women's choices, careers, and lives.

Swierstra's remarks were also potentially alienating to any non-heterosexual men who were present, as they reflected an assumption that he was speaking to an audience of people who found women, and only women, "attractive". Finally, there is a tacit understanding when one talks about "attractive" women that one is talking about women who have cissexual bodies, are thin, aren't disabled, and are in a particular, narrow age range. So apparently, if you're a woman and not all of those descriptors apply to you, maybe you shouldn't think about learning Haskell, as your presence wouldn't make the Haskell Symposium more attractive (to heterosexual men).

So while Prof. Swierstra may have meant no harm -- may indeed have meant to do good by encouraging efforts to increase women's participation in the Haskell community -- what matters is not his intent, but the effect of his words. (Everyone who's ever written code knows that the compiler doesn't care about your intent; extend that to your interactions with other people, and you might find yourself behaving more fairly.) Any women who were in the room for the meeting (and when I have attended it in the past, there have always been at least a few) got the message that if they weren't there to be pretty, why were they there? And any women who watched the video of the discussion (relevant part begins around 32 minutes in) got the message that the Haskell community is a community that tolerates sexism.

When I watched the video, what I heard after Prof. Swierstra's comment about attractiveness was laughter. No one called him out; the discussion moved on. I might be wrong here, but the laughter didn't sound like the nervous laughter of people who have recognized that they've just heard something terrible, but don't know quite what to do about it, either (though I'm sure that was the reaction of some attendees). It sounded like the laughter of people who were amused by something funny.

It would have taken just one person to stand up at that moment and say, "That was sexist and it's not acceptable here." (That person would probably have to be a senior faculty member or researcher, someone of equal rank to Prof. Swierstra; challenging a male, senior researcher is not something a female grad student (or even maybe a male grad student) should be expected to do.) But nobody did. And that's what really disappoints me. Structural sexism persists not because of the few people who do and say blatantly bad things, but because of the majority who tolerate them. People say things like the things Prof. Swierstra said because they are socially rewarded for it: they can get a few laughs. Also, they can display their membership in a high-status group (heterosexual men). Take the reward away, and the comments and actions that exclude go away too.

I expected more from the people who attend the Haskell Symposium. I expected more because for years, I attended ICFP and the Haskell Symposium, and even in the days when I didn't identify as male and didn't usually challenge others' perception of me as a woman, I felt like I was in a community where I belonged when I was there. For the most part, I didn't feel like my perceived gender was called attention to, and I felt like I would be judged based on what I could contribute to a conversation rather than on whether a man would find my appearance pleasing. If my first Haskell Symposium as a twenty-year-old had been in 2012 instead of 2000, I wouldn't have come away with the same impression. And I don't know if I would have gone back.

I'm no longer in the community of people who attend ICFP, and I no longer work on Haskell projects. My academic career ended a year ago when I was told that I couldn't be a grad student if I didn't want to interact with another student I'd witnessed joking about raping a fellow student. I have a job that doesn't involve Haskell, and lack the privilege of having spare time and energy left to do programming projects when I'm done with paying work. There have been days when I've had regrets. Today is not one of them. If I'd continued doing functional programming research, I could have been an agent for change; sexism no longer affects me directly now that folks have to have it spelled out for them that I'm not a cis man. Still, I don't feel like a community that makes somebody feel like it's acceptable to say that women would add "attractiveness" to a professional meeting is a community that I belong in.

If you are a man in this community, please don't feel like you have no power. You actually have a lot of power: you can let people who make these comments know that sexism isn't okay. The Geek Feminism Wiki's "Resources for allies" page is one resource that can help; the wiki also has a page of good sexism comebacks. Some comebacks that might have helped in this situation are: "I don't think that sounds as funny as you want it to sound"; "Who let you think it would be okay to say something like that?"; "Excuse me? / "I'm sorry, I don't quite understand what you're trying to say. Could you state it more plainly?"; "It sounds like you are implying <sexist thing>. I'm sure you don't really think that. <change subject>"; "That was sexist"; and (if used by the moderator) "We're done" and "That was sexist, and that is not acceptable here." Of course, there are others. The most important thing you can do to be an ally is to listen to women, and people who are perceived as women, in your community. Don't lecture people about how to respond to difficulties you haven't faced; simply learn from their own self-reporting of their experiences. Of course, don't demand that others educate you without establishing trust, either.

Countering sexism requires courage and (in Samuel Delany's words) moral stamina. It is work that largely needs to be done by men, since men who tacitly believe that women aren't quite human are hardly going to listen to women's opinions on the subject. For men to do this work, of course, they have to believe that women belong in their communities, that women are more than just attractive bodies, and that their communities will benefit from the inclusion of women -- benefit in ways that are not about aesthetics. Whether from within or without, I hope that the Haskell community will include more men who have this courage and who believe these principles -- whether or not the presence of those men makes the community more attractive.

---

Addendum: If you're coming here from Reddit, please take the time to read four background pieces that are part of my earlier series of essays "A Problem With Equality": "Power and privilege", "Systems and individuals", "What oppression is", and "Emotional invalidation". Most criticisms of the piece you're reading have already been answered in one of these essays.

Since Facebook is made out of monkeys smoking crack and won't let me post this image, here's where I went biking today:

Definitely better than where I went biking on Friday:

And finally, I'd like to say that LA is a strange place, but this picture was actually in Glendale: