tim | Entries tagged with computer science

There's a thing that happens sometimes when language changes, which is that people mistake a conditional claim for an absolute one.

For example, a person of color might suggest that the terms "primary/replica" could be used instead of the technical term "master/slave", to avoid trivializing an extended era of structural violence which to this date the United States has never made amends for. A white person might reply indignantly, might condemn "language policing" and say "you can't tell me what words to use!"

Now suppose I make the claim that an adjacency list uses less memory to represent a sparse graph than an adjacency matrix does, at the cost of making edge-existence queries less efficient. Is anybody going to tell me that I'm algorithm-policing or that I can't make them stop using an adjacency matrix? I don't think so, because they would recognize that I'm stating that there's a trade-off implicit in your choice of data structure: make edge-existence queries faster, or use less memory. I'm not telling you how you should resolve that trade-off, just that there is one.

Like engineering, language involves trade-offs. Continuing to use the term "master/slave" in technical contexts where it's historically been used arguably has the advantage of being a well-understood term, as well as saving the time that would be spent explaining and possibly defending the decision to switch to new vocabulary. The disadvantage of continuing to use "master/slave" is that it alienates many Black Americans, among others.

It's up to each individual to decide whether they want to resolve this particular linguistic trade-off on the side of subjective clarity, or of making as many people as possible feel welcome. To point out that a trade-off exists isn't to demand that it be resolved in one particular way. It's just to help people make decisions that reflect their values, just as explaining engineering trade-offs helps people make wise use of the resources available to them.

Another politically loaded technical term is "divide and conquer". Recursive algorithms aren't inherently violent or militaristic -- why not "divide and solve" or "divide and organize"? Again, there's a trade-off: using the historically accepted term "divide and conquer" has the advantage of clarity, while "divide and solve" has the advantage of not normalizing violence or abuse of power. You might choose to accept "primary/replica" but continue saying "divide and conquer", and that's fine. Just realize that there are trade-offs involved in both, and that the choice to continue using an accepted term whose connotations are political is just as political a choice as the choice to adopt a new term.

If I say that QuickSort has better average-case performance while MergeSort has better worst-case performance, I don't think anyone would complain that I'm telling them what sorting algorithm to use, or dictating whether they should care more about average-case performance or about worse-case performance. So why do so many people seem to interpret observations as commands when those observations are about language trade-offs?

I'm organizing an Ally Skills Workshop at ICFP this August, which Valerie Aurora of the Ada Initiative will be teaching. If you are attending ICFP or a co-located event such as the Haskell Symposium, CUFP, or Erlang Workshop (not an exhaustive list), you are welcome and encouraged to apply to attend!

The workshop is geared towards men in the functional programming community who want to learn how to be better allies to women and non-binary people in the community. However, it is open to people of all genders.

For all the details, see the information page, which links to a Google Forms page that you can use to apply.

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

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

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

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

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

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

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

and

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

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

A comment on

lambdamaphone's post about obstacles to learning typed functional programming, in which I attempt to dissect the antipathy that some programmers have towards math, encumbered by as little evidence as possible. I wanted to preserve it someplace.

Rank speculation: A lot of people have traumatic experiences associated with math, because math is frequently taught in elementary school (computer science rarely is). In particular, math teachers at that level are usually poorly trained (due to the structural disincentives for people with math education to enter K-12 teaching) and/or lack enthusiasm for the subject.

Moreover, at that time in a person's schooling, it's common for a student to be shamed (publicly or privately) and told they're "not good at math". Because socially, math isn't considered a necessary skill (unlike reading), it's easy for a student to deal with this kind of treatment through avoidance rather than mastery. This is completely understandable for a child who has never been told why math is worth doing and has only been taught that it's a tool that will be used to humiliate them and demonstrate their inadequacy, by the way.

So when many adults -- even adults who have enough analytical reasoning ability to be programmers -- hear the word "math", they think back to those experiences, to the time when they were told "you're no good at this", and they freeze up, or else feel the need to prove why math is some useless ivory-tower theory garbage, because of their own feelings of insecurity to do with the disservice that their school system did them.

This is rank speculation because I didn't go to school until college, but I did tutor high school dropouts for a brief period of time, and over and over I'd run into a student who kept saying "I'm not good at math" even though I was there to help them be better at it.

I wrote this comment on a LinkedIn forum thread a few weeks ago for alums of my undergrad school, and I wanted to save the comment somewhere less ephemeral. Most of it is replying to another comment that I won't quote directly since it was posted to a private forum, but it's from a faculty member who I respect very much.

I haven't read the blog post Daniel linked to yet, but I would suspect that the reasons based on humanities/social science apply to us as CS people more than you might think.

As far as [REDACTED]'s points: I don't know of any CS Ph.D programs that will put you into debt either... well, sort of. I went from having ~ $5000 in student loans post-Wellesley to having ~ $40000 in student loans after being a Ph.D student at Portland State for 4 years (and not graduating). Why? Because my grant didn't pay for health insurance, so I had to pay for that out-of-pocket (and the cost of student health insurance went up from about $1200/year to $4000/year over that four years). I had a lot of other expenses, mostly medical, that I couldn't pay for just out of my grad student stipend either. So while a CS Ph.D program may seem like it's not going to cost you anything, you also have to think about the opportunity cost of spending 4-10 years making $15K-$25K/year, most likely with no benefits (since RAs and TAs at many schools are hired at 0.45 FTE so the university won't have to give them benefits -- the exception is schools where RAs and TAs are unionized, which anyone looking to go to grad school should seek out). Especially for CS majors, those 4-10 years could be critical in your career -- people who don't go to grad school spend them developing and gaining experience that you're likely going to have to start over with anyway if/when you leave or graduate and can't or don't want to work in academia.

I agree that being your own boss is very appealing, and it's a big reason why i once wanted to be a professor. But it's not quite right to say that professors get to decide what they work on, and especially not grad students. Applying for grants limits what you can work on and also means you have to do a little or a lot of "spin" to make your work sound like something that will "help the war fight" (at least if you're applying for defense funding, which is what a lot of CS funding is). For some people, this may feel dishonest.

Teaching and mentoring are also appealing. There are many jobs that have mentoring as a component.

I think there should be more women in CS, but I also wouldn't want to make any individual woman deciding on a career feel like she *has* to do something that's difficult, costly (financially and emotionally), and will likely expose her to various kinds of harassment just to further the cause of equality. Ultimately, it's men's job to stop driving women out of CS.

In the end, I think if somebody reads all of this stuff and makes an informed decision that they still want to go to grad school, then they should go. That's why I went, two separate times! I won't exactly say that I wish I hadn't, but I also wonder how it could have been if I had spent those years working on projects with clear goals and expectations where I would have been compensated fairly.

A comment on a post I can't link to (friends-only), but that basically compared certain recreational programming language conferences to church, reminded me that I stopped being an atheist right about the same time as when I started to stop worshiping CS, hackers, and hacker culture. Funny, that.

This is the last part in a 4-part series on impostor syndrome. (Part 1; Part 2; Part 3)

Conclusions

At this point, I know someone will ask: "what could computer science departments do differently?" Well, more involved advising and mentoring would be a great start! That is, it isn't enough for an advisor to just say "come by if there's anything you need", because if you have impostor syndrome, you may not know what you need and you certainly won't want to admit that you need help. What if departments expected advisors to be ready to support all grad students, not just the ones who look exactly like themselves? This isn't to say that every faculty member can or should try to be an expert on every identity, but knowing what they do and don't know would be a start. Any outright acknowledgment of impostor syndrome would be a great start too. At Berkeley, there was nobody who stood up and said that most of the time when people look like they know what they're doing, they don't. I'm not sure I would have believed it even if they'd said it. Oh, sure, other people might be fumbling, but not as fumbling as me. We did have a required class on teaching techniques at Berkeley, since all grad students were required to TA for at least one semester -- in my head, I called the class "Geek Support Group", but it was actually really helpful because it was one time during the day when we got to put aside the pretense that we were all rational beings made of pure logic. So maybe a required class on how to be a grad student would have been helpful (required because I suspect the very people who needed it the most would have brushed it off if it was optional.)

Encouraging socialization in a way that includes everyone would also be helpful. Of course, most departments already have social events. In my department at Berkeley, when I was there, the CS grad students' group organized a weekly reception. However, faculty members rarely attended; the professor who I saw there most frequently seemed to stay just long enough to snag some free food. I was part of the CS grad students' group at Portland State, and over time, students stopped attending our events, even when we offered free food; it's not clear why. In contrast, in my ex-partner's department at Berkeley -- mathematics -- the department had a tea/coffee hour every afternoon, which a department assistant organized (the job wasn't pushed onto students) and was very well-attended by both students and faculty. Just having social events is not a be-all and end-all, since some students won't feel comfortable in large groups and some people always get left out, but it's a start. Of course, offering free food can help, and provides an excuse to go for someone who is reluctant to socialize.

( Read more... )

This is the third post in a 4-part series about impostor syndrome (Part 1, Part 2). Check back tomorrow for the conclusion!

Self-Deportation

When a department admits students from "minority groups" but doesn't do anything to address impostor syndrome, how different is that from categorically rejecting everyone who isn't a het cis able-bodied white man from an middle- to upper-class background? This way, the administration gets to boost their diversity numbers and gets plausible deniability when those students (as it were) "self-deport". "We tried to admit women and students of color, but they just didn't like it here! They must just not be interested in science." As if interests are developed in social isolation and don't depend on a network of social support telling you -- implicitly, usually -- that you belong. It's not as if everyone who's in a minority group experiences impostor syndrome, but the experience of someone who gets treated like they belong and someone who doesn't is so different that I don't think it's too strong to say "you might as well just reject everyone". I also don't mean to say that diversity decisions always get made in bad faith, but I've had some personal experiences that make it difficult for me to believe that there is any genuine institutional commitment to diversity at the universities I've attended.

In my experience, it seems that being told you're welcome and that you belong is sort of like water if you're a fish: when you have it, you don't notice it. It's only when these things are absent that you do notice. I blamed myself for their absence, because that's what I've always been taught to do. I attributed my failure at Berkeley to my own incompetence, and it didn't occur to me until years later to think about how my environment contributed to my failure to thrive there. I got ignored. The other grad students in my group and cohort socialized with each other; I just got left out. Since I was being perceived as female at the time, I think this had something to do with the fact that I was perceived as not a peer (because I wasn't male) and not sexually available (since I was married) -- therefore, to most of my fellow students, I was useless.

( Read more... )

This is the second post in a 4-part series about impostor syndrome (Part 1). I'll be posting one installment per day.

Berkeley 2001-2003

"it's cool to discover someone
it's hard to support them
everyone is playing life
like it's some stupid sport"
-- Ani DiFranco

As for most new Ph.D students in the US, my first year at Berkeley consisted mostly of coursework, and that was what I was used to, so for the most part it went smoothly. At the end of the year, it should have been a warning sign when nobody wanted to be my advisor. One professor I talked to -- the one I'd mentioned in my statement of purpose as who I wanted to work with, and who encouraged me to come to Berkeley when I visited during prospective student day -- said "no" outright, saying he wasn't interested in what I wanted to study (functional programming languages). Another one didn't say no, but had a reputation of being someone who didn't answer email; I was hoping for someone who actually seemed interested in having a student. I ruled out two more professors who seemed close to retirement, and one more because she did scientific computing and that pushed my "I went to a liberal arts school and don't know anything" buttons too much. I ended up with an advisor who told me he was willing to advise me, but given what I was interested in doing, he wasn't going to be very involved and he would basically just be there to sign paperwork. At the time, I thought that was fine. Remember, I didn't like talking to people. I thought I would just work on my own, and that would be easy. Easier than getting up the courage to talk to somebody, anyway.

Later on, I saw it as a personal mistake to have chosen this advisor rather than looking harder for a more involved advisor, or even changing research areas. But part of why I made that decision was structural. I was socially shut out, as I'll discuss, which meant that I wasn't getting any tacit knowledge that would have helped me understand that I did need an advisor who was involved. I know this is a structural factor and not a personal issue because Barbara Lovitts talks about it in her book Leaving the Ivory Tower. That is, she discovered that a major component of grad students' success or failure is the extent to which they can use informal social networks to attain the tacit knowledge that's essential to completing almost any graduate program; faculty and staff rarely communicate this knowledge to students in any systematic way. Official lists of graduation requirements stick to course requirements and the specifications for what constitutes a dissertation -- they don't talk about the unofficial things, like having an advisor you can work with (and who has time for you) and which advisors are likely to be compatible with which kinds of people. Thus, people who find themselves misfits and outsiders in the (figurative) lunchroom in any particular department tend to get pushed out, even if they're just as able as the insiders to complete the academic requirements.

So here's where my impostor syndrome really began. ( Read more... )

This is the first post in a 4-part series about impostor syndrome. I'll be posting one installment per day.

"Compare the best of their days
With the worst of your days
You won't win..." -- Morrissey

I can't remember exactly when I first encountered the term "impostor syndrome", but I know I was less than ten years old at the time, and I know where I read about it: a book called The Gifted Kid's Survival Guide. I don't think it made much of a mark on me. And knowing what it was early on didn't stop me from developing it later.

This essay is about my experiences with impostor syndrome. One of the reasons why I want to talk about these experiences is that I had them while most people in the world were seeing me as female, though I'm not female. Sometimes people tell me that my experiences are un-representative (of, I guess, anyone except me), but I think they're wrong. My experiences represent those of one person who spent 26 years moving through the world while generally being perceived to be female, albeit (often) gender-non-conforming. I say this not to lay claim to any sort of female socialization, which I didn't have; or to deny that I have male privilege (and probably had some even before I knew I was male); but because if I can say something that helps people understand what cis and trans women, as well as many trans men and genderqueer people, face in trying to find a place for themselves in male-dominated spaces (which is to say, in the world), I want that message to be understood. At the same time, I'm speaking from my position as a white trans man who doesn't have visible disabilities, was raised lower-class, and has a graduate degree and works as a software engineer. I've had it harder than some people and easier than many others, if it even makes sense to compare.

Ideally, I would like to change how historically male-dominated institutions -- specifically in this essay, computer science graduate programs -- try to integrate and welcome women as full participants. While one little blog post can't change the world, it might show a few people that the situation isn't as simple as it may look, and that has ripple effects. So I'm simply going to recount my personal history as a non-traditional learner, then undergraduate, then graduate student at Berkeley, and wherever possible try to draw connections between my experiences and larger social structures. If you remember nothing else from this essay, I hope you remember that when grad programs admit more women as students, it's not enough: to do so without extra attention to structural inequalities sets these students up for failure and actually reinforces sexism. I'll elaborate on that point in the rest of this essay.

( Read more... )

From a closed-forum reply to this link about casual misogyny and othering in the tech community:

"Why. WHY does this ALWAYS happen in CS courses??

In college my data structures professor used pictures of the following to examplify members of the class "Object", over and over again throughout the course:

A Lamborghini Diablo

A mug full of beer

A flat screen TV

Salma Hayek

headdesk"

(By the way, when I was majoring in computer science at a historically women's college? None of my professors used such examples. Just sayin'.)

"...programming without loops and variables sounds as weird to me as doing maths without numbers..."

"...ML is a functional programming language, used mainly for mathematical algorithms and such like."

(Undergrads trying to understand programming languages are like dogs trying to understand quantum mechanics.)

I think next time I give a talk, I'm going to hold up a baby and say, "This baby doesn't believe in uncertified compilation. This baby wants type safety. This baby doesn't want to use an unverified garbage collector. This baby wants strong guarantees that her reasoning about the code she writes also applies to the code she executes."

Does anyone have a baby I can borrow?

A blog comment in response to an argument that writing a parser for Perl is Turing-complete:

"That's some mighty fine left brain thinking there( especially for a Monday morning ), but does it in anyway affect any practical aspect of Perl? Like can it be used to show that Perl is more or less reliable/secure? This isn't a criticism of your node, but I left college 35 years ago, and this sort of analysis seems very ivory-tower-ish to me now. It's sort of like saying 'one cannot prove self-existence'. Is the fact that Perl cannot parse itself a good or bad thing, or can other languages do it? Does that make them superior?"

Computer science is an intellectual and pragmatic failure. Kids, if you're looking for a good career, major in English.

S	M	T	W	T	F	S
	1	2	3	4	5	6
7	8	9	10	11	12	13
14	15	16	17	18	19	20
21	22	23	24	25	26	27
28	29	30

Tim's journal

Taking metaphors too far since 1995

Language and trade-offs

You're invited to apply for the 2015 Ally Skills Workshop, to be held at ICFP in Vancouver, BC

Paul Hudak, 1952-2015

CUFP notes, 2014

A random comment about math and programming

Computer science grad school

(no subject)

Impostor Syndrome: Part 4 of 4

Conclusions

Impostor Syndrome: Part 3 of 4

Self-Deportation

Impostor Syndrome: Part 2 of 4

Berkeley 2001-2003

Impostor Syndrome: Part 1 of 4

headdesk

Things you find when googling for other things

Sometimes you can learn something from Republicans

Why the software industry is morally bankrupt, volume #0xDEADBEEF

Profile

November 2021

Links

Syndicate

Most Popular Tags

Page Summary

Style Credit

Expand Cut Tags