tim: Tim with short hair, smiling, wearing a black jacket over a white T-shirt (Default)
2030-12-18 02:14 pm

How to post comments if you don't have a Dreamwidth account

I request that you read my comment policy before commenting, especially if you don't know me offline.

If you have a LiveJournal account and want to leave comments on my journal, you can do that without giving Dreamwidth a password or any personal information except an email address. You can follow these instructions (with slight modifications) if you have an account on a site that provides OpenID credentials, too. (For example, any Google or Google+ account should work this way.) Here's how:

  1. Go to the main Dreamwidth page
  2. Follow the "Log In with OpenID" link
  3. In the "Your OpenID URL" box, put yourusername.livejournal.com. For example, if I wanted to log in with my LiveJournal account, I would type "catamorphism.livejournal.com".
  4. Click Login.
  5. Click "Yes, just this time" or "Yes, always" when LiveJournal asks if you want to validate your identity.
  6. The first time you log in, you'll see a message "Please set and confirm your email address". Click the "set" link and follow the instructions.
  7. You'll get an email from Dreamwidth containing a link. Follow the link to confirm your email address.
  8. Follow the instructions. You should now be able to leave comments.

Edited to add as of February 26, 2013: There have been intermittent problems with using OpenID to log in to Dreamwidth. The most reliable way to comment is to create a Dreamwidth account, which is free.
tim: text: "I'm not offended, I'm defiant" (defiant)
2014-11-18 11:16 am
Entry tags:

Required reading about Trans Day of Remembrance

I linked to some of these posts in 2013 and in 2012. It bears repeating.

Alyssa Caparas (2011):

I hate what TDoR has come to represent: a queer ‘holiday’ for embracing the narrative of fear; fear of violence, fear of death, self-stigmatization. The co-opting of POC trans women of a very-particular-background’s experiences as those of the ENTIRE trans community, regardless of race, class, or whatever. It’s a day to remind us all why we need to be afraid all the time and I think it’s a bunch of bullshit.

The large majority of people on the lists of the dead are NOT middle class white transwomen or men. They’re lower class PoC & PoC sex workers. I find it incredibly dissrespectful when white, middle, & upper middle class transpeople claim the narratives of transwomen of color & sex workers experiencess as their own. I’m sick of seeing Transbros at TDoR co-opting the narrative of transwomen’s experiences, internalizing them, and feeding those narratives back to everyone, then high-fiving each over how radical & edgey they are. I’m sick of being a Transwoman at TDoR and feeling marginalized by all the gender hipsters who’re there to bump up their scene cred.
(emphasis author's)

erica, ascendant (2012):

because trans identity is so caught up in Caucasianness, a new problem emerges with both the claiming of dead trans people of color altogether: if we weren’t “trans enough” in life, why are we suddenly being counted by the same people who wouldn’t have us once we’re dead? it’s because the idea that it’s dangerous to be trans has to be sold somehow, given that cis people generally ignore violence against trans people regardless of what color we are, and i do have no doubt that it seems like a good idea to use all these names. the trouble is that when this happens without any discussion of race, class, and how violence is often linked to certain types of work, reading our names uncritically is appropriative and using the deaths of people you didn’t care about in life as a vehicle for activism in death. i get that this has to be sold as a concept because cis people are often willfully ignorant that we’re getting killed out here. thing is, there are ways to sell this concept and be conscious of the racial/class/social politics involved herein. i see what the point of TDoR is in terms of public relations, but it isn’t so invaluable that the problematic things about it should go unchecked.
(emphasis author's)

Monica Maldonado, 2012

The truth is, the Trans Day of Remembrance is a day of political grand standing, using the deaths of trans women of colour as a numbers game to buy someone else’s pet project sympathy for votes, dollars, or attention. It’s a day where trans women of colour have greater value dead than we do alive.

We all too often hear that this day is a day where we must not let the deaths of these women be in vain, but this just underscores the transactional nature of these women’s deaths, most of whom fought no war. They lost their lives not in valour, but only as a result of being women in a world filled with gendered violence. They lost their lives because — all too often — our society casts out the disenfranchised and marginalized, no longer calling the huddled masses and tempest-tossed to our communities with heartfelt calls of liberty and virtue.

We should gather to mourn the dead, not conscript them into a battle they never had the privilege to fight while living. It pains me to stand here and remind you that these deaths, of our brothers and sisters and wives and husbands and daughters and sons, that these deaths are senseless tragedies that remain a black mark on society. These deaths are signs of a systemic, institutional, social, economic, and political failure to care for our most vulnerable and marginalized populations. But what may be worse, is the crude politicising of these deaths serves no cause more than that of the same vanity we decry.


Edited to add: Monika Mhz, 2013 (video):

The reading of each mispronounced name that usually happens, mostly from extracontinental locations, acts as a drop of emotional currency for the pimps feeding the masses hungry for misery pornography and serves validation upon their fears. I want to be clear that all fear is real, and I sympathize deeply with the way that events like this -- the general climate of fear, nonlethal violence, and broader aspects of discrimination felt by our community can impact our lives in real ways, regardless of whether or not our risks truly match. But if we are to move forward in creating the change, if we are to move forward in ending the lethal, nonlethal, discursive, institutional and cultural violence that plagues our society, if we're to forge a future where trans women of color's lives are cherished and we don't find reason to feel that we must need to look over our shoulders every waking moment, then we have to be willing to have a real discussion about the violence that faces our community.


fake cis girl, 2013

The dead are us. They’re trans women of color trying to live their damn lives. They’re killed by partners, by clients, by random encounters on the street. I mean, seriously, the silence of white trans people when Islan Nettles was beaten to death walking down the damn street, and even worse the attempts at victim-blaming, were truly horrific…including some invective hurdled about how walking around in the hood comes with such risks. There is such a severe disconnect that part of what would help is that if white trans people in general listened to us this one day a year it could be a catalyst, or so I try to believe. Our realities include much more than how we’re seen in the TDoR list-of-names format: dead people. We are so much more than that, and our realities might be uncomfortable to the “trans community” or maybe, just maybe, the “trans community” will see us as something more than just a list of names of dead people and a bunch of inconvenient bodies and realities to dismiss in life.


Morgan Collado, 2014:

Trans Day of Remembrance is filled to the brim with the names of murdered Black and brown trans women, but is a single evening of remembering enough? And what does it mean that TDoR doesn’t explicitly talk about race and is often dominated by white people? Here in Austin there’s this tradition of calling the names of the dead and then having an audience member sit in a chair that represents where the dead trans woman would sit. The seats are always filled with white people and non-trans women. What do our deaths mean when our bodies, our lives, the physical space we take up, is appropriated by white folks? How can I mourn for my sisters when the space set up for that mourning is so thoroughly colonized? And how can I even see hope of living a full life when I don’t see myself reflected in what is supposed to be my community?

Don’t get me wrong, it’s important to honor those women who came before us, those women murdered by colonial patriarchy. But it seems like more often than not, the queer community at large is content with just remembering. We only hear about trans women after their deaths. And even our deaths are not our own. A week doesn’t go by without a white queer citing the deaths of trans women of color as the evidence of how oppressed they are. These stats are often used in service of their own assimilation; meanwhile, they’re happy to leave us out in the cold. We don’t even have dignity in death, nor the ability to decide what it will mean for us.


fake cis girl (2014):

TDoR generally sees trans women of color as acceptable losses as a central part of the minstrel show that it is. You can’t have a list of dead trans people without it mostly being dead trans women of color with a significant scattering of disabled trans women, too. This common thread between trans suicide and homicides of trans people is no accident, because the violence of rejection may not be the same force of violence that comes from a killer’s blade, but it’s violence nevertheless, and that violence drives some people to suicide. That violence, unlike the violence of a killer, is tolerated and even encouraged in our community. From Ryan Blackhawke’s since-deleted libelous comments complaining about last year’s version of this article to Andrea James’ harassment to the exclusionary nature of the only spaces trans women have (spaces like Ingersoll) comes this violence, and it needs to stop.

TDoR is still broken and still fails trans women of color. Gwen Smith still keeps the list manicured and controlled for whatever political purpose she’s aiming for, refusing to discuss race on the official site of TDoR itself, a day Ms. Smith continues to claim to “own”, and she hasn’t shown any willingness to change the reprehensible fact that deaths in custody don’t count when trans women are frequently targets of police harassment which disproportionately affects trans women of color, which leads to the logical conclusion that we’re more likely to be victims of police and governmental violence.
tim: A warning sign with "Danger" in white, superimposed over a red oval on a black rectangle, above text  "MEN EXPLAINING" (mansplaining)
2014-11-13 08:59 am
Entry tags:

Why I tell people not to go to grad school

I wrote the following on a closed Facebook group for Wellesley alums, and since I spent all that time writing it, thought it would be worth it to share with a larger audience.

See also: How to Fail Out of Grad School Without Really Trying (which I wrote while I was still in grad school).


I thought everyone in this group was tired of me talking about why grad school is a mistake ;) For me, grad school turned out not to be what it says on the tin. That is, I went (to two different Ph.D programs) thinking I was going to learn how to be a researcher. Instead, I found I was being evaluated on things that had nothing to do with ability to do research. My first program had a prelim that was basically filtering out anybody with any degree of impostor syndrome. My second program didn't want me there because I wouldn't tolerate sexual harassment (I wrote about that at length).

I also found that graduate programs -- compared to anyplace I've worked that wasn't a university -- are very unforgiving of, basically, any sign of humanity: chronic illness (regardless of whether it's coded as "physical" or "mental") that interferes with work or causes you to need extended time off. In my experience, if a company hires me, they value me and, all other things being equal, don't want to lose me. So they have a reason to accommodate me (not that companies are perfect about this, of course; the job I stayed at the longest, I left because my manager there made my disability the focus of my annual performance review). In a Ph.D program, though, you're disposable and interchangeable; you're paid very little, so in the same way you might throw away something cheap you bought at Target whereas if you invested in an expensive piece of furniture, you'd fix it, your department generally has no reason to keep you around when they see a way to replace you with somebody healthier.

Don't underestimate the effect of spending 5-6 years or more -- which are, for most other college-educated people, the very years they spend building their careers (often, the years when they can just focus on work and don't yet have a lot of family obligations) being severely underpaid. Of course, this is something that varies a lot by field, and if somebody is in (say) sociology I realize there aren't a surfeit of high-paying jobs outside academia. But for me (I'm in computer science), if I went back to grad school today, that would cut my pay to a sixth of what it is now. Even if you don't care about money (and I didn't think I did when I was starting grad school), it's easy to underestimate the psychological effects of being paid fairly vs. being grossly underpaid because your employer hopes you'll fall for the promise of jam tomorrow (that is, a tenure-track job, which in reality is all but unavailable anymore) and give them your labor for practically nothing now. It really changes the relationship between you and your employer when they're paying you enough that they value their investment in you and won't kick you out the door the first time you show you're human.

When you're considering opportunity costs, also make sure you understand the real costs of grad school. Obviously, don't go anywhere that won't pay your tuition in full and give you a stipend for living expenses. But also know what the cost of housing is where you're going to be going to school; whether you can afford to live near the university or whether you'll have to factor the costs of commuting in (both economic and psychological; having any length of commute to work is apparently a major cause of stress and unhappiness in people's lives); whether or not your program will cover your health insurance or will add insult to injury by claiming you're not an employee (at the university I left, I had to pay thousands of dollars a year out of pocket -- a huge percentage of my stipend -- because they deliberately hired research assistants at 0.45 FTE to avoid paying for benefits); and whether or not you'll have easy access to mental health resources (which some of the most stable and well-adjusted people I know needed after a couple years in grad school).

And then there's the question of what you're going to do afterward. I originally wanted to be a professor. After my second experience in grad school, I no longer did, because I didn't want to be like the professors in my department who defended a grad student who sexually harassed his colleague while blaming the victim. But even if that hadn't happened, I doubt I would ever have been able to find a tenure-track job; even though there are still some TT jobs in computer science (although they're disappearing like in every other field), they're reserved for only the people who scored highest in the privilege lottery and have a monomaniacal focus on work. One or the other (generally) doesn't cut it. In grad school, I never wanted to spend all my waking hours on research, which meant that if I'd graduated, I would have had at most 2 or 3 publications; when I read CVs for tenure-track faculty candidates who were coming to meet with grad students, they had as many as 20 publications straight out of grad school. I realized that I didn't like research enough to spend that much time on it, and in fact, I don't like *any* one thing enough to spend that much time on it. I'm passionate about more than one thing, and I'd even like to start a family sooner or later. I've talked to one too many people who had to choose between going hard for tenure and watching their children grow up, chose the former, and regretted it.

(edited to add:) If you already know you don't want to be a professor or work at a research lab, and you get a Ph.D, be prepared to have to remove it from your résumé to get a job; at least in computer science, a Ph.D actually lowers your expected salary compared to a master's. Be prepared to enter every job interview on your guard, explaining why you're not overqualified or why you won't be bored at a job that your interviewer is already assuming is "beneath you". (This is, at least, the experience of some of my friends with computer science Ph.Ds.) Some people describe a Ph.D as a "union card" to teach at a university -- if you already know that's not what you want to do, think especially hard about why you want to get one. At least in my field, everything else you can do along the way (teaching, learning, reading, writing) is work you can do outside a university -- often, as part of an industry job, while getting paid a lot more for it.

Now, just because grad school is essentially a huge scam that promises much in order to extract extremely cheap labor from grad students and make them feel like they're getting an education, that doesn't mean it isn't the right choice for some people. If you read all this and think "hmm, I really still want to go," then you should probably go. Some books you should read first, though:

Leaving the Ivory Tower, Barbara Lovitts: It's about why Ph.D students leave grad school (spoiler: the reason is usually structural in that a huge number of departments systematically identify a few favorites among each incoming cohort of Ph.D students and actively neglect the rest; but faculty take credit for their successful students while placing all the blame on the individuals who don't succeed).

Getting What You Came For, Robert Peters: very readable, and describes what you need to be doing to get through a Ph.D program. It won't help if your advisor is determined to defend sexual harassment, of course, but if you read this book and more-or-less do what it says I think that you'll avoid some of the major mistakes that are avoidable.
tim: text: "I'm not offended, I'm defiant" (defiant)
2014-11-08 07:24 am

NPR Continues to be Full Of Awful People

I read this article summarizing a study (paywalled, unfortunately) on trans men who become pregnant with interest, since (if all goes well) I'll be getting pregnant sometime in the next year. Interest and, also, nausea (and I'm not even pregnant yet).

Because any day is a good day for pointing out why cis people are wrong:


  • Automatically labeling men who have uteruses as "transgender" = ugh. For the record, if you want a ticket out of my life, one of the fastest ways is to call me "transgender". I still don't know what that word communicates other than "I am trying to perform my well-intentioned, liberal attitude." (I'm transsexual, but then, if you're about to describe me that way, consider whether it's any more relevant than the fact that I'm right-handed is. You didn't know whether I was right-handed or not? Exactly.)
  • "When Dad is the one who gets pregnant, the whole process of pregnancy and childbirth gets a lot more complicated." I guess so, but ONLY BECAUSE GOD DAMN CIS PEOPLE MAKE IT COMPLICATED WITH THEIR INABILITY TO UNDERSTAND ANYTHING MORE NUANCED THAN GO DOG GO.
  • "someone who has transitioned from a female identity to a male or masculine identity" - I can't even begin to explain all of the fail in this sentence other than by headdesking repeatedly. I'd like to propose a licensing system where cis people get to use the word "identity" only a limited number of times and only when referring to their own identities, as opposed to using it for invalidating trans people, which is what they always use it for.
  • "Pregnancy as a transgender man is unlike any other kind" - well, I haven't been pregnant (yet), so I don't know (and when I am pregnant, it won't be "as a transgender man", because again, wtf does "transgender" mean), but again, IF IT'S DIFFERENT, THAT'S BECAUSE CIS PEOPLE FORCE IT TO BE DIFFERENT.
  • "Some transgender men use testosterone to look and sound more masculine." This is like saying that some cancer patients use chemotherapy to look more bald.
  • "gender dysphoria, the feeling that one's psychological gender identity is different from one's biological sex" FUCCCCK it's almost 2015 and we're still repeating this nonsense about "gender identity" and "biological sex"? Reminder: humans do not have a "biological sex" that is different from their "gender identity". They have a collection of physical characteristics, some of which differ in ways that are sometimes categorized using a social model that some people ignorantly call "biological sex". But the only thing "biological sex" means is that a cis person is trying to misgender you because they feel that science is -- rather than a tool for understanding the world -- a good way for them to assert their power over you using the epistemic superiority that was granted to them the day they were born cis.
  • "The author of the new graphic memoir Pregnant Butch, a masculine-looking woman named by A.K. Summers, said one of the worst parts of her pregnancy was that it exaggerated the most female aspects of her body" -- I'll take their word for it (which maybe I shouldn't) that A.K. Summers' pronouns are "she/her", but why couldn't they find an actual man who'd been pregnant to quote in an article about, y'know, men being pregnant?
  • "In some of the transgender men in the study, gender dysphoria actually declined with pregnancy. These people said they were, for the first time in their lives, pleased with their bodies, which were finally helping them do something they valued that a typical male body could not do." WTF does "typical" mean? Why is a cis man's body any more "typically male" than mine?
  • "gender identity is a spectrum" - no. Fuck you. (That's my "gender identity.")
  • And finally, wtf is up with the headless-trans-man (though who knows what gender either the adult or the baby in the picture is... which is kind of the point, though it's probably lost on anyone working for NPR) photo illustrating the article? Given that the article strips away our autonomy and dignity, can we at least be afforded the luxury of having faces?


I should note that probably the study being discussed in the article is perfectly OK (though who knows? Since it's paywalled, I can't read it), with the exception of an author's use of "gender identity as a spectrum" (again, the term "spectrum" needs to be taken out and shot unless you're referring to a brand of organic all-vegetable shortening). I'm just objecting to NPR's coverage of it.
tim: text: "I'm not offended, I'm defiant" (defiant)
2014-11-04 09:25 pm
Entry tags:

Does Mozilla support Gamergate?

Since writing "It's All Connected" almost a month ago, I haven't had much to say about GamerGate; it seems like everything's been said and the people who should be listening are refusing to.

Tonight, though, I do want to add something. On Twitter, [twitter.com profile] whump linked to this pro-GamerGate article by Georgina Young. The article is entirely unremarkable except for one thing: it appears on Mozilla's Open Standard blog. Unlike Planet Mozilla, Open Standard's messaging is that it is a blog curated by Mozilla, and Mozilla is responsible for any editorial choices.

By choosing to present the issue of whether women should be purged from the video game industry as if it has two sides, Mozilla is legitimizing the abuse of women and actively participating in the creation of a hostile environment for women in software.

Moreover, as [twitter.com profile] solarbirdy pointed out, Open Standard almost gave Eron Gjoni -- the abusive stalker who launched the GamerGate harassment campaign back in August as revenge against his ex Zoe Quinn -- a platform to continue perpetrating his abuse. Gjoni has admitted that he started GamerGate in order to defame and abuse Quinn.

This might be more surprising to me if not for what happened back in September when I filed a Bugzilla bug report about GamerGaters' use of Mozilla's Etherpad installation -- basically, a public pastebin -- to coordinate their attacks. Mozilla runs an open, unauthenticated Etherpad server at etherpad.mozilla.org (e.m.o.) -- the e.m.o. home page contains the following disclaimer: "Mozilla systems and collaborative tools are intended for use by the Mozilla community for Mozilla related work and subject to web site terms and conditions at Legal Notices." I expected that -- since coordinating Gamergate was obviously not Mozilla-related, and the people using it for that were not members of the Mozilla community -- the content would be swiftly deleted., in the same way that Github swiftly deleted a repository used by Gamergaters. [Edit: see comments.]

The contents of Bugzilla issue 1063892 are private, visible only to me (as the bug reporter) and Mozilla staff. But here's the gist of it: several Mozilla staff concurred that it was not an option to remove the content from their Etherpad server without consulting their legal team. This is puzzling, since most other companies I'm familiar with would not need to consult their legal teams to remove consent that constituted an abuse of company resources. When a member of the Mozilla legal team asked, "does the existence of these mopads have any negative consequences to the company?", multiple Mozilla employees answered this question "no" -- that is, they don't believe that it hurts Mozilla's reputation to provide free Web hosting for a harassment campaign. Jake Maul, a member of the Mozilla ops team who the bug was assigned to, elaborated:


If Mozilla removes this content (without any legal requirement to do so), without a policing system in place to remove other non-Mozilla content, we open ourselves up to the claim of being biased. This is not a Mozilla issue. By removing content (without law or policy protecting us), we potentially make it one.

If someone can point to specific lines of pads that infringe specific parts of the Mozilla CoC (or other suitable document), then IMO that drastically lowers the bar to removing these pads because we can easily point to why the pad was removed. For instance, we could remove the pad and then create a new one with the same name containing a link to the relevant document to explain why it was removed.

I'd personally be much more at ease about removing content if someone can show me where in the pads the harassment is happening. They're large, and much of what I've skimmed seems like links to other places and (without following every link) I'm not sure the stuff hosted on our servers constitutes harassment. If it doesn't, then what reason do we have to remove it?

In case it seems like I'm supporting harassment, let me be clear: all I want is a good solid leg to stand on before we employ the banhammer. Mozilla has had plenty of bad PR this year, and I don't want to add to it with a claim about censorship, "hating gamers", or "supporting misguided Social Justice Warriors". If we get our ducks in a row first, we can (hopefully) avoid any negative fallout.


Jake seemed to be under the misapprehension that Mozilla -- a private company -- requires some sort of law that specifically justifies them using their property in the way that they choose. In fact, Mozilla is free to delete any content from their servers, for any reason that they choose, just like every other private company (an exception is common carriers like your ISP or the phone company; Mozilla is not a common carrier).

In response to Jake's comment, I wrote:

I'm afraid I don't see how Mozilla will be hurt by criticism from people who self-identify as opponents to social justice.


No one addressed this comment. In any case, the legal team's final response was:

Jake: please take down only the specific etherpads that were reported in this bug. The basis for removal is that these reported pads: (1) do not relate to the Mozilla community and (2) contain objectionable content. The combination of both us why we're requesting a takedown.

Moving forward, we're recommending against active searching of public pads using keywords. Instead, our position is that we'll consider any specific reported pads and decide on a case by case basis if there is a basis for removal. We feel this is the best way to retain and encourage the positive uses of public pads that can be used by Mozillians and non-Mozillians (e.g. teachers, other nonprofits, community groups, etc.). This approach also means that, when pads are being used for questionable purposes and this is reported to us, we'll examine and remove public pads based on the specific situation. There are many interpretations and perspectives of what is objectionable content. The legal team assists in making this call.

Please file a legal bug if there are more reports of objectionable mopads. You can file here: https://bugzilla.mozilla.org/enter_bug.cgi?product=Legal

In this gamer situation, if more reports come in regarding objectionable pads, we can evaluate and discuss if further action is needed and what that might look like.


It's unclear to me how removing harassing content interferes with use of Mozilla resources by "teachers, other nonprofits, community groups, etc." I am also genuinely unsure what kind of backlash Maul and several other Mozilla staff members feared from people who don't like "social justice warriors", but in any case, it seems to me like if Mozilla is going to get out of the business of standing up for social justice on the Web, they should probably let their donors and volunteers know that.

You could, of course, argue that all of this is evidence of Mozilla's collective cowardice in the face of a genuine threat to the open Web, but I would argue that organizational cowardice in the face of coordinated bullying is indistinguishable from support for those bullies. Unlike the many women who Gamergate attacked -- with the help of free Web hosting from Mozilla, at least temporarily -- Mozilla is a wealthy organization with the resources to resist harassment and attacks. Instead, Mozilla has chosen to walk a path paved with false equivalences and bogus free speech concerns -- a path that ultimately leads to a Web where only people with the resources and social standing to resist or evade harassment and doxxing can make their voices heard.

If you support Mozilla but can't feel safe supporting an organization that presents attacks on women as just another side in a debate, I encourage you to let them know.

Edit: Since at least one person has complained that the quotes are out of context, here's the entire PDF of the Bugzilla thread, with innocent parties' names redacted.
tim: Tim with short hair, smiling, wearing a black jacket over a white T-shirt (Default)
2014-10-14 02:47 pm

CUFP notes, 2014

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

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

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

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

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

It's All Connected

Content warning: Discussion of violence against women, gun violence, death and rape threats, workplace harassment, suicide (and threats thereof as an emotional manipulation tactic), online harassment, abuse of the legal system to further sexual harassment and domestic violence, and neo-Nazis.

Italicized quotes are from Stephen Fearing's song "The Bells of Morning", which he wrote in 1989 about the École Polytechnique massacre in Montreal.

It's All Connected

Donatenow

"Tonight I am speechless
My head is filled with pouring rain
As the darkness falls on Montreal
When violence is shrieking
The city streets will run with pain
Until the moon can shed no light at all"




"Gamergate": the word we dare not write on Twitter, for fear of a torrent of harassment. It started with a spurned ex-boyfriend doing his best to try to drag his ex's reputation through the mud. He succeeded beyond his wildest dreams, because she makes video games, and he -- as well as an army of supporters initially rallied using the 4chan hate site -- weaponized male video game enthusiasts' terror of women encroaching on their turf.

Why this fear of women? The term "witch hunt" is overused, but Gamergate is one of the closest modern-day analogues to a witch hunt. Teenage boys, frustrated in a culture that doesn't have much use for teenagers at all, were so dedicated in their zeal to spread lies and hyperbole that a major corporation, Intel, acted on the fear they spread. (I use "teenage boys" here to refer to a state of mind.) Like a toddler who has figured out something that annoys their parents and keeps doing it, and like the teenage girls of New England in the 17th century who figured out that they could set a deadly chain of events into motion, these boys are drunk on the power they have stumbled into. Their goal? Stopping a woman they believe to have strange powers: the power to pass off what they see as a non-game as a game, through bewitchment of influential men ("bewitchment of" here means "sex with"). I am being literal here. Read more... )

tim: Mike Slackernerny thinking "Scientific progress never smelled better" (science)
2014-10-05 12:25 pm

Linkdump about why biological sex is a social construct

I find myself looking for this collection of links so often (and I just assembled it for a comment elsewhere) that I'm going to put it here in one place:



Insistence on the objective truth of the culturally mediated ideological construct called "biological sex" is anti-trans, anti-intellectual, and anti-science. It is indistinguishable from misgendering -- in fact, it's a form of misgendering clothed in ersatz scientific terminology -- and as such, it's violence against trans and gender-non-conforming people, but especially against trans women and other people who were coercively assigned male at birth but reject that designation.
tim: text: "I'm not offended, I'm defiant" (defiant)
2014-10-01 08:47 pm
Entry tags:

Open letter to Intel

I submitted the following comment using the form at https://www-ssl.intel.com/content/www/us/en/forms/corporate-responsibility-contact-us.html . If you feel similarly, I encourage you to submit your own comment!
To whom it may concern:

I am disappointed to learn that Intel made the decision to pull its advertising from Gamasutra. I understand that Intel made this decision under pressure from people identifying themselves with the "Gamergate" coordinated harassment campaign. Gamergate is a concerted effort on the part of a small group of virulently misogynist men to drive women out of the video game industry. While the actual number of people involved in it is small, they have directed a huge amount of harassment at any woman who they see as a threat: that is, every woman they can find who makes or plays video games. Links with more details can be found at http://geekfeminism.wikia.com/wiki/Gamergate_coordinated_harassment_campaign .

By pulling its advertising from Gamasutra, Intel has made the choice to align itself with a hate group that seeks nothing less than to stop women from being employed in the video game industry. Does that represent Intel's views as a corporation?

Sincerely,
Tim Chevalier
Co-moderator, geekfeminism.org
Wiki administrator, Geek Feminism Wiki - http://geekfeminism.wikia.com/wiki/Geek_Feminism_Wiki
Senior Member of Technical Staff, Heroku
Co-signers (added after the fact):

Frances Hocutt
Joshua Wise
tim: Tim with short hair, smiling, wearing a black jacket over a white T-shirt (Default)
2014-10-01 10:22 am

Functional Programming Community Challenge: It's not too late!

As of September 19th, functional programmers and friends had surpassed not just our initial goal of $4096, but also our first stretch goal of $8192 and second stretch goal of $10,000!

And amazingly, since then, we've raised another $2407 without really trying -- at this writing, we're up to $12,407, most recently thanks to a donation from Simon Peyton Jones. I think Simon deserves a lot of the credit for building the supportive community that I discussed in my initial post about why the Ada Initiative matters to functional programming, so I'm grateful for his support for this challenge.

Donation button

Donate to the Ada Initiative

The Ada Initiative announced their overall fundraising goal: $150,000, which they're currently about $32,000 away from, with 8 days to go:


Donate now



Besides raising money, the other goal of the functional programming challenge was to lobby the ACM to be more uniform about communicating its anti-harassment policy to conference attendees. 31 people (last time I checked) specifically tweeted at [twitter.com profile] TheOfficialACM, although only [twitter.com profile] chrisamaphone had the ingenuity to directly tie it in to what was their most recent tweet at the time:







No reply so far. However, I'm aware that there are other ways besides Twitter to contact the ACM, and I'm in touch with several people who are active in SIGPLAN to discuss next steps.

Note that there have been 686 individual donors so far. Of those, at least 59 donated as part of the functional programming community challenge (including 58 individuals and one company, AlephCloud Systems). That means 8.6% of TAI's total donors for the fall fundraiser donated through the functional programming challenge! (And actually more than that, since the count of 59 only includes people who gave permission for their names to be used on TAI's web site.)

So far, we've donated $12,407 out of a total of $118,469 -- which means 10.5% of TAI's total donations came from the functional programming community! As much as I'd like to think functional programmers make up ten percent of all programmers (and actually, people who donated to TAI also include librarians, hackerspace supporters, people interested in the intersection of science, technology, and culture, and science fiction/fantasy fans, among other people who may or may not be programmers), I know we're a smaller percentage than that. But we're overrepresented among TAI supporters, which is great.

It's not too late to skew the numbers even further, and if you donate $128 or more, you still get an awesome "Not Afraid to Say the F-Word" sticker pack! And if we do reach $16,384 in the next 8 days, our promise to perform "There's No Type Class Like Show Type Class" and put the recording online still stands.

I would also like to thank everybody else who has donated to #lambda4ada so far. This should be a complete list of people who either gave permission for their names to be used, or tweeted (in the latter case, I'm only using Twitter handles). If you donated and are not on the list, but want to be, let me know. If your name is on the list and I've spelled it wrong (or included alongside your Twitter handle), also let me know.

Adam C. Foltzer (lambda4ada co-organizer)
Chung-chieh Shan (lambda4ada co-organizer)
Clément Delafargue (lambda4ada co-organizer)

Aaron Levin / Weird Canada
Aaron Miller
Alejandro Cabrera
AlephCloud Systems
André Arko
Andy Adams-Moran
Ben Blum
[twitter.com profile] bentnib
Bethany Lister
Brent Yorgey
Carlo Angiuli
Chris Martens
Cidney Hamilton
Colin Barrett
Colin Gourlay
Corey "cmr" Richardson
Dan
Dan Licata
Dan Peebles
Daniel Bergey
Daniel Patterson
Daniel Ross
David Smith
David Van Horn
[twitter.com profile] dorchard
Dylan Thurston
Edward Kmett
Ellen Spertus
Eni Mustafaraj
Eric Rasmussen
Eric Sipple
fanf42
Florent Becker
Glenn Willen
Holly M
J. Ian Johnson
Jack Moffitt
James Gary
John Garvin
Jon Sterling
[twitter.com profile] joshbohde
Joshua Dunfield
Justin Bailey
Ken Keiter
Kevin Scaldeferri
[twitter.com profile] kowey
Kristy
Lars Hupel
Levent Erkok
[twitter.com profile] lindsey
Lucas Bradstreet
Lyn Turbak
M Wallace
[twitter.com profile] MaggieLitton
Manuel Chakravarty
Michael Greenberg
Neel Krishnaswami
Pat Hickey
Peter Fogg
Philip Wadler
Prabhakar Ragde
Ryan Wright
[twitter.com profile] shelfuu
[twitter.com profile] simrob
[twitter.com profile] tomburns
wilkie
Will Salz
Wouter Swierstra

Many of the people above tweeted under #lambda4ada to announce that they donated and to lobby the ACM. The following people also tweeted under #lambda4ada in order to pressure the ACM:

[twitter.com profile] atombeast
Conor McBride [twitter.com profile] pigworker

Thank you all -- including those of you who preferred not to be named -- for all you've done so far, including donating, communicating with the ACM, and telling your friends in the functional programming community about the challenge! It makes me so happy.
tim: A warning sign with "Danger" in white, superimposed over a red oval on a black rectangle, above text  "MEN EXPLAINING" (mansplaining)
2014-09-28 09:25 am
Entry tags:

Self-Censorship

Saying "I don't censor myself. I just say what I think" is popular. I used to say it a lot myself, and I probably still sometimes say something that amounts to that.

My preferred way of saying it now looks more like "no fucks given" -- which is, I think, a little bit more accurate in that it's a statement about my assessment of the risks and benefits of saying something in a particular situation. Which is to do with how much power I have in that situation.

So somebody who says "I never censor myself" is either extremely powerful (and if that person is Donald Trump, he might just be making a completely straightforward statement of truth); is foolish (somewhat more common than the Donald Trump scenario); or isn't being totally honest. (Ironically.)

It's the last case -- the "not totally honest" case -- that I want to look at more carefully. I think a lot of people take pride in their putative lack of self-censorship because they like TV shows like "South Park" or admire some particular comedian. But they're not as funny as the comedians they admire, or even as funny as "South Park" can occasionally be.

More to the point, I think "I don't censor myself" often comes with an implied moral judgment: that there's something dishonest about not saying what you really think, in every possible situation. Tell your friend that his haircut looks nice, when you think he looks like someone put a bowl on his head and cut around it? YOU ARE A TERRIBLE PERSON, because somehow honesty (about something unimportant) gets weighted much higher than the value of maintaining a relationship and making someone else feel nice. Why is that? We know there's no single moral principle that trumps everything -- most decisions are some form of balancing test or another.

Interlude



What does the expression x + y mean in a program? Pick whatever programming language you like (except Lisp, I guess -- sorry) for the purpose of answering; at least, any one where x and y denote variable references (so, not Erlang or Prolog either).

You don't know, right? It depends on what x and y refer to in the lexically (or dynamically, depending what language you picked) enclosing environment when this expression gets evaluated at runtime. If you are a programmer, you understand that context doesn't only affect meaning. It is meaning. Or at least, you understand that when you're reasoning about programs.

Context



So why would I choose to not say exactly what I think in a given situation? If the same person with the haircut was a total stranger, and my job was to do quality assurance for a haircutting place, then probably I would say that his haircut looked bad. So that suggests that context matters.

Not only does context affect the meaning of what you say, context is meaning in and of itself. For example, if I was at a bar with a very close friend and we were 3 drinks in, I might tell a fantastically filthy joke. (I mention "3 drinks in" because shared intoxication is a legible indicator of intimacy in my culture, rather than because drinking makes people behave badly.) I wouldn't tell the same joke at 10:00 AM on a Monday in a meeting at work. Why is this? Am I a hypocrite because I'd tell the joke in one situation but not the other? If the joke is somehow bad if I tell it at work, isn't it also bad if I tell it to my friend?

25 more paragraphs; some discussion of sexualized presentations, trigger/content warning debates, and racism )
tim: Tim with short hair, smiling, wearing a black jacket over a white T-shirt (Default)
2014-09-27 05:56 pm

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

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.
tim: text: "I'm not offended, I'm defiant" (not offended)
2014-09-23 03:52 pm

(no subject)

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.
tim: Tim with short hair, smiling, wearing a black jacket over a white T-shirt (Default)
2014-09-23 09:14 am

ICFP 2014 Notes, Day 3

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!
tim: A person with multicolored hair holding a sign that says "Binaries Are For Computers" with rainbow-colored letters (binaries)
2014-09-22 08:05 am

ICFP 2014 Notes, Day 2

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.
tim: A person with multicolored hair holding a sign that says "Binaries Are For Computers" with rainbow-colored letters (binaries)
2014-09-21 07:05 pm

ICFP 2014 Notes, Day 1

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!
tim: Tim with short hair, smiling, wearing a black jacket over a white T-shirt (Default)
2014-09-19 05:03 pm

WE DID IT!

See that number? It has five digits in it.

Donation button

Donate to the Ada Initiative

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

[twitter.com profile] 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 :)

tim: Tim with short hair, smiling, wearing a black jacket over a white T-shirt (Default)
2014-09-19 12:11 pm

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

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

Donation button

Donate to the Ada Initiative

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
[twitter.com profile] dorchard
Eni Mustafaraj
Eric Sipple
Glenn Willen
Justin Bailey
Ken Keiter
Kevin Scaldeferri
Kristy
[twitter.com profile] lindsey
Lyn Turbak
M Wallace
Michael Greenberg
Peter Fogg
Rob Simmons
Ryan Wright
[twitter.com profile] 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.

Donation button

Donate to the Ada Initiative

tim: Tim with short hair, smiling, wearing a black jacket over a white T-shirt (Default)
2014-09-18 06:09 pm

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

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!

Donation button

Donate to the Ada Initiative

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 [twitter.com profile] kowey
Jack Moffitt
Philip Wadler

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

Aaron Tomb [twitter.com profile] atombeast
algebraic affects [twitter.com profile] joshbohde
Bob Atkey [twitter.com profile] bentnib
Maggie Litton [twitter.com profile] MaggieLitton

And finally, thanks to [twitter.com profile] haskellnow, [twitter.com profile] haskellorg, and [twitter.com profile] lambdaladies for help publicizing!

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


  1. Know what intersectionality is
    This is tricky to talk about, because TAI and the loosely affiliated Geek Feminism Blog and Geek Feminism Wiki are all run mostly by white people (like me). We all know there's a problem here; we talk about how there's no excuse for companies and open-source communities to be 100% male, yet we're almost 100% white.

    With that said, to be an ally, being open to feminist perspectives isn't enough. Intersectionality, a term coined by Black feminist scholar Patricia Hill Collins, refers to the ways in which membership in multiple oppressed groups is not compositional. That is, a Black woman's experiences (for example) are not merely the result of composing a prototypical white woman's experiences with a prototypical Black man's experiences; rather, multiple marginalizations compose in a more complicated way. When it comes to understanding a concept like intersectionality, functional programmers have an advantage: like intersectional feminists, we are often criticized for using too many long and unfamiliar words. So we should know as well as anyone that sometimes, technical language is necessary for clarity. (Insert pun about intersection types here.)
  2. Attend an Ally Skills workshop

    The Ada Initiative runs workshops that teach men how to better support women in their workplaces and other communities. I participated in the Ally Skills track during this year's AdaCamp in Portland, and I appreciated that it was designed primarily around small-group discussions of hypothetical but realistic scenarios. For a reasonable fee, TAI will hold one at your workplace, and one thing that donations finance is holding them at nonprofit organizations for a reduced cost. You just have to ask.
  3. Listen to women

    When a woman talks about her experiences, and you have never had the experience of being perceived as a woman, try something: assume she is reporting on her own experiences accurately. Almost all the time, your assumption will be correct. But more than that, it's an important skill to be able to temporarily suspend your programmerly desire to find edge cases and point out errors, and just listen. Listening doesn't always mean shutting the heck up, although sometimes that's what's needed too. Rather, active listening means acknowledging that you understand what's being said: you can do this non-verbally (for in-person discussions) or by rephrasing what the person said in different words to indicate your comprehension and validate what she is saying. In light of point 1 about intersectionality, the more intersecting oppressions somebody has, the more important it is to listen to and let them know that you hear them.

    This doesn't mean you have to believe everything all women say all the time. Rather, it means that there are already enough men in the world automatically casting doubt on everything a woman says, and you don't need to be one more. Indicating that you hear what somebody is saying doesn't mean agreeing. It means that for the moment, you prioritize understanding their message ahead of showing off how much you know or how good you are at debates. You can decide offline whether to agree.
  4. Believe women

    But I just said you didn't have to agree! Well, yes, you don't have to, but in a world that bombards more or less all women with gaslighting, believing a woman is a radical act. In particular, if a woman is talking about her experience of harassment or another adverse experience that typically involves men mistreating women when no other men are present, assume she's telling the truth (and if anything, understating how bad it was). You will almost never be wrong if you believe her, and it's better to have a vanishingly low chance of being wrong than to contribute to the systematic psychological torture of women who are honest about their lives.
  5. Help women get heard

    Say you're in a meeting and a woman says something; it's ignored, and 15 minutes later, a man rephrases the same idea and gets praised for it. At that moment, you can speak out by saying, "How does that compare to the idea that [woman's name] proposed?" This is a non-confrontational way to re-center the woman as originator of an idea. In general, if you're in a conversation and other people are steamrolling a woman or women, say something -- you don't have to say "you sexist pigs, why don't you listen to her?" unless you want to, but there are many different ways to indicate that, if nothing else, you heard her.
  6. Hire women

    If you work at a software company and have any influence over hiring, hire women. The same goes if you work at a university, even if the hiring process is a bit more byzantine. In computer science or in software, anybody who is not a cis man is more qualified than an imaginary person who is identical except being a cis man. Isn't that "reverse sexism"? No, for the same reason that it's harder to do a pull-up with 50 pounds of weights strapped to your ankles than without. Give women (as well as people of color, disabled people, trans people, queer people...) credit for the enormous amount of work they've had to do just to be seen as equally competent to a given man who is actually less competent. In functional programming, nobody would do this work just for fame and wealth, because there is very little of that to be had; someone purely interested in a high-paying job or other extrinsic motivators would never choose our field if they also had to deal with others' bias along with the risk of not getting rewarded at all. The people who do persevere do it because they love the work they do, probably more than you do.
  7. Practice your empathy

    If you have lived your entire life in the Western Hemisphere being seen as a white, cis, abled man, you probably have some work to do here. It's not your fault: it's likely that you've rarely been rewarded for taking the perspective of someone unlike yourself, and indeed have been coddled for solipsistic thinking rather than being encouraged to think of others' feelings. Fortunately, empathy is a skill that can be learned. Kronda Adair's talk Expanding Your Empathy (from Open Source Bridge 2013) is one place to start.
  8. Encourage double-blind reviewing

    This one applies to those of you who review for and/or help organize academic conferences. It is documented beyond a shadow of a doubt that innate bias affects decisions about people's work: when evaluators know that a particular article is by somebody with a name they interpret as female, they grade it more harshly than if all of its authors had male-coded names. Most people don't want to exercise bias against women, but they do anyway, subconsciously. Concealing author names during reviewing goes part of the way towards addressing this problem. It's not perfect, but someone claiming that it doesn't reduce bias is making an evidence-free claim.

    Non-academics can try applying this one by having their recruiting team (if they have one) redact names from resumes during the first round of candidate evaluation.
  9. Show fallibility and humility

    This one has to be exercised carefully, but if you are someone with a relatively high amount of power (for example, if you're a white cis man who has a tenure-track or tenured academic position, or are a manager in an industry position), it's helpful to others around you if you say "I don't know" when you don't know, admit mistakes when you are wrong, and acknowledge when you're finding something difficult. Sometimes people underestimate just how much influence they have. If you're white, cis, and male, whether you like it or not, the people around you will tend to believe the things you say. With that increased power comes increased responsibility: to scrupulously distinguish what you believe to be facts from what you know are your opinions.
  10. Volunteer to mentor women

    For example, the GNOME Outreach Program for Women matches promising women getting started in open source with mentors from various projects. This is one of the most direct, personal ways you can help. If you don't work on an open-source project, find out what your company can do in the way of outreach at local schools, or if you're a faculty member, figure out what your department can do to support women in undergrad and graduate CS programs instead of just tallying up your admission numbers and cheerfully declaring diversity a done deal while all the women get constructively dismissed.

    If you do this, though, be prepared to learn as much from your mentee as vice versa.
  11. Try to be kinder than you have to

    I don't mean that you need to be kind to people who are abusing or oppressing you; you don't. What I mean is that you have the affordance of being patient when somebody asks the same beginner question for the nth time on a forum you're on, or when somebody makes a wrong assumption based on their knowledge of a different programming language. It's easy to lose patience with people who don't know as much as you do; I've done it a lot myself. But it takes very little to make somebody give up on a community that is new to them, and I've personally seen that happening with functional programming. When somebody else genuinely seems to be acting in good faith, even if they're confused or seem to be slow on the uptake, just remind yourself that you have a privilege that they lack (knowledge) and give them the benefit of the doubt.
  12. Remember that functional programming is a part of programming, and programming is part of the world.

    You might react to some of these suggestions with, "what does that have to do with functional programming? That happens everywhere." Indeed. Most of these bullet points are not specific to our field. But global problems must be addressed locally, in the community that you're in. The good news is that everything you do to make functional programming a safer field for women, and genderqueer and non-binary, people to be in will also make programming as a whole that much safer, as well as the world as a whole.

Donation button

Donate to the Ada Initiative
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

tim: Tim with short hair, smiling, wearing a black jacket over a white T-shirt (Default)
2014-09-17 09:53 pm

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

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.

Donation button

Donate to the Ada Initiative

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