Long overdue, here are my notes on the talks at CUFP 2014 (September 6, 2014). This is the last in a series of conference write-up posts from me that cover CUFP, the Haskell Symposium, Erlang Workshop, and the three days of ICFP itself. CUFP is the workshop for Commercial Users of Functional Programming, and I was honored to have served on the program committee for it this year.

Joe Armstrong's invited talk, "Making Money with FP", was quite entertaining... for the most part anyway. His comment that you can't sell a language, and must sell a project written in it, harked back for me to working at Laszlo Systems in 2005.

He made the point, about adoption of FP, that "nobody ever got sacked for using Microsoft products (or Java, or C++" -- also this gem, "You get paid based on the number of people you manage, so people hate the idea that ten Haskell programmers can do what 100 C++ programmers can do." (I'm not confident that that generalization always holds, but it does seem to be true in my experience.)

One aside that marred an otherwise great talk was an unnecessary use of "guys" on a slide, when Armstrong said (while speaking to the same slide) "technical guys enjoy an argument". One or the other and I might have let it slide, but not all "technical guys" enjoy an argument, plus technical women who enjoy arguments are punished for that while technical women who don't enjoy arguments tend to get steamrolled.

Then, Armstrong went on to talk about different business models for making money from FP. Most of this advice seemed broadly applicable, but it was still good to hear it coming from one of the people who is most qualified to talk about "how to make money with FP". He implied, I think, that the best two routes for a person trying to get into business with FP were either a consultancy (where you are an independent businessperson who sells consulting hours or services to other companies) or a development/R&D company where the goal is to "develop a product and sell it to a bigger company that can sell it." He explained how a good way to gain a reputation is to participate in the standardization of a language or framework: either choose a new standard or invent one of your own, and then make the best and first implementation. Then, you sell or give away software to build your reputation (which is why you can't sell a language, I guess!) and finally, sell the company :D
( Read more... )

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.

These notes are about Tuesday, September 2.

I caught the end of Robby Findler's invited talk on behavioral software contracts. That was enough to catch a point that I found thought-provoking: that contracts aren't a subset of types, because contracts can express protocol-based properties (similarly to how session types do), which fundamentally involve assignment. I'm still mulling it over, and I should probably just watch the whole talk, but it might be the answer to a question that has plagued me for years, which is: "are contracts just type signatures that you put in a comment?" (Not meaning to participate in a holy war here -- I assume the problem is my lack of understanding.)

If that's true, it reminds me of typestate in Rust, which I implemented for my intern project and which was later removed from the language. Or, maybe, Rust's typestate wasn't as powerful as contracts are, and that's why people didn't find it useful in practice. I do remember always being really confused about the interaction between typestate and assignment -- we went back and forth between thinking that typestate predicates should only be able to refer to immutable variables, and thinking that we'd take the YOLO approach and leave it as a proof obligation for the user that mutation can't cause unsoundness. So maybe if I had understood contracts at the time, the whole thing would have gone better. In any case, I'd like to read more so that I can articulate the difference between typestate and contracts.

I caught slightly more of David Van Horn's talk on soft contract verification, though I missed part of that talk too. The principle here is to allow assigning blame when an assertion fails at runtime: then, you can write your code so as to have strong enough contracts so that your code is to blame as infrequently as possible when something goes wrong (if I understood correctly, anyway). ("Blame" is a technical term introduced by Dimoulas, Findler, Flanagan, and Felleisen, at least if I have the correct initial reference.) As in soft typing, "soft" here means that the contract checker never rejects a program -- it just introduces runtime checks when it can't convince itself of a particular safety property at compile time. This also recalls Rust typestate for me, which had a very similar approach of falling back to runtime verification (actually, in Rust, all typestate assertions were verified at runtime; we thought that would be a simpler approach, and if the feature had persisted, we might have implemented some sort of analysis pass to eliminate some of the dynamic checks). In my copious free time, I'd love to revisit Rust typestate and compare and contrast it with the work presented in these two talks, as well as gradual typing and effect systems, maybe even as a paper or experience report. (Which, of course, would involve me learning about all of those things.) I want to say that Rust typestate did have an analogous notion to blame: it was all about forcing each function to declare its precondition, so that if that precondition was violated at runtime, we knew it was the caller's fault, not the callee's. But I'd like to read the paper to see how much of a role inference plays.

As a much more trivial aside, I really liked that Van Horn used ⚖ as an operator, at least in the slides (as in, C ⚖ M). There should be more Unicode operators in papers! It's 2014; we don't need to limit ourselves to what was built into a 1990s-era version of LaTeX anymore.

In any case, the parts of Van Horn's and Findler's talks I heard made me think "this is the right way to do what we were trying to do with typestate". I want to be sure I believe that, though. I say this because their approach to handling mutation is to statically check any contracts that don't involve assignment -- other contracts revert to runtime checks, but the checks always happen, either statically or dynamically. My memory is hazy, but in the context of Rust, I think we talked about introducing additional precondition checks at each use of a variable involved in a typestate predicate, but quickly decided that would be inefficient. In any case, those two talks made me want to revisit that work, for the first time in a while!

I missed most of Norman Ramsey's talk "On Teaching How to Design Programs as well, but the paper seems worth reading too. Two things I did catch: Norman saying "Purity has all sorts of wonderful effects" (I think in terms of helping students discipline their thinking and avoid just banging on the keyboard until something works, though I don't recall the context), and him making the point that the HTDP approach makes it easier to grade assignments based on how systematic the student's design is, rather than a laundry list of point deductions.

Next, I went to Richard Eisenberg's talk "Safe Zero-Cost Coercions for Haskell". I have painful memories of this line of work dating back to 2007 and 2008, when I was reviving the GHC External Core front-end and had to figure out how to adapt External Core to represent the new System FC type system features, which (to me at the time) seemed to make the Core type system twice as complicated for unclear benefit. (External Core was removed from GHC some years later, alas.) I'm willing to say at least provisionally, though, that the work Eisenberg presented cleans up the coercion story quite a bit. I also appreciated the motivation he gave for introducing coercions into the type system at all, which I hadn't heard formulated quite like this before: you can typecheck System F just using algebraic reasoning, but when you want to introduce coercions (which you do because of GADTs and newtypes), contravariance ruins everything. I think a way to summarize the problem is that you get overlapping instances, only with type families rather than just type classes.

To solve the problem, Eisenberg and colleagues introduce two different equality relations: nominal ~, and structural ~~. This allows the type system to incorporate coercions based both on nominal type equality, and structural type equality, without having to pick just one. Then, each type parameter gets a "role", which can be either "structural" or "nominal". This allows coercion kinds (my nemesis from the External Core days) to just go away -- although to me, it seems like rather than actually taking coercions out of the kind system, this approach just introduces a second kind system that's orthogonal to the traditional one (albeit a very simple kind system). I guess it's possible that separating out concerns into two different kind systems makes the implementation and/or reasoning simpler; also, as far as I can tell, roles are more restricted than kinds in that there's no role polymorphism. (I'm not sure if there's kind polymorphism, either, although there certainly was in GHC at least at some point.) Actually, there are three roles: "nominal" (meaning "this parameter name matters and is not interchangeable with structurally equal types"), "representational" (for a type that is interchangeable with any others that are structurally equal to it), and "phantom" (type parameters that are unused on the right-hand side of a definition). I wrote in my notes "I wonder if this sheds any light on Rust traits", but right now I'm not going to elaborate on that query!

The implications of the work are that generalized newtype deriving now has a safe implementation; the type system makes it possible to only allow unwrapping when the newtype constructor is in scope. (This, too, reminds me of a Rust bug that persisted for a while having to do with "newtype dereferencing".) The results were that the new role system uncovered three legitimate bugs in libraries on Hackage, so that's pretty cool. Also, Phil Wadler asked a question at the end that began with something like, "...here's how Miranda did it..." (Not something one hears a lot!)

Finally, I stayed for François Pottier's talk "Hindley-Milner Elaboration in Applicative Style", which I understood more than I expected to! He began by saying something that I noticed long ago, but originally chalked up to my own stupidity: Algorithm W in its original presentation, was "imperative, and messy". We want a simpler, more declarative formulation of type inference. Pottier claims that conjunctions and equations are simpler than compositions and substitutions -- I agree, but I'm not sure if that's based on something objective or if that's just what works well for my brain. He defines a constraint language that looks like λ-calculus with existential types, which allows constraint solving to be specified based on rewriting. On paper, it's a declarative specification, but the implementation of it is still imperative (for performance reasons). It sounds like it might be fun to prove that the imperative implementation implements the declarative specification, though perhaps he is already doing that!

Stay tuned for my notes on day 3, when I get around to editing them.

See that number? It has five digits in it.

Comprehensive retrospective and thanks post coming soon once I'm done having all the feels. For now, I just want to thank the last batch of donors from this afternoon (the ones who tweeted and/or gave permission for their names to be used):

alleynoir
Dan Licata
Darin Morrison (edited to add, with permission)
David Smith
Eric Rasmussen
Glenn Willen
Holly M
Lucas Bradstreet
wilkie

As always, if I left out anyone, let me know.

And if you weren't paying attention all week? Now it can be told: if you donate now, the money still goes to exactly the same place :)

We're on day 3 of 4 in the functional programming community challenge -- we're less than $1000 from our $8192 revised goal! We have exceeded our second goal, $8192, and have increased the goal to $10,000!

Thanks to the people who donated between 3:00 PM September 17 and 6:00 PM September 18 who gave permission for their names to be used and/or tweeted saying that they donated; if your name is not on the list and you donated, then you either didn't give permission, didn't use the ?campaign=lambda URL suffix, or something somewhere got messed up; if so, email me (catamorphism at gmail) and we'll fix it.

AlephCloud Systems -- our first corporate donor! (We'd love more.)
Corey "cmr" Richardson
Eric Kow kowey
Jack Moffitt
Philip Wadler

As well as those who donated earlier, but whose names got left off the first list somehow:

Aaron Tomb atombeast
algebraic affects joshbohde
Bob Atkey bentnib
Maggie Litton MaggieLitton

And finally, thanks to haskellnow, haskellorg, and lambdaladies for help publicizing!

Giving money is a good start, and I hope that at least some people will be moved to collaborate with the Ada Initiative in other ways. In any case, it shouldn't end there. Here are 12 other things that functional programmers who want to support and include women can do:

1. Know what intersectionality is
   This is tricky to talk about, because TAI and the loosely affiliated Geek Feminism Blog and Geek Feminism Wiki are all run mostly by white people (like me). We all know there's a problem here; we talk about how there's no excuse for companies and open-source communities to be 100% male, yet we're almost 100% white.
   
   With that said, to be an ally, being open to feminist perspectives isn't enough. Intersectionality, a term coined by Black feminist scholar Patricia Hill Collins, refers to the ways in which membership in multiple oppressed groups is not compositional. That is, a Black woman's experiences (for example) are not merely the result of composing a prototypical white woman's experiences with a prototypical Black man's experiences; rather, multiple marginalizations compose in a more complicated way. When it comes to understanding a concept like intersectionality, functional programmers have an advantage: like intersectional feminists, we are often criticized for using too many long and unfamiliar words. So we should know as well as anyone that sometimes, technical language is necessary for clarity. (Insert pun about intersection types here.)
   
2. Attend an Ally Skills workshop
   
   The Ada Initiative runs workshops that teach men how to better support women in their workplaces and other communities. I participated in the Ally Skills track during this year's AdaCamp in Portland, and I appreciated that it was designed primarily around small-group discussions of hypothetical but realistic scenarios. For a reasonable fee, TAI will hold one at your workplace, and one thing that donations finance is holding them at nonprofit organizations for a reduced cost. You just have to ask.
   
3. Listen to women
   
   When a woman talks about her experiences, and you have never had the experience of being perceived as a woman, try something: assume she is reporting on her own experiences accurately. Almost all the time, your assumption will be correct. But more than that, it's an important skill to be able to temporarily suspend your programmerly desire to find edge cases and point out errors, and just listen. Listening doesn't always mean shutting the heck up, although sometimes that's what's needed too. Rather, active listening means acknowledging that you understand what's being said: you can do this non-verbally (for in-person discussions) or by rephrasing what the person said in different words to indicate your comprehension and validate what she is saying. In light of point 1 about intersectionality, the more intersecting oppressions somebody has, the more important it is to listen to and let them know that you hear them.
   
   This doesn't mean you have to believe everything all women say all the time. Rather, it means that there are already enough men in the world automatically casting doubt on everything a woman says, and you don't need to be one more. Indicating that you hear what somebody is saying doesn't mean agreeing. It means that for the moment, you prioritize understanding their message ahead of showing off how much you know or how good you are at debates. You can decide offline whether to agree.
   
4. Believe women
   
   But I just said you didn't have to agree! Well, yes, you don't have to, but in a world that bombards more or less all women with gaslighting, believing a woman is a radical act. In particular, if a woman is talking about her experience of harassment or another adverse experience that typically involves men mistreating women when no other men are present, assume she's telling the truth (and if anything, understating how bad it was). You will almost never be wrong if you believe her, and it's better to have a vanishingly low chance of being wrong than to contribute to the systematic psychological torture of women who are honest about their lives.
   
5. Help women get heard
   
   Say you're in a meeting and a woman says something; it's ignored, and 15 minutes later, a man rephrases the same idea and gets praised for it. At that moment, you can speak out by saying, "How does that compare to the idea that [woman's name] proposed?" This is a non-confrontational way to re-center the woman as originator of an idea. In general, if you're in a conversation and other people are steamrolling a woman or women, say something -- you don't have to say "you sexist pigs, why don't you listen to her?" unless you want to, but there are many different ways to indicate that, if nothing else, you heard her.
   
6. Hire women
   
   If you work at a software company and have any influence over hiring, hire women. The same goes if you work at a university, even if the hiring process is a bit more byzantine. In computer science or in software, anybody who is not a cis man is more qualified than an imaginary person who is identical except being a cis man. Isn't that "reverse sexism"? No, for the same reason that it's harder to do a pull-up with 50 pounds of weights strapped to your ankles than without. Give women (as well as people of color, disabled people, trans people, queer people...) credit for the enormous amount of work they've had to do just to be seen as equally competent to a given man who is actually less competent. In functional programming, nobody would do this work just for fame and wealth, because there is very little of that to be had; someone purely interested in a high-paying job or other extrinsic motivators would never choose our field if they also had to deal with others' bias along with the risk of not getting rewarded at all. The people who do persevere do it because they love the work they do, probably more than you do.
   
7. Practice your empathy
   
   If you have lived your entire life in the Western Hemisphere being seen as a white, cis, abled man, you probably have some work to do here. It's not your fault: it's likely that you've rarely been rewarded for taking the perspective of someone unlike yourself, and indeed have been coddled for solipsistic thinking rather than being encouraged to think of others' feelings. Fortunately, empathy is a skill that can be learned. Kronda Adair's talk Expanding Your Empathy (from Open Source Bridge 2013) is one place to start.
   
8. Encourage double-blind reviewing
   
   This one applies to those of you who review for and/or help organize academic conferences. It is documented beyond a shadow of a doubt that innate bias affects decisions about people's work: when evaluators know that a particular article is by somebody with a name they interpret as female, they grade it more harshly than if all of its authors had male-coded names. Most people don't want to exercise bias against women, but they do anyway, subconsciously. Concealing author names during reviewing goes part of the way towards addressing this problem. It's not perfect, but someone claiming that it doesn't reduce bias is making an evidence-free claim.
   
   Non-academics can try applying this one by having their recruiting team (if they have one) redact names from resumes during the first round of candidate evaluation.
   
9. Show fallibility and humility
   
   This one has to be exercised carefully, but if you are someone with a relatively high amount of power (for example, if you're a white cis man who has a tenure-track or tenured academic position, or are a manager in an industry position), it's helpful to others around you if you say "I don't know" when you don't know, admit mistakes when you are wrong, and acknowledge when you're finding something difficult. Sometimes people underestimate just how much influence they have. If you're white, cis, and male, whether you like it or not, the people around you will tend to believe the things you say. With that increased power comes increased responsibility: to scrupulously distinguish what you believe to be facts from what you know are your opinions.
   
10. Volunteer to mentor women
    
    For example, the GNOME Outreach Program for Women matches promising women getting started in open source with mentors from various projects. This is one of the most direct, personal ways you can help. If you don't work on an open-source project, find out what your company can do in the way of outreach at local schools, or if you're a faculty member, figure out what your department can do to support women in undergrad and graduate CS programs instead of just tallying up your admission numbers and cheerfully declaring diversity a done deal while all the women get constructively dismissed.
    
    If you do this, though, be prepared to learn as much from your mentee as vice versa.
    
11. Try to be kinder than you have to
    
    I don't mean that you need to be kind to people who are abusing or oppressing you; you don't. What I mean is that you have the affordance of being patient when somebody asks the same beginner question for the nth time on a forum you're on, or when somebody makes a wrong assumption based on their knowledge of a different programming language. It's easy to lose patience with people who don't know as much as you do; I've done it a lot myself. But it takes very little to make somebody give up on a community that is new to them, and I've personally seen that happening with functional programming. When somebody else genuinely seems to be acting in good faith, even if they're confused or seem to be slow on the uptake, just remind yourself that you have a privilege that they lack (knowledge) and give them the benefit of the doubt.
    
12. Remember that functional programming is a part of programming, and programming is part of the world.
    
    You might react to some of these suggestions with, "what does that have to do with functional programming? That happens everywhere." Indeed. Most of these bullet points are not specific to our field. But global problems must be addressed locally, in the community that you're in. The good news is that everything you do to make functional programming a safer field for women, and genderqueer and non-binary, people to be in will also make programming as a whole that much safer, as well as the world as a whole.
    

Don't forget to tweet to #lambda4ada when you donate! Suggested tweet, though you're encouraged to use your own words:

I donated to @adainitiative b/c I want @TheOfficialACM events to announce their anti-harassment policy. https://supportada.org?campaign=lambda #lambda4ada

Don't forget to tweet to #lambda4ada when you donate! Suggested tweet, though you're encouraged to use your own words:

I donated to @adainitiative b/c I want @TheOfficialACM events to announce their anti-harassment policy. https://supportada.org?campaign=lambda #lambda4ada

So far, the following people from the functional programming community have donated to the challenge, as well as a number of anonymous donors. If your name appears here, it's because you checked the box that says it's okay for TAI to share your name, for which I thank you as well -- knowing who has donated so far makes it easier for other people to decide whether to donate. If you want to be as cool as these folks, then donate and (optionally) tweet about it!

In addition, I made an additional matching donation of $64 (on top of my usual $80/month), and my fellow challenge organizers Adam Foltzer, Clément Delafargue, and Chung-chieh Shan have donated as well. If your name doesn't appear here, you want it to, and you donated between September 1 and 3:00 PM Pacific Time on September 17, email me at catamorphism at gmail and I'll add it. (If you donated after that, don't worry, I'll be doing more thanks posts!)

In alphabetical order by first name:

Aaron Levin / Weird Canada
Alejandro Cabrera
Ben Blum
Bethany Lister
Carlo Angiuli
Chris Martens
Colin Barrett
Colin Gourlay
Dan
Dan Peebles
Daniel Ross
David Van Horn
Dylan Thurston
Edward Kmett
Florent Becker
J. Ian Johnson
Jon Sterling
Joshua Dunfield
Lars Hupel
Manuel Chakravarty
Pat Hickey
Prabhakar Ragde
Wouter Swierstra

Thanks as well to everybody else who has tweeted under #lambda4ada so far! Keep it up.

To all of you on this list, as well as to the donors who preferred not to be named: thank you! And if you haven't yet donated, you still have until Friday, September 19 at 5 PM for your donation to count towards the challenge. We have more than satisfied our initial $4096 goal, and are trying to raise $8192 by Friday. [Edit: We have raised $8678 and are now aiming for $10,000 before the end of business, Pacific time, on Friday!] What's more, if we raise $16,384, then the four of us will record a version of "There's No Type Class Like Show Type Class" and share it with the world. We appreciate your past and incoming donations, tweets, and blog posts!

The following is a guest post from Adam Foltzer (acfoltzer).

Our Challenge

This fall, I'm joining with Tim Chevalier, Clément Delafargue, Eric Merritt, and Chung-chieh (Ken) Shan to challenge the functional programming community to help make computer science conferences more welcoming to more people. We have two goals:

1. Support the work of the Ada Initiative by donating $4096 $8192 by 5pm Pacific time on Friday, September 19th. Use and share the URL https://adainitiative.org/donate/?campaign=lambda so that we functional programmers may be counted!

   (Edited to add: We reached our initial $4096 goal at 1:15 PM Pacific time on Tuesday the 16th, so we are now aiming to raise $8192 by Friday!)

2. Call on the ACM to definitively support and publicize their anti-harassment policy for their conferences. If you're on Twitter, tweet @TheOfficialACM with the hashtag #lambda4ada with something like:

I donated to @adainitiative because I want @TheOfficialACM to stand behind their anti-harassment policy https://adainitiative.org/donate/?campaign=lambda #lambda4ada

Being part of the functional programming community has been an incredibly valuable and rewarding part of my life. Much as Tim says in his post, conferences like ICFP offer a wonderful recurring dose of friendship, support, and belonging.

However, conferences like this are not necessarily as welcoming to folks who aren't white, cis, hetero, well-off men like me. This isn't usually due to any overtly toxic behaviors as in other communities (hi, fellow atheist gamers!), but due to a combination of incidental condescension, microaggressions, and other subtle ways that often well-meaning people can exclude those who aren't already part of the in-crowd. We can push back against these exclusions by supporting the work of the Ada Initiative and making sure ACM stands behind their anti-harassment policy.

In the last year I have become a member of the Haskell.org committee, donating my time to help improve our community, but I am under no illusions that the balance is equal. Because of functional programming, I have a career so cool I could not have imagined it, I have friendships of great depth and strength, and I have the privilege of constant learning as we discover and invent together every day. Laying down this challenge is part of what I can do to repay this debt, and I hope you will do the same.

The Ada Initiative does important work supporting women in a broad range of technology fields through the development of codes of conduct, anti-harassment policies, advocacy, and education. Their model anti-harassment policy is the basis for the ACM's, and their work informs much of what we are working on in the Haskell.org committee to improve the inclusiveness of Haskell specifically.

The Ada Initiative does valuable work worth supporting. Every month I donate $32, and for this challenge will be donating an additional $128. Join me in reaching for that $4096$8192 goal (powers of two, y'all!): https://adainitiative.org/donate/?campaign=lambda

The ACM has done well to adopt an anti-harassment policy, but to have impact it must be consistently supported and publicized along with their conferences. Join me in calling on them to do so:

I donated to @adainitiative because I want @TheOfficialACM to stand behind their anti-harassment policy https://adainitiative.org/donate/?campaign=lambda #lambda4ada

And finally, as a functional programmer, you probably know at least 5 other people who have benefited from being part of such a weird and delightful community. Pass this challenge along to them and give them the chance to help us reach our goals. Let's make it happen!

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.