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.

If you are one of the Mozillans who expressed disbelief that another Mozillan would do such a thing, in response to what's described in this post from two years ago, then read this tweet from today.

These notes are about Wednesday, September 3.

The first talk I went to was Carlo Angiuli's talk on homotopical patch theory. I understood very little about the actual new work in the talk, but I'm very glad to finally have at least a vague sense of what homotopy type theory is about (though I no longer remember how much of that came from the talk, and how much came from talking to Carlo and to Ed Kmett the day before :) I was about to write down my hand-wavy summary of what I think it's about, but I realized it's too hand-wavy to even write down. But, I want to read more about it, and if you're curious, so can you!

The next talk I went to was Niki Vazou's talk on refinement types for Haskell. Refinement types are cool, but sadly, I lost the thread (totally my fault in this case) somewhere after Vazou said something about using refinement types to prove termination for themselves. At that point, I wrote down an outraged little comment on my notepad that ended with a note to myself to read the paper. The other thing about this talk that I noted, which I hate to mention -- but really, what I hate is that it's even noteworthy at all -- is that during the Q&A period, a woman asked a question at a talk given by a different woman. This was the 10th ICFP I've attended, and I'm pretty sure this was the first time I've seen that happen at ICFP.

Then I missed most of Conor McBride's talk "How To Keep Your Neighbors in order" indirectly due to listening to Ed tell his (edited, I'm sure) life story. If you get the chance, you should ask Ed his life story; he may be the closest person to a character in a Hunter S. Thompson book who you're likely to meet at a computer science conference.

Next (for me) was Simon Marlow's talk "There is no Fork: an Abstraction for Efficient, Concurrent, and Concise Data Access", which was probably the best talk title of ICFP 2014. Simon talked about his work on Haxl, motivated by wanting an implicitly concurrent language for fetching data incrementally and lazily. This reminded me a bit of what I overheard when I was working on Rust about Servo's incremental layout, but I don't remember it well enough to know if that's a red herring or not. I'll be interested to read the paper and see if there's any comparison with Erlang, as well.

Jeremy Gibbons began his talk "Folding Domain-Specific Languages: Deep and Shallow Embeddings by saying that his co-author Nicolas Wu couldn't be there because "he has taken delivery of a new baby". Which was funny, but possibly took someone else out of the picture a bit ;) The talk was helpful to me since I spent four years at Portland State hearing people talking about deep and shallow embeddings without knowing what that meant, and now I do. Deep embeddings are syntax-driven and shallow embeddings are semantics-driven (unless it's the opposite); in a shallow embedding, operations are functions in the host language and in a deep embedding, operations are types in the host language (ditto). It's a similar dichotomy to the expression problem. I wrote in my notes "Somehow you can turn context-sensitive interpretations into compositional ones (read the paper)". At that point, I was literally too tired to stand up, so I'm just pleased with myself for having remembered this much!

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.

During this year's ICFP, I took probably more notes than I've taken at any other conference I've gone to. Now some of my notes were silly ideas or random to-do items that would have distracted me if I didn't write them down, but a lot of them were actually about the talks I was listening to, surprisingly enough!

In the interest of posterity, as well as justifying to my employer why it was a good idea for them to pay $3000 for me to go to an academic conference when I'm not a researcher, I'm going to try to summarize those notes here. What follows is my attempt to turn my notes on the first day (September 1) into something half coherent. I'll do a separate post for each day. I will try to link to the video from each talk.

The first talk of the day that I caught was Daniel Schoepe talking about SELinq. Yes, this is LINQ as in LINQ. He (and his coauthors Daniel Hedin and Andrei Sabelfeld) wanted to build on top of what LINQ already does -- making database queries typed -- to annotate types with "public" or "private". This means, probably, exactly what you'd think it would mean in an everyday sort of database application: for example, they applied their work to an example from the PostgreSQL tutorial site and showed that they could implement a rule that in a database of people, demographic info, and addresses, each person's exact address is private -- so queries can get aggregate data about what regions people live in, but a query that tries to look up an individual's street address would be ill-typed. That's really cool!

Schoepe et al.'s work is based on FlowCaml, which is an information flow analysis for OCaml. Crucially, the work relies on embedding the database query language in the underlying programming language, so you can piggyback on the host language's type system. That's cute! It also relies on baking operations like list append into the language, which is a little sad. (In my never-published -- and never-finished -- dissertation proposal, I wanted to explore using a combination of proofs and types to modularize the primitive operations of a language. I wonder if an approach like that would be useful here.)

They proved a soundness theorem that guarantees non-interference, and implemented a source-to-source compiler that generates F# code. Their type inference is conservative, which doesn't violate any intuitions: that is, it's always safe to treat public data as private. In future work, they want to apply it to front-end JS web apps, and in the question and answer session, Schoepe said it shouldn't be hard to generalize the work to arbitrary lattices (not just the one with "public" and "private").

After lunch, Paul Stansifer talked about binding-safe programming. The take-away line from Paul's talk was "Roses are olfactorily equivalent under α-conversion." (This might make more sense if you keep in mind that the name of the system he implemented is "Romeo".) Everybody knows that naming is one of the hardest problems in computer science; Paul presented a type system for naming. This pleases me, since I think nothing makes sense unless it's formulated as a type system. In his system, types track binding information: specifically, in a way that allows names to be shadowed safely. The type keeps track of which "direction" shadowing should go in. The running example was expanding let* (because this is in a Lisp-ish context) into lambdas.

The next talk I took notes on was by Lars Bergstrom, on higher-order inlining. (Paul and Lars are both former colleagues of mine from Mozilla, by the way, which is why I'm referring to them by their first names.) Lars presented an analysis that determines where it's safe to inline higher-order functions. This was interesting to me since I'd always thought of inlining higher-order functions as a very naughty thing to do; the first research papers I ever read, in undergrad, were about inlining, and I did my undergrad and master's thesis work on deforestation (which depends intimately on it), so this is a belief I've held for a long time! Lars showed that it's wrong, so that was cool. The central contribution of his work is an analysis that doesn't have to compare the entire lexical environment for equality. I would have to read the paper to explain why, but Lars said that his work provides principles that replace the bag of heuristics that was the previous state of the art, and for now, I believe him.

It's safe to inline a higher-order function if you know that its environment doesn't change dynamically: that is, that inlining won't change the meaning of the function's free variables. Lars' analysis answers the question "does any control flow path pass through a sub-graph of the control flow graph that constitutes a re-binding?" An interesting thing that Lars didn't say (but perhaps it's not as deep as I think it is) is that this touches on how closures and value capture are sort of a hidden side effect even in a pure, strict functional program. His conclusion was "You can use closures in benchmarks now!"

In the Q&A, I asked whether it was imaginable to prove that the analysis improves performance, or at least doesn't make it worse -- in other words, that the higher-order inlining optimization has a predictable effect on performance. This question has haunted me ever since I worked on type-based deforestation. Lars thought this would be very ambitious because inlining is often an enabler of other optimizations, rather than improving performance on its own; though it does inherently eliminate stack frame allocation and deallocation. He said that he and colleagues want to do a correctness (i.e. semantic preservation) proof, but haven't yet.

My last set of notes for the day was on Jennifer Hackett's talk "Worker/Wrapper Makes It Faster". As Lars said in answer to my question, Jennifer's work answers the question I asked, sort of: it's about proving that optimization really does improve performance. She has a proof strategy based on defining a "precongruence": a relation that's preserved by substitution; this is because the "natural" approach to proving performance improvement, induction based on execution steps, doesn't work for lazy languages. If a relation is a precongruence, intuitively, a local improvement always translates into a global one. I would have to read the paper before I said any more, but I thought this talk was cool because it contributes the first performance guarantee for an optimization for a lazy language.

Stay tuned for my notes on day 2, once 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've achieved our $8192 goal!!!! But wait, there's more: we're increasing our goal for a second time and are trying to raise $10,000 by 5 PM Pacific time today. (If we raise $16,384, there will be filk singing.)

Thanks to those who donated between 6:00 PM September 18 and 12:15 PM September 19 and gave permission for their names to be used and/or tweeted about it on #lambda4ada:

Aaron Miller
André Arko
Andy Adams-Moran
Dan Licata
dorchard
Eni Mustafaraj
Eric Sipple
Glenn Willen
Justin Bailey
Ken Keiter
Kevin Scaldeferri
Kristy
lindsey
Lyn Turbak
M Wallace
Michael Greenberg
Peter Fogg
Rob Simmons
Ryan Wright
simrob

If your name is not on the list, you've donated, and you'd like it to be, send me an email (catamorphism at gmail).

A thought for today:

On Reddit, user green_mage asked:
"Why ask us to pay for something you don't want to talk about?"

This was in reference to what I said in my initial post:

"I would rather not talk about diversity, inclusion, feminism, gender, race, and sexuality with my colleagues. The difference between me and -- say, the young male graduate student who attended Wouter's Haskell Symposium talk and later tweeted something to the effect that Europe didn't have a good record when it came to distinguishing people based on race and gender -- isn't how interested we are in lambdas, type theory, theorem proving, compilers, or whatever happens to make our synapses light up. We both are. The difference is that I cannot do my job while ignoring the constant drone of small -- and occasionally big -- indignities and violations that make my friends who are also my colleagues sad and, sometimes, drive them out of the field altogether."

I don't want to fix bugs in code. I would much prefer it if my code worked the first time I wrote it, so I could focus on implementing new features. Wouldn't everybody?

I fix bugs anyway. Not just because I get paid to do that -- I'd still do it even if I became independently wealthy and decided to devote the rest of my days to open-source volunteering. The reason I fix bugs is that -- as anyone who's ever used a computer knows, not just programmers -- bugs in software detract from the pleasure and delight that using good software can bring. All the new features in the world don't do much good for someone using my code if it crashes when they try to save a file.

I try to fix bugs in culture for the same reason. That we exclude people who look different from ourselves from our professional cultures -- usually without meaning to -- is a bug in human behavior. We are taught to hold onto our power; that part of the value in who we are and what we do is excluding other people from it. (This is why most women were driven out of computing in the 1960s, when it began to be a professional and profitable occupation.) Exclusion and marginalization, deliberate or accidental, distract attention from the things that unite those of us who like to program in functional languages: beauty, elegance, the Curry-Howard isomorphism.

I don't want to fix bugs. But I do it because it's part of being a programmer. I don't want to do advocacy. But I do it because if I don't, I don't feel like I'm doing my job, either.

I hope this answers green_mage's question.

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:

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.)
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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

In my initial challenge post, I left the connection between functional programming and the Ada Initiative's mission a bit unclear. I suspected that most people who would already be inclined to listen would already understand what TAI has to do with helping bring more people into functional programming and use their talents fruitfully there.

But on the Haskell subreddit, where a Redditor by the name of LeCoqUser (in reference to the Coq proof assistant, of course) linked to my initial post, one person wrote: "I cannot fathom what this has to do with Haskell or functional programming..." I'm going to give this person the benefit of the doubt and assume they really meant, "What does this have to do with Haskell or functional programming?", and were simply applying a principle that many people like me -- who were socialized by Usenet -- learned: "If you want to know the answer to something, never just ask a question; make a false statement that's designed to get people to answer your real question by correcting you."

And it worked! Here's what I wrote on Reddit. My comment was specific to Haskell because it was on the Haskell subreddit (it's also the community I know the best), but I think what follows applies to all other functional programming language communities too.

Just to clarify why it's on-topic, I'd like to say a little bit more about what the Ada Initiative (TAI) does and how it helps the Haskell community:

As has been noted, TAI helps conferences and meetups develop codes of conduct. The ACM anti-harassment policy, which applies to ICFP and other conferences and workshops related to Haskell, is based on TAI's model code of conduct.
TAI leads anti-impostor-syndrome workshops for women who want to enter technology. As I tried to explain in my blog post, impostor syndrome is a structural barrier to getting involved in functional programming for many people who otherwise would be interested. Impostor syndrome disproportionally affects women. By helping fight impostor syndrome, one woman at a time, TAI is creating more potential members of the Haskell community.
TAI runs AdaCamp, which has a potentially life-changing effect as self-reported by many of the women who have participated -- in terms of building the confidence necessary to participate in tech as a career software developer and/or open-source volunteer. Again, this means more potential Haskell programmers -- there's no sense in losing half the potential audience before they even start.
TAI runs Ally Skills workshops, which help men who want to make their tech communities safer for women -- including, I like to think, most of the men reading this -- put their intent into action.

Hopefully that clarifies things, and I hope folks from Reddit will help us reach our new goal of ~~$8192~~ $10,000! Money talks, and the fact that we've already raised ~~$4320~~ ~~[edit: $5557]~~ [edit: $8678] from functional programmers in less than ~~a day [edit: two days]~~ [edit: three days] says to me that most of us recognize that TAI's work is both crucial, and not being done by any comparable organization.

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!

I'm happy to report that the community challenge has raised $4394 for the Ada Initiative as of this writing, passing the $4096 mark just five hours after the first blog post. Thanks to Adam, Clément, Ken, and everyone who has donated so far!

Since leaving our friends who were just getting ready for bed when the original blog post went live wouldn't be nice, we're increasing the goal to $8192. If we raised more than $4096 on the first day, can we raise a little less than that with three days to go? I think so!

[Edited to add: With 6 hours left, we've raised $8678 and are aiming for $10,000!]

But that's not all! We're adding a stretch goal: if we raise $16,384, then Adam, Clément, Ken, and I will record Ken's classic filk "There's No Type Class Like Show Type Class" and post the recording on YouTube (or another video sharing site of our choice), illustrated by some informative graphics explaining topics like "polymorphic recursion" that the song mentions. We are putting our mouths where your money is. Tell your friends! Tell your colleagues! Tell everyone who doesn't wish you any specific harm!

Remember: donate, then tweet:

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

I'd love to link to more blog posts from folks writing about why the Ada Initiative's work is needed, and why our conferences need strong and clearly advertised anti-harassment policies. Just drop me a line (full contact details in my original post).

Still no response (as of this writing) from

TheOfficialACM after 15 mentions -- maybe 15 more will do the trick?

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:

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!)
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!

Make Functional Programming Better by Supporting the Ada Initiative and Petitioning the ACM

Edited to add: we reached our initial $4096 goal in just 5 hours! Can you help us raise it to $8192 and double what we hoped to raise? Edited again to add: We've now exceeded our goal of $8192, six hours before the end of the challenge! Can you help us bring it up to $10,000?

Clément Delafargue, Adam Foltzer, Eric Merritt, Chung-chieh (Ken) Shan, and I are orchestrating a community challenge to both raise money for the Ada Initiative, and make computer science conferences (specifically, the many technical conferences that the ACM (Association for Computing Machinery) organizes) better. We are challenging anybody who identifies as a member of the functional programming community to do two things:

Donate to the Ada Initiative, a nonprofit organization that is working hard to make it broadly possible for women and people in a variety of other marginalized groups to work in technology.
Call on the ACM to consistently publicize their own anti-harassment policy for all its conferences. That is, I'm asking that those -- at least those of you who use Twitter -- tweet a statement like the following one (use your own words, just include the #lambda4ada hashtag and try to include the donation link):
I donated to @adainitiative b/c I want @TheOfficialACM events to announce their anti-harassment policy. https://supportada.org?campaign=lambda #lambda4ada

Our goal is to raise ~~$4096 $8192~~ $10,000 for the Ada Initiative by 5:00 PM Pacific time on Friday, September 19. If you use the URL https://supportada.org?campaign=lambda, your donation will count towards the functional programming community challenge and help us reach the ~~$4096 $8192~~$10,000 goal. I have personally matched the first $1024 of funds raised -- that is to say, I already donate $80 per month to TAI, so over a year, my contributions will add up to $960. On Tuesday, Sept. 16, I donated an additional $64 to round the amount up to $1024. I've spent the past couple years struggling to pay off student loans and medical bills despite being generously compensated for my work -- nevertheless, I support TAI every month because I see it as an investment in my continued ability to work. I hope that my example inspires those who have a bit more financial freedom than I do to donate accordingly.

If you are reading this and you have benefited from your involvement, past or present, with any part of the functional programming community, we need your support. It is up to you how much to give, but we ask that you consider how much you have gained -- materially, intellectually, socially, perhaps even spiritually -- from what you have learned from functional programming and from the people who love it. Particularly if you are currently making your livelihood in a way that would be impossible without the work of many people who have and are making functional programming languages great, consider giving an amount that is commensurate with the gift you have received from the community. If you need a suggested amount and are employed full-time in industry who is using functional programming or doing work that wouldn't be possible if not for the foundations laid by the FP community, $128 seems pretty reasonable to me -- and at that rate, we would just need a total of 32 people to donate in order to reach the goal. I think there are far more people than that who do FP for a living!

If anybody assumed that Clément, Adam, Eric, or Ken endorsed anything in the remainder of this blog post, that assumption would likely be wrong. In what follows, I am speaking only as myself and for myself. I am an employee of Heroku, a Salesforce company, but neither Heroku nor Salesforce endorses any of the following content either. Likewise, I don't necessarily agree with everything that Ken, Eric, Adam, or Clément might say in support of this challenge; we are all individuals who may disagree with each other about many things, but agree on our common goals of supporting the Ada Initiative and raising awareness about the ACM anti-harassment policy.

If you've already gone ahead and made a donation as well as tweeting your support under #lambda4ada, great! You can stop reading here. If you're not sure yet, though, please read further.

Why ICFP Is Fun... For Some

Young man, there's no need to feel down
I said young man, put that old journal down
And come publish at... I - C - F - P
It's fun to publish at... I - C - F - P
When your lambda is tight, and your theorems allright
You can come, on, down, and publish at... I - C - F - P
You know I'm talking 'bout... I - C - F - P
There's a place you can go, and lots of friends that you know, at the I, C, F, P.

-- Nathan Whitehead, paying homage to The Village People

ICFP, functional programmers' annual "family reunion" (to borrow a phrase from one of the organizer's of this year's ICFP, which took place two weeks ago) feels to me like more than just an academic conference. The lone academic publication that I can claim (second) authorship for appeared in ICFP, but it's more than just the opportunity to hear about new results or share my own that keeps me coming back. Maybe that has something to do with the affiliated annual programming contest, or the copious number of co-located workshops revolving around different language communities, or maybe it's just about folks who know how to keep the "fun" in functional programming. It's a serious academic conference that occasionally features cosplay and [PDF link] once had an accepted paper that was written in the form of a theatrical play.

( Putting The Fun Back in Functional Programming and How the Ada Initiative Is Helping Us Do It )

"Every gun that is made, every warship launched, every rocket fired signifies, in the final sense, a theft from those who hunger and are not fed, those who are cold and are not clothed. This world in arms is not spending money alone. It is spending the sweat of its laborers, the genius of its scientists, the hopes of its children. The cost of one modern heavy bomber is this: a modern brick school in more than 30 cities. It is two electric power plants, each serving a town of 60,000 population. It is two fine, fully equipped hospitals. It is some 50 miles of concrete highway. We pay for a single fighter plane with a half million bushels of wheat. We pay for a single destroyer with new homes that could have housed more than 8,000 people. This, I repeat, is the best way of life to be found on the road the world has been taking. This is not a way of life at all, in any true sense. Under the cloud of threatening war, it is humanity hanging from a cross of iron."

-- Dwight D. Eisenhower, 1953

"We all travel together as passengers on a little spaceship, dependent on its vulnerable reserves of air and soil; all committed for our safety to its security and peace; preserved from annihilation only by the care, the work, and -- I will say -- the love we give our fragile craft. We cannot maintain it half fortunate, half miserable; half confident and half despairing; half slaves to the ancient enemies of mankind and half free in a liberation of resources undreamed of until this day. No craft, no crew can travel safely with such vast contradictions. On their resolution depends the survival of us all."

— Adlai Stevenson, 1965

"Listen to the voice of the soldier
Down in the killing zone
Talking about the cost of living
And the price of bringing him home

They're already shipping the body bags
Down by the Rio Grande
But you can fight for democracy at home
And not in some foreign land

And the fate of the great United States
Is entwined in the fate of us all
And the incident at Tschernobyl proves
The world we live in is very small

And the cities of Europe have burned before
And they may yet burn again
And if they do I hope you understand
That Washington will burn with them
Omaha will burn with them
Los Alamos will burn with them"

-- Billy Bragg, 1986

"Billy Bragg/ Help Save The Youth Of America." (Watch on YouTube)

Or: Lessons I Learned From Years Of Flouting Them
Or: Don't Do What I Did

The following is a list of tips derived from what I think has helped me enjoy computer science conferences more (and possibly learn more from them) as time has passed. I don't assume that they will be helpful to anybody else, but perhaps they're worth thinking about! I expect this list will be the most useful for grad students starting out, and other people who haven't gone to conferences before. If you are more experienced, you can always tell me why I'm wrong or whatever.

1. Pace yourself.

Skip talks. No, really. Going to every talk should not be your goal. Most people can't go to every talk and understand everything. (Don't even expect to understand everything in any one talk.)

Try to highlight talks you especially want to go to in the program in advance. You can do this during the first coffee break or during the first talk when you get there halfway through; it's okay :) Be open to adding or dropping talks (adding can be if someone tells you "hey, X's talk is going to be good" or if you happen to see the beginning and are drawn in; dropping can be if you feel tired, want to get some exercise, or get into a good conversation with somebody). I promise you that even if your school or employer is paying, nobody is going to exhaustively quiz you on the contents of every talk when you get home.

2. Pace around.

If it's possible -- not too rude and disruptive given the room layout, and physically possible for you -- try pacing around while you're listening to talks. At ICFP this year, the room had a big space in the back without chairs, which some people used for standing, lying down, doing yoga, and other such things. I don't know if this was intentional, but it worked well. Sitting in the same position all day is not good for most bodies. Don't be afraid to move, stretch, or even sit on the floor or lie down while listening to talks. If you're me (and possibly even if you're not me), this will help you listen better. Just because most people are sitting (too close together, on chairs that are probably uncomfortable) doesn't mean you have to.

Another advantage of standing is that it discourages you from opening your laptop, if that's a compulsion for you.

3. Take notes.

Not everybody focuses better while taking notes, but I certainly do; if my hand isn't moving, my mind checks out. But taking notes does more harm than good unless you do it effectively. it took me years to learn that note-taking isn't about writing down what the speaker says in complete sentences. If you hear something that makes you think, "That's interesting! I wonder...", write it down. If you hear something you want to read more about, write it down. Notes can be illegible to anyone else (so long as you can read them later!), in incomplete sentences, structured as bullet lists, etc. Nobody else gets to see your notes unless you let them.

Sometimes notes are write-only, and that's totally okay. You might never look at them again, but the act of writing will still have helped you remember what you learned.

4. If you don't understand, assume that it's not your fault.

This doesn't mean getting aggro at the speaker because they were unclear. It does mean not bearing all of the blame for every single talk you don't follow. It also means asking questions (sometimes) without thinking it will expose your horrible ignorance. Chances are, if you have a question in mind, ten other people do and won't want to say it. If you ask, you'll be helping all of them.

It's possible that it is your fault, but more often, somebody just didn't put in the time/didn't do practice talks/other things to improve talk quality. At least at the conferences I go to, papers are selected solely based on the quality of the ideas and writing, not the talk (since when the authors submit the paper, they haven't prepared the talk yet!) Someone can write a great paper with a great ideas, but still have no idea how to organize slides visually or structure a talk. The academic system affords very few incentives to learn how to do that, other than an individual's intrinsic motivation and/or peer pressure.

5. If you can't pay attention to the content, critique style -- INSIDE YOUR HEAD.

I mean, it's educational for you to think about what methods do and don't work for slides ("wow, that hot pink background with white text is hard to read..." "wow, I don't like Comic Sans and only SPJ gets a pass"), but just to be clear, nobody else (especially not the speaker) wants to hear your bikeshedding. That said, I find this is a way for me to actually get more out of the talk content, because if I'm noticing how I could have done the talk better from a purely visual POV, I'm not thinking about how much of a doof I am for not understanding the content.

6. If possible, stay physically nearby.

At least at the conferences I go to, the conference is usually at a hotel, and you can also stay at the hotel, though the hotel the conference is in is usually outrageously expensive (not an issue if your research grant or company gives you an unlimited budget, but for grad students, faculty at small schools, and unaffiliated people, that can be a problem). That means you can theoretically travel to an exciting, cosmpolitan city for a conference, and never leave the hotel except to go back and forth to the airport (if you're willing to eat hotel restaurant food). The drawback is that there are usually much cheaper options, but generally a significant distance from the conference. It's up to you to set your own budget priorities, but even though I wish they weren't so exorbitantly priced, there really are advantages to staying in the same hotel as the conference. This is true even in European cities where you can walk or take an easy light rail ride everywhere -- the time it takes will add up, and you're spending enough time attending, going to dinner, and staying out late shooting the breeze that every minute counts (and sleep is crucial to everything else working out).

Staying at the hotel also makes it easier to show up on time for the first talk in the morning, which saves you guilt about missing it (especially if the conference puts invited talks first, which is cruel and unusual punishment if you ask me -- signalling that a talk is expected to be especially good by scheduling it at a time when it's difficult for many of us to be awake). It also makes it a snap to go back to your room for a nap, break, or just some alone time when you need it.

7. Know your limits.

I don't mean alcohol so much as people and new information. It's okay to tell yourself that your brain is full and go take a break. (Taking notes makes this easier, since you know you'll be able to resume easily.) This is true whether you're an introvert, extrovert, or the (probably-majority of us) who don't fit neatly into one of those categories. The limits may vary wildly for different people, but almost everyone has them. When you hit your limit, you'll know.

8. Ask questions.

Many conferences have a few people who seem to dominate the Q&A sessions for almost every talk. Session chairs usually know this, and some will try to call on less familiar faces. But for that to work, people have to step up. So every question you ask -- as an outsider, newcomer, or whatever -- means that many more fresh perspectives that the whole conference gets to hear.

Often, not everybody gets to talk in a given Q&A session, but it's okay and encouraged to approach a speaker later and say you liked their talk and are wondering about ____. This is also totally okay if you're just too intimidated to ask a question in front of a large group. Personally, when I've given talks and no one has said a word to me about it later -- or if all anyone says is the equivalent of "great talk!" -- I worry.

9. Know how talks get selected.

At least at the academic conferences I go to, program committees don't select talks based on presentation quality, because they don't get to see the talks first or figure out how good a speaker the presenter is (in fact, often they don't know who will speak, because papers usually have multiple authors and only one will give the talk.) They select talks based on their assessment of the quality of the papers that go with them. Selection also isn't an objective process; political, messy, human one (just ask anyone who's been on a PC). Inclusion in a given conference, even a conference with a good reputation, doesn't imply lasting value. Rejection doesn't imply absence of value.

I'm saying this to encourage you to go easy on yourself if you miss talks or don't get much out of one or many talks. It doesn't necessarily mean that you had a great opportunity to learn something, and you (and only you) squandered it. When choosing talks to go to -- or choosing how hard to listen! -- trust your own judgment and don't assume everything is a pearl of wisdom.

10. Know that sometimes a great idea is buried in a bad talk.

Even if a talk leaves you reeling and not in a good way, maybe it just means you should read the paper. Different people learn differently, but for many of us, it's easier to understand something when we can go back and read the same sentence six times before continuing. You can achieve something similar by re-watching the video (if you're at a conference that records talks) later, which also has the advantage that you can rewind parts you want to listen to again and fast-forward through parts you don't. All of this only applies if the idea actually interests you. There's no obligation. In my experience, the most common scenario is a terrible talk based on an alternately lucid and confusing paper about a cool idea.

The following question was posted on a closed support group that I read on Facebook:
I'm applying for residency to become a family medicine doc. Chronic pain and illness is a huge part of taking care of patients, and I want to know your opinion on your healthcare experience. What did you like/dislike/need/receive/not receive from the healthcare field. What is a small thing that would have made a big difference? How can I become a great doctor for my patients? How can I teach others/emulate behaviors for others to become better doctors? Thank you!

I'm copying my reply here to save it for posterity:

I would love it if more doctors understood Health at Every Size (HAES) - specifically, the role of weight stigma, largely inflicted by the medical profession, as a barrier to health care and cause of stress-induced illness and shorter lives for many fat people. It would be great if they understood it comprehensively, but even if they just understood that there is no evidence that intentional weight loss improves health outcomes, that would be great.

Understanding that trans people are biologically the sex that we affirm ourselves to be would be great.

Understanding that the boundary between physical and mental illness is political, not scientific, would be great, as well as the role of abuse culture manifested through childhood trauma in causing both, and how widespread PTSD and CPTSD really are.

If you haven't, read everything by Paul Farmer that you can (especially _Infections and Inequalities_ and _Pathologies of Power_.)

Finally, I wish more doctors would treat a patient who does their own research on their own condition the way they'd treat a student they were mentoring, rather than shaming such patients for 'going on the Internet'.

If you have anything else to add, I'll try to pass it on to the person who asked, as best I can!

I wrote this as a comment on a friends-only LiveJournal post, so I'm reproducing it here.

"I figure that since my employer doesn't monitor how I spend my paychecks to make sure I don't spend it on booze, drugs, porn, etc. but rather only on nutritious food and sensible clothing, I am going to give to people on the street, and in fact I am going to assume giving to people on the street does more good than giving it to white people with good salaries who decide which people on the street are deserving (which is more or less what [REDACTED] said, I'm just agreeing with her).

Since I believe that I am rather good at figuring out how to spend money on things I want and need if someone just gives it to me, I'm not going to condescend to poorer people and assume they're not as good at it. (In fact, they're probably better at it, having managed to survive this long.)"

I'd add to this that I see an analogy: donating money to disease-specific charities (especially for diseases whose cures are open-ended research problems and that tend to affect people who are privileged enough not to die young of an infectious disease) : supporting global public health efforts :: donating money to white people with good salaries who will then decide how to allocate it among the poor (after taking their own cut) : giving money on the street to people who ask for it.

That said, I won't usually give on the street when I'm with other people, since in my experience that leads to pressure on the other people to give too, and I guess I put my friends' comfort first... which may not be the right set of priorities. I also don't give every time I'm asked, but I would like to give more often. My reflex (trained into me through years and years of living in cities and being influenced by people who were anti-giving) is just to say "no". And truthfully, I read this one _Babysitters' Club_ book when I was six or so where one of the characters opens up her wallet to give money to a panhandler and the more street-wise character scolds her with "he's just trying to get you to take out your wallet so he can steal it", which left its imprint on me (the bad thing, of course, wouldn't be losing my wallet, but shamefully being "gullible" which is obviously the worst thing you can be). Anyway, I'm trying to train myself out of those reactions.

( Have you been everywhere? A poll! )

In 2004, I attended ICFP in Snowbird, Utah. At the time, Paul Graham was on the schedule to give an invited talk entitled "Don't make the wrong mistakes: programming as debugging".

That might have been an interesting talk. The talk Graham actually gave was "storytime with Grandpa about the dot-com bubble" (which was all of three years ago, at the time.) I don't remember much about the talk, which was quite inane. I do remember the quotes I wrote down on LiveJournal at the time, which I approved of (shamefully... but it was ten years ago):

"It's no coincidence that I'm dressed like this... it's to make an important point. The coincidence is that I'm always dressed like this." -- PG
"Nerds dress informally as a prophylactic against stupidity." -- PG
"If you go to Google and search for 'nerd', I'm what you get." -- PG
"If your code miscalculates the path of a space probe, you can't dodge your way out of it by saying that your code is patriotic." -- PG

There is a liberally rewritten transcript of his talk on his web site. It still has nothing to do with the abstract he submitted to ICFP for his talk. (Full text for all you non-ACM-members out there. I'm pretty sure it's short enough to qualify as fair use.)

Anyway, what's not in the liberally rewritten transcript was the bit where, in the Q&A session afterward, someone asked him his opinion of outsourcing. And Graham said -- I'm paraphrasing -- that he thought outsourcing would be a self-limiting trend, because, "You can send things to India all you want, but eventually you realize you have to hire real programmers."

This is notable because while racism is thoroughly shot through Silicon Valley, it's rarely stated that overtly, that unashamedly, and by someone with some degree of social capital.

In any case, I guess Graham was namesearching on a Friday night, since out of nowhere, he replied to a tweet of mine that was about something else, giving me the occasion to post the tweet that is the pinnacle of my career.

Achievement unlocked: being told by Paul Graham that I should be ashamed of myself.

So far, the responses to my article "Killing the Messenger at Mozilla" on Model View Culture have been almost completely positive. (That's almost a bit disappointing, because if no one gets shirty about it, then I worry that I haven't done my job.)

But there's one response that may superficially seem compelling. I thought about addressing it in the article, but ended up leaving it out for space reasons and because I felt like I, and others, had talked about it over and over, and that at this point, if someone is still using this argument, they are simply not listening. I'm an eternal optimist, though, so I want to summarize my thoughts on it one more time. The tl;dr version is that concern over "forcing the resignations of CEOs over political donations" is a red herring. The concern is not really about political donations, but about forcing the resignations of CEOs over the kinds of political donations that white heterosexual cis men tend to make -- thus, the concern is really about excluding people in that narrow social clique of folks who have always taken for granted that they will be included in any space they want to be in.

Who pays for free speech?

A representative example of the argument is:

"...but I remain unconvinced that we really want to force the resignations of CEOs over political donations." -- Jason Pontin

(I'm picking this tweet for concreteness, not out of a desire to portray Pontin's specific comment as uniquely heinous.)

It makes me viscerally angry that this is still a tenable response to critiquing putting bigots in charge of public interest organizations. I think it makes me so angry because it's so disingenuous. Literally nobody believes that there is never an occasion when a CEO could make a political donation that is incompatible with the mission of their company or organization. The debate is about which donations are acceptable, and it frustrates me to no end that folks make such an absolutist, obviously shallow argument to avoid confronting the real issue.

The hidden assumption is that public spaces belong to heterosexual men. Everyone else dwells in public spaces at the pleasure of heterosexual men. Therefore, to exclude a heterosexual man from such a space -- especially from a leadership position! -- requires far more basis than excluding anybody else.

I want to be absolutely clear that I don't think this response is quite the same response as the even shallower (but still popular) "Everybody has the right to do and say whatever they want and keep their jobs, because free speech." This response has been addressed exhaustively (see Valerie Aurora's "What Free Speech Really Means" for just one example), far beyond what the time and effort it deserves.

The question "do we really want to drive someone out because of a different opinion?" is different because rather than appealing to shady constructions of individual rights, it raises a question about the public good. Latent in the question is the liberal (with a small 'l') notion that diversity of ideas is always a good thing. Subscribers to this, the liberal viewpoint, say that if we merely include people with a variety of ideas and opinions in our community, the best outcome will naturally happen rather than if we made any intentional effort to actually make a variety of people feel safe in that community.

Donations, by the way, are definitely speech. A political donation is political speech, and as such, is necessarily public. Don't trust me on that one -- just ask the Supreme Court. Donating money is absolutely a form of speech, and as such, should be assessed in the same way as other kinds of public speech would be.

But what about the "public" part? There is a very good reason why political donations are public. It's not, as some have suggested, a procedural accident that means Eich's donation record should be politely ignored. The privilege of privately donating money to influence the political process and thereby affect the public is inseparable from corruption. Put another way, if you are going to interfere with my life, you don't get to keep your own identity a secret from me while doing so -- if you want privacy, you always have the option of not interfering with my life. Given that I can't opt out of a law preventing me from marrying, it's only fair that the people who underwrote that law can't opt out of me knowing who they are.

While it's a bit more sophisticated than "but free speech?", "do we really want to drive someone out because of a different opinion?" is still the wrong question. I think a better question is, "Is a man who paid money to run advertisements insinuating that dozens of his employees rape children, not because they have actually done so but because they have queer relationships with adults, someone who is well-equipped to carry out the mission of his company?" Details matter.

Not only is it the wrong question, it implies a false equivalence. The subtext here (made much more explicit by various voices online) is that anti-queer bullying -- including bullying backed up with the full power of the state, such as the ultimately-unsuccessful effort to make Proposition 8 law in California -- is exactly the same thing as fighting back against that bullying. "You're just as bad as they are!", say these voices, shaming queer folks with the suggestion that we deserve no empathy, compassion or tolerance because our defiance of oppression makes us exactly like our oppressors.

Not only is it the wrong question, it's misleading, and it's hard to believe that it's not deliberately misleading. While Pontin's question explicitly refers only to donations rather than opinions or beliefs, it's hard to understand it except via an appeal to (once again) the liberal notion of diversity of ideas and tolerance for all ideas (including ideas that would, if broadly adopted, destroy liberalism). Without some belief in the inherent value of diversity of opinion, it would be hard to understand why someone shouldn't be held to account for their political donations. The statement "but I remain unconvinced that we really want to force the resignations of CEOs over their actions" would plainly be absurd. And there is no special reason to grant immunity to the act of paying other people to do things, other than (perhaps) desire to give rich people an additional way to do wrong without accountability. If there was, contract killing would be less harshly punished than any other form of murder. We're talking about actions, not ideas.

People keep talking about how Brendan Eich shouldn't have been held accountable for his views about "homosexuals", or his views about "traditional marriage", in one breath, and in the next breath about how his donation doesn't reveal anything about his views about "homosexuals" or marriage. You can't have it both ways. In point of fact, I agree with Eich's defenders about one thing: we don't know anything about Eich's views on queer people, marriage, or anything else pertaining to Proposition 8. We only know about his actions, which can and should be judged in their own right. If the conversation we're having was about Eich's "private" beliefs, we wouldn't be having it, because we wouldn't know anything about those beliefs! That's the definition of "private", after all.

If we take it as a given that the conversation is about actions rather than beliefs, the question remains of how to evaluate Eich's actions. Here are some concrete effects that the campaign for Proposition 8 had:

It caused more people to think that queer people are more likely to abuse children than heterosexuals are (actually, the opposite is true), and/or strengthened their existing misconceptions to that effect.
It provided further moral legitimacy to those who terrorize queer youth (and queer adults) with physical and verbal violence.
It contributed to the levels of fear and stress experienced by queer people, especially young queer people. The copious deleterious physical and emotional effects of chronic stress are well-documented.
It incited kids and teenagers to bully their peers whose parents are queer.

Here are some concrete effects that the campaign did not have:

It did not strengthen marriages between heterosexual men and heterosexual women. (As far as I know, the divorce rates are still where they were before.)
It did not result in the passage of the legislation it purported to pass.

The second point is worth dwelling on. Proposition 8 proposed an unconstitutional law. There was nothing particularly subtle about this. In his Perry v. Brown decision, Judge Vaughn Walker noted the absolute vacuity of all the arguments that were presented in favor of the proposition's constitutionality. If the case was Prop. 8 supporters' best effort to show that the state of California had a compelling interest in regulating intimate relationships, they failed spectacularly. It's hard to imagine that they didn't see that coming. I'm sure many people who voted for and financially supported Prop. 8 believed it would be feasible to make it the law of the land, but I think the folks who campaigned hardest for it were probably bright enough to realize it was doomed. It's hard to imagine that in their minds, the expected value of sneaking an unconstitutional law through the legislative process exceeded the expected value of conducting a smear campaign against members of gender, romantic, and sexual minorities.

It frustrates me that the folks saying things like what Pontin said refuse to own up to what the vague language of "political donations" actually refers to here: violence. This is not hyperbole -- according to the World Health Organization, violence is

"the intentional use of physical force or power, threatened or actual, against oneself, another person, or against a group or community, that either results in or has a high likelihood of resulting in injury, death, psychological harm, maldevelopment, or deprivation." -- WHO Violence Prevention Alliance

As per the WHO's typology of violence, political donations like the ones made in support of Prop. 8 fall under the category of "collective violence": "violence committed by larger groups of individuals and can be subdivided into social, political and economic violence."

Let's try rephrasing that comment yet again:

"...but I remain unconvinced that we really want to force the resignations of CEOs over violence."

I'm not going to say that no one would sincerely make this statement -- after all, many people leapt to the defense of Scott Kveton, who was (at most) obliged to take a leap of absence. But it's harder to defend than the initial formulation. If you want to argue about whether or not it's really violence to fund a propaganda campaign aimed at encouraging scapegoating of a vulnerable minority group, I guess you can. It would at least beat disingenuously claiming that everybody should find any political activity their supervisor undertakes to be acceptable.

I do think it's difficult for some people to understand the difference between "differences of opinion" and violence aimed at a vulnerable minority group. If you have ever been in a vulnerable minority group, you know the difference. I've been over this before in "A Problem With Equality".

What if I want something that hasn't got spam in it?

As I also wrote about in "A Problem With Equality", some points of view have the effect of dominating discourse and making it hard or impossible for other points of view to flourish.

An analogy is weeding a garden: even people who love plants need to get rid of plants that use a disproportionate share of space. While there's nothing wrong with letting your front yard grow wild (so long as you aren't subject to an HOA's rules, anyway), you will probably have fewer different species of plants as a result than you would if you pulled weeds and made a deliberate effort to plant many different kinds of flowers. Likewise, people responsible for parks and open spaces make an effort to reduce or eliminate the share of resources taken up by invasive species. This isn't because they want less diversity of plant species -- it's because they want more diversity of plant species.

Ideas are like that too. If you believe that all opinions are worth listening to, I suggest that you try turning off your email program's spam filter for a week and see if you can still conduct your professional and personal life. In truth, no one believes that all opinions are equally desirable. If this was really a widely accepted truth, your city or town hall would be covered in Lyndon LaRouche flyers, you wouldn't be able to attend a conferences without someone standing up during the question and answer period to talk about chemtrails, and you would say "yes" whenever a street canvasser asks whether you have a moment to spare for the environment. The world would be a very different place. It's not just that everyone has their own set of preferences for which opinions they listen to, tolerate, or detest. It's also that everybody recognizes that the presence of some kinds of speech makes the metaphorical garden of ideas less diverse, not more, just as invasive plants make literal gardens less diverse. It's why we have spam filters, the do-not-call list, and "No Soliciting" signs. If we didn't have these things, we wouldn't have any time to develop our own ideas -- we'd be too busy listening to people trying to sell us something.

Given that the supposed goal of anti-queer activism is to make everybody heterosexual, I think the analogy with invasive species is apt. At least Scotch broom doesn't try to turn other plants into Scotch broom besides just taking away their room to grow! Really, though, I think most anti-queer activists probably know that other people's sexuality is non-negotiable, and merely seek to make queer people's lives as difficult as possible.

It's hard to grow and thrive when people around you are telling you that you should change fundamental aspects of your self or that you don't belong in your community because of those fundamental traits. It's especially difficult when those people are your managers or the heads of your company. Given the choice, you might just choose to go to a company where your managers and executives won't say those things. If they're not telling you those things directly, merely making it a matter of public record that they want your life to be harder than it is, that's not necessarily any easier to tolerate. Even if bigotry-underwriting CEOs are always nice to you to your face, never treat you in a way that's obviously unfair, their presence corrodes your ability to trust the fairness of your organization's decision-making processes. In an environment of fairness, you can be sure that if your manager criticizes your performance, it's because they think you need to work on improving something. When your leaders' support for bigotry is on the public record, it's impossible to be free from the nagging question of whether it's really about your work, or the fact that somebody up there wishes you didn't exist.

Different goals, not different tactics

Returning to Pontin's words, "...we really want to..." raises the question of who "we" are and what we want. Perhaps he and I just want different things.

I want to encourage diversity of opinion, and tactically, I would advise anyone else who wants the same thing to make a specific effort to include points of view that usually get marginalized. The points of view that enjoy majority endorsement will take care of themselves. Of course, other people might not want what I want. But I don't think it's so controversial that all other things being equal, a public organization should strive to encourage diversity of opinion within their ranks -- indeed, this is exactly what many of Eich's defenders have said.

So if we assume for the sake of argument that we all want to encourage diversity of opinion, how are we to go about doing so -- concretely, in the organizations where we work or volunteer? One approach is the laissez-faire method: just let it all hang out. But if you've ever attended a meeting without a moderator, you know that approach doesn't work. The people who can yell the loudest will get heard, leaving everybody else to fight just to get a word in.

Another approach is to maintain a social contract that explicitly calls out inclusion. It's best when such a contract is explicit rather than implicit, because it's not fair to expect people to follow rules they don't know about. I think this is a better approach than the laissez-faire approach, because having explicit policies makes it possible for everyone to be heard, not just those who can yell the loudest and longest. Part of such a social contract can be the expectation that people will refrain from public speech that has a chilling effect on the free speech of others -- particularly on the speech of those who are most vulnerable to oppression, since protecting the free speech of people who are politically powerful is superfluous. Sometimes these contracts are called codes of conduct.

Another thing that's very frustrating about the "do we really want to drive out a person for? ..." approach is that it mistakes a difference of opinion about goals for a difference of opinion about tactics. I don't think someone asking this question has the same goals as I do. I can only conclude that they have the goal of making corporations safe places for people who have any opinions that a white heterosexual man would be likely to have, while I have the goal of making them safe places for everybody who is willing to work respectfully with others. It's easy for other heterosexual men to defend Eich because they can imagine themselves being in his shoes, but can't imagine what it's like to be a queer person in a heterosexual world. I realize that it's easier for someone who looks a lot like Eich to imagine no longer being welcome in their job because the world has made progress that they haven't caught up with than it is for them to imagine dealing with the daily microaggressions that come with being part of a minority group. But it's still frustrating for me that they refuse to even try to take another point of view, given how much time I have to spend taking their point of view just so I can survive.

False equivalences

"It's important to be able to work with people who you disagree with." I can't count the number of times this has been said about the Eich crisis, and it's closely related to the idea that we don't really want to force the resignations of CEOs over political donations. It's smarmy, condescending, and erases power imbalances.

It is condescending to tell me I need to be able to work with people I disagree with when if I refused to work with people I disagree with, I would immediately be unemployed and, shortly afterward, bankrupt. Working with people we disagree with is a necessary survival skill for those of us whose basic humanity is still up for debate. Not only do we have to work with people we disagree with -- we have to work with people who disagree with us about whether we're people, about whether we're capable of telling the truth about our own subjective experiences. The smarmy folks talking down to us about how we need to be able to tolerate differences will never have to experience that.

It also erases power imbalances to implore us to "work with people [we] disagree with" -- the recasting of structural violence as "disagreement" implies falsely that a queer person who says "no, really, I'm telling the truth when I say I love my partner just as much as you love your spouse" to a heterosexual person has equal power -- is accorded as much respect and credence -- as a heterosexual person who says "gay people's relationships are just about sex, not love". There is a difference between supervising employees who vote Democratic when you vote Republican, and having a boss who (or knowing that someone at the top of your reporting chain) has taken specific action to take away your civil rights.

It is not just outright speech or actions towards the goal of eliminating queer people that hurts us (and when I say "us", I mean everybody, because an environment that tolerates eliminating a group of people because of a non-negotiable trait diminishes everybody's dignity). For many of us, it's insulting as heck when people claim to agree with us, but nonetheless go to the mat for the conviction that whether or not queer people are people should be subject to debate, should be hashed out in the free marketplace if ideas. It is hurtful when someone who claims to be my ally is more interested in fostering open dialogue about the pros and cons of accepting that I'm human than they are in showing solidarity with me.

To say that 'queers are subhuman' is a valuable perspective that improves a community is, itself, an act of rhetorical violence against queer people.

Ethical Culture Fit?

The last reason why I think it's disingenuous to treat "forcing someone to resign over political donations" as an outrage is that in Silicon Valley, people literally get fired (and I mean fired, not voluntarily resigning in order to cease hurting your organization, despite being implored by the organization's other leaders to stay on) -- or constructively dismissed, or rejected for jobs -- for having "different views" ALL THE TIME. This phenomenon is usually called "culture fit". In principle, there's nothing wrong with it, except that a very narrow culture tends to dominate and it's hard for the majority who don't fit with that culture to be in tech.

But if there's nothing wrong with "culture fit" hiring, there's certainly nothing wrong with a person recognizing that his views make him a poor fit with a culture that has changed while he has not, and voluntarily exiting. While I don't think that's exactly what happened with Eich leaving Mozilla, in principle, if an organization has a culture that supports queer people's freedom to be who they are, there is nothing wrong with declining to select leaders who oppose that freedom. At least, if you think there is something wrong with it, you should probably also criticize companies where if you aren't a bearded white guy who wears T-shirts and jeans and likes to drink with your colleagues after work, you will be ostracized to the point where it hurts your performance.

The near-universal acceptance of "culture fit" as a valid gatekeeping mechanism makes it clear that "no one should be pushed out for their opinions", or whatever, is disingenuous. They're not objecting to people getting pushed out for their opinions. They're objecting to people like themselves getting pushed out for their opinions, or perhaps to people getting pushed out for opinions they can imagine themselves holding. More so, they're protesting the fact that they no longer have exclusive control of the discourse -- that somebody other than themselves is now involved in deciding which opinions are acceptable. Most of the time, when you see someone calling for tolerance or acceptance who already enjoys a great deal of tolerance and acceptance, what they're really asking you to do is tolerate their domination of you.

Postscript

Some of the same people who wrung their hands about "people being driven out for having different opinions" when Eich resigned are approaching maximum beardhurt because Steve Klabnik is both a contract technical writer for Mozilla, and a critic of capitalism. To which I say: good.

Tim's journal

tl;dr since 1995

Haskell Symposium (day 2) and Erlang Workshop notes, 2014

(no subject)

ICFP 2014 Notes, Day 3

ICFP 2014 Notes, Day 2

ICFP 2014 Notes, Day 1

WE DID IT!

Thanks (day 4); I Don't Want to Fix Bugs

Thanks (day 3) and twelve things you can do besides giving money

"What does the Ada Initiative have to do with functional programming, anyway?"

Functional Programming Community Challenge, day 2! Thanks to the first round of donors.

Functional Programming Community Challenge: Let's raise another $4096!

Guest post from Adam Foltzer: Our Challenge

Our Challenge

Functional Programmers Support the Ada Initiative

Make Functional Programming Better by Supporting the Ada Initiative and Petitioning the ACM

Why ICFP Is Fun... For Some

Chance of peace

How To Conference, by Tim aged 33 2/3

Things you wish primary care doctors would know

Giving money

It's been too long since I did one of these

Achievement unlocked

Ethical Culture Fit

Who pays for free speech?

What if I want something that hasn't got spam in it?

Different goals, not different tactics

False equivalences

Ethical Culture Fit?

Postscript

Profile

January 2015

Links

Syndicate

Most Popular Tags

Page Summary

Active Entries

Style Credit

Expand Cut Tags