A humane Real Names Policy

I found myself with occasion to tell the same story multiple times in the past couple of days, so it seems appropriate to publish it somewhere for easy reliable reference:

Years ago at a programming language conference, I finally met in person someone I’d interacted with regularly on IRC and Twitter. In those contexts, he used a handle of his choosing, and naturally, everyone referred to him by it.

I noticed that everyone was addressing him by his initials. I played along, but eventually asked him directly — in a minute when others were occupied elsewhere — if the use of his initials was his choice.

You see, my friend was from Elsewhere: the conference was in the U.S., while he and his name are not “American”, nor Western. Many people seem to balk at saying names that they are not already familiar with, either because of pronunciation anxiety, or much less benign reasons. Dale Carnegie is often quoted on this topic, so I might as well follow suit:

Using a person’s name is crucial, especially when meeting those we don’t see very often. Respect and acceptance stem from simple acts such as remembering a person’s name and using it whenever appropriate.

So, I asked, and my initialed friend indicated that he’d prefer it if I used his given name when speaking with him, but that it was apparently tough for some to pronounce. I asked him to say his name a couple of times, I got it right on my second try, and I used his name as he preferred it in every interaction we had thereafter. It wasn’t hard, and he seemed glad that someone was willing to take 60 seconds to show him that respect.

This is simple stuff that is easy to get right and costs nothing.

Some obvious corollaries to the above story:

  • Always address people by the name that they prefer. (Everything else follows from this.)
  • Default to their given name if you know it, but don’t deputize yourself as proxy of whatever faceless bureaucracy stamped their birth certificate.
  • Don’t be so lazy as to let your own bias — cultural, geographical, or linguistic — prevent you from respecting someone else.
  • None of this changes online: if someone has chosen a name for themselves in some context, use it to refer to them. It is especially careless to refer to someone in one channel by the name they use in another.

Someone’s “real name” is whatever they say it is.

I built an app to save my Mom’s life

Republished from https://www.homehelpstatus.com/posts/2015/08/19/i-built-homehelpstatus-to-save-my-moms-life.

Legend has it that many (most?) people that start a software business, launch an internet site, or create an app in the modern era are looking for a big payday. That may or may not be true, but I know that, when I set out to create what would eventually become HomeHelpStatus, I did so for one reason: I needed to save my Mom’s life.

This sounds like hyperbole, but it’s not. As I’ve written before, my Mom has advanced secondary-progressive Multiple Sclerosis (MS), a degenerative neurological disease that is symptomatically similar to ALS. In my Mom’s case, MS has left her quadriplegic with a host of “secondary” conditions, such as limited respiratory capacity.

As her condition worsened over the years, she became more and more dependent upon her home care workers, which we call PCAs (Personal Care Assistants; other terms like Home Heath Aide [HHA] are used as well). This has mostly worked out well; without their help, my Mom would not be able to live at home.

…a caregiver not showing up for their scheduled visit could result in my Mom’s death.

The problem is, sometimes things happen. People get flat tires on the way to work. Their child is significantly injured, and they can’t come in. Sometimes (thankfully, very rarely) PCAs we’ve trusted have ended up not being reliable, not showing up for work when scheduled for little reason.

This is generally not a serious problem in other healthcare contexts. For example, a nursing home, clinic, or group home will typically be staffed by a multiple people at any given time; one or two people being absent there will be inconvenient, but usually not an emergency. However, in my Mom’s case, she only ever has one PCA scheduled at a time (a constraint understandably enforced by the government agency that thankfully pays for her home care).

So, when someone doesn’t show up when they’re scheduled, my Mom isn’t just inconvenienced: she can’t eat; she can’t drink; she can’t go to the bathroom; she can’t take her medications. This last fact is particularly problematic, as some of her medications must be taken rigorously, at the same time every day, or very bad things can happen. There have been times when a PCA not showing up has resulted in an emergency room visit for my Mom…that is, once a PCA shows up for the next scheduled visit, or me or my Dad discover what’s happened.

Once I drove over to her apartment after calling a dozen times over the course of an hour or two, only to find that the phone cord had accidentally been yanked out of the wall.

As you can imagine, such situations are horrible experiences. And as terrifying as it might be, it’s not hard to think of scenarios where a caregiver not showing up for their scheduled visit could result in my Mom’s death.

Knowing this has for years resulted in a sort of mild, gnawing worry: around the times caregivers were supposed to be arriving, I’d look at the clock and wonder, “Are they going to show up?” I’d debate with myself about whether to call over and confirm. Sometimes I would, and sometimes the phone would just ring and ring. Are they just a little late? Are they busy? Did my Mom send them to the store for something? Or, are they not going to show up at all? Once I drove over to her apartment after calling a dozen times over the course of an hour or two, only to find that the phone cord had accidentally been yanked out of the wall.

Earlier this year, I knew I had to do something, but no obviously good options presented themselves:

  • Caregiver check-in services did exist, but they were built for organizations like home care agencies that had dozens of staff, and cost $1,000’s just to get started. I found nothing suitable for individual and family use.
  • Informal check-in services also exist, but they’re largely intended for families, e.g. so teenagers can let parents know where they are. While we aim to hire trustworthy people, I wanted to know for sure that caregivers were actually at my Mom’s apartment, and not checking in from their phone from wherever. Trust, but verify is an apt proverb.
  • Emergency call services like Lifeline are available, but my Mom simply isn’t able to operate the switches or even blow tubes you can use to trigger them. Also, we don’t need EMT calvary rolling in when a caregiver doesn’t show up; knowing that that’s going to happen actually discourages the use of things like Lifeline.

What I wanted seemed very simple:

  1. A way for caregivers to check in from my Mom’s apartment in a verifiable way (by phone using caller ID or maybe using a mobile app that used GPS to verify presence).
  2. When a caretaker doesn’t arrive within some minutes of when a visit is scheduled, I want to get a text message or phone call so I can do whatever is necessary.

I don’t have to worry anymore about whether she’s being cared for.

Thankfully, being a reasonably competent software developer, I built this. It’s worked wonderfully for my Mom for some months now: when a PCA has very occasionally been running late, I get a text message, and my Dad gets a phone call. PCAs now also check in when they’re departing at the end of their visit, so a nice side benefit is that I now have access to a complete in/out log that I can use to verify their pay (and thus protect the hours of care that my Mom is allotted).

I don’t have to worry anymore about whether she’s being cared for. And, if I do feel a flutter of paranoia, I can just go look at the checkin log in 10 seconds and be reassured. More subtly, my Mom doesn’t worry about what will happen the next time someone is late or doesn’t show up.

But, most importantly, I know my Mom will never be in danger again, when someday a PCA really doesn’t show up again. It’s not glamorous, and it’s not technically boastful, but the code and system that enables this may be the most important I’ve ever written.

Other people, maybe many others, could get the same benefit from it that I and my family have. I know I wish I had had something like this when my grandmother was getting some minor home care some time ago: she remains in good health, but is the sort of person will say “I didn’t want to bother you!” when you find out that the aide didn’t show up the week before, but didn’t call anyone.

So, I’ve done what I can to make it as easy to use as possible; this is what HomeHelpStatus is today. Please pass it along if you know someone that might find it useful.

Living with yaks

A “yak shave” — the performance of a task solely in order to continue one’s “real work” — has traditionally been a pejorative term in the software and programming world. Much like “real life” yak shaves (fixing the garage door so you can get the car out so you can go to the store so you can make dinner, each task discovered only in service of the one it depends on), shaving programming yaks is typically not considered enviable work. It’s all stuff you reluctantly attend to in order to get on with the thing you wanted to do in the first place.

Such a perspective makes taking stock of my professional life an equally grim business: the overwhelming majority of my technical work has been in shearing wooly yaks, some more cleanly than others: vast savannahs of code for extracting data from PDF documents, libraries for authentication and authorization, AWS APIs, byzantine dependency resolution, and teststeststests; then there’s tools everywhere I look, including more REPL guff than you can shake a stick at, contributions to programming languages, and too many little bits of glue code to enumerate in any comprehensible way. (Let’s not speak of yaks kept away from the harsh lights of github and open source in general.) All of this was done in order to do other things. More often than not, I’ve let my hands linger far longer than necessary on those shears, rarely ever moving on to my original plans and projects.

Being busy is the most perfect form of procrastination, so that’s one explanation. I also think the yak-shaving tendency is an affordance of modern programming, with its deep cravasses that are sooooeasy to slip into, only to emerge 15 years later with a lot of experience in SOAP and WS-$WHATEVER. Why did I learn about OpenId in the first place? No one knows. Why do I still remember the Swing APIs with such exactitude that I’m confident I could knock out a moderately-complex Java GUI without looking at docs? Please, let me find blissful forgetfulness.

It’s too easy to gripe and grumble about this, though. We all have this experience of yak shaving, and occasionally regret for the time spent with such noble creatures, but I now think it’s disingenuous to lament. These computers we pound and tap on are things of our own creation: we choose our own legacy through our use and abuse of them.

When I look back on the computering I’ve done, I’m much more forgiving of my follies than I used to be. I can’t say I’ve accomplished what I originally set out for myself; but then, I can’t judge the work that was done too harshly, either. Most of it works well, most of the time, and many have found good use in it. I can’t ask for too much else, and I think I see now that hardly any other programmers (and perhaps, any other creative folk in general) are any different in this respect: we all struggle with whether we did good work yesterday, whether what we’re working on now is what we want to be working on, and whether it’s a stop on our path to something else, or a place where we might rest for a while.

Being at ease with this ennui puts the long years I hopefully have ahead of me in a much more pleasant light. It’s easier to be more thoughtful about the work I plan for, as well as more forgiving of the yaks that lay in wait for me along the way.

I talked about all of that so I could tell you a little story:

While idly twittering recently, a friend asked if I was talking about one of my “pet” yaks (I keep a number of forever projects around the house, their foraging is good for the lawn and they keep critters at bay):

The idea and visual of a World Yak stayed with me. Half-serious as it is (anyone even vaguely familiar with the workings of these stupid machines would recognize the truth in the sentiment), I couldn’t stop giggling about the visual. I eventually commissioned a wonderful artist to bring the meta-yak to life:

meta-yakI don’t know what exactly I’ll do with this burdened animal, but metayaks.com and @metayaks is a fun start.

Empathy and optimism

When talking with others over the past year or so, I’ve occasionally mentioned how I’ve been “working on my empathy”. This usually prompts confused, awkward moments, but I’ve meant it wholeheartedly. The most basic way I’ve found so far to describe what this means is I’ve been attempting to be as mindful as possible in my interactions with others, and in my apprehension of their stories and personal testimony. My objective isn’t just to comprehend what I’m reading, watching, or being told, but to do my best to re-experience, at least as much as is possible within my own head.

(Amusing, telling anecdote: after watching an “original series” Star Trek episode [or maybe it was an early movie?] featuring Spock successfully suppressing his baser human and Vulcan impulses, I said to my mother, “Wouldn’t it be great if we could all be like that?” She told me years later that my posing that rhetorical question worried her deeply for some time afterwards.)

Far from some kind of wispy daydreaming exercise, this is a laborious process. Since our phenomenology is apparently automatic (“System 1” thinking, in Kahneman’s terminology), assessing the uncountable set of signals and flashes that makes me feel like me is effortless, an instant-on flow state. Working on appreciating others’ experience as more than an abstract intellectualization of circumstances demands the careful, conscious construction of a completely different mindset, replacing as much of the sinewy underpinnings of my own identity as much as possible, and allowing myself to slip into the result like a bath filled with ice water.

Working on being empathetic in the way I’ve described is intense (how could it not be?), but one of its more surprising effects on my day-to-day life has been how it’s challenged my bias towards optimism. This bias has many roots; an impartial list might include the doctrine of American exceptionalism that I’ve been steeped in all my life; pop culture history of western society and technology that usually generalizes into a vector of ever-improving conditions for humanity at large; and my engineering and creative profession that is premised on the notion of individuals and small collectives being able to affect significant, tangible positive change.

There is truth in these influences, but each is a narrative better suited to providing comfort than actual enlightenment, like a fluffy, cozy blanket, so frail that the smallest poke or stretch yields a hole. The American project has always been fraught, its history pocked as it is with us repeatedly, collectively falling short of its promise. The postwar narrative of societal progress largely marks time on the backs of people overcoming adversity, usually spending far too little time on the fact that those adversaries should have been their brethren. The software engineering world I inhabit traditionally espouses a strictly technocratic problem-solving approach, fabulously appropriate when one’s objective is to build a bridge, but yielding catastrophic (yet ironically, invisible) consequences when applied to qualitative effect.

I knew all of this before, in the same way that I had previously coldly intellectualized others’ experiences. But the more I “worked on my empathy”, the less I could wave at the footnotes to my optimistic bias as incidental, temporary hiccups on the way to The Future, akin to having to break a few eggs in order to make an omelet.

In hindsight, this isn’t surprising: being as fortunate as I am, being empathic inherently requires trying to inhabit the stories of people that are or have been less so. Getting even a hint of the experience of people that have been failed by the American ideal (whether on its shores or abroad), people that are or have been treated as sub-human by their neighbours, people that have been ignored or personally injured by well-meaning but narrow-minded technologists…this made me question deeply those beliefs that previously sustained me so reliably. It seemed my optimism was a false idol, and I was despondent for a while.

What broke the malaise was my returning to the stories of people that embodied an eyes-wide-open sort of optimism, and trying to capture some of what made them push forward. Martin Luther King, Jr. remains front-of-mind for me, especially his last speech at the Mason Temple in Memphis on April 3, 1968 (multipart video), popularly remembered as ending with King prophesising his assassination the next day. Much of the speech is occupied with the particulars of that time and place, but some other passages spoke to me. In particular, King talked about the parable of the Good Samaritan, emphasizing the exercise of empathy in performing good works:

He got down from his beast, decided not to be compassionate by proxy. But he got down with him, administered first aid, and helped the man in need. Jesus ended up saying this was the good man, this was the great man because he had the capacity to project the “I” into the “thou,” and to be concerned about his brother.

And later:

And so the first question that the priest asked, the first question that the Levite asked was, “If I stop to help this man, what will happen to me?”

But then the Good Samaritan came by, and he reversed the question: “If I do not stop to help this man, what will happen to him?” That’s the question before you tonight.

Here Dr. King is imploring Memphis’ black community to stand together, and not just pass on by those among them that needed aid. I found the fact that he felt the need to do this remarkable; a modern reader or listener might think that, in that time and place, poor blacks would do anything to support each other, but doing so was itself an act of protest, carrying risk to prospects and body. In the scheme of things, Dr. King’s plea here was both critically important and an incredibly modest goal relative to his broader cause, but he agitated for it with all the vigor and determination he exhibited when discussing his grandest visions of peace and equality among races. His solemn, unyielding commitment to an unlikely cause even when facing his own demise overwhelmed me.

Now when I think of “real” optimism, I think of projects that demand a compassionate perspective, and recognition of those most different than I as my kin. It is our flawed human nature that such projects are more likely to fail than they are to succeed, their objectives so lofty and their opponents so tawdry and powerful that simply having an opportunity to work another day is a step forward: the Good Samaritan may just as well have been betrayed by the man on the road, who could have been luring him for ill cause, just as Dr. King was ultimately betrayed by his neighbours even while he worked towards ensuring that his country fulfilled the ideals it set out to live up to centuries prior.

We live in brighter times today, and so it is harder to see the stars. Maybe this is why I was lulled into adopting a triumphant, up-and-to-the-right flavour of optimism, a just-so Schoolhouse Rock tune of potential and incessant progress that is easy to bop to but impossible to build upon without maintaining an improbable naiveté. By working on my empathy, I feel like I have finally learned what optimism looks and feels like, and simultaneously gained the tools to practice it, too.

My Mom has Multiple Sclerosis, and needs a new wheelchair van

My mom has been battling secondary-progressive Multiple Sclerosis over the last 30 years (I’ve written about her a bit before). Over that time, she went back to school in her 30’s and graduated from the University of Massachusetts, worked as a substitute teacher and home health aide, and raised a son throughout. Unfortunately, she’s been quadriplegic for the last several years; despite this, she lives at home with the help of family and a number of personal heath aides, and maintains an independence and level of energy inspiring to everyone around her, even managing to continue pursuing her greatest passion, writing, now about her day-to-day experience living with MS.

Her current wheelchair van is shown in the photos below. While it’s never been much to look at, it has over the last 10 years been essential in allowing my Mom to go about living her life to the fullest: enjoying concerts and movies, going shopping for food and clothes, seeing doctors of all sorts, and visiting family, especially her mother and her new grandchildren (twin girls, if you hadn’t heard :-)).

This slideshow requires JavaScript.

The van was already very used when it was purchased, but my father (a skilled auto mechanic) has thankfully been able to keep it in reasonable running condition. It’s at the end of its road now, though: it needs a new transmission (it can’t go in reverse anymore!), the air conditioning has failed (a serious thing during the summer for someone with MS), and the body has rusted beyond any hope of repair.

So, my mom needs a new wheelchair van. To make this possible, we have set up a fundraising page, aiming to raise $10,000:

We hit our fundraising goal! Read the updates below…

Brand-new wheelchair-accessible vans often top $30,000, but we don’t need anything so fancy. We’re looking to purchase a new-used van in good shape that will last for a long while. We don’t have a particular van in mind yet (though we have been keeping an eye out), so the exact cost is not entirely clear yet. If any funds are left over after purchasing a van, they’ll be used to defray the costs of insurance, taxes, and repairs over the coming years.

(It kills me that I can’t simply take care of this myself without such a public appeal; while my wife and I will absolutely be helping her with this purchase, the realities of recently having bought a house and having twins makes doing so on our own impossible at the moment.)

I, my family, and my mom will be grateful for any little bit you can spare to help!

Update 2015-03-22

My mom’s birthday was a few days ago, but we all gathered to celebrate today. She knew about the fundraiser before, but didn’t know how far we had gotten until this afternoon (60% toward our goal!). She wanted to record a few words to pass along to everyone that had helped so far, whether by giving generously, or sharing the fundraiser via Twitter, Facebook, and other channels:

Update 2015-03-25

In just four days, we’ve reached the goal for our fundraiser! It will be hard to sufficiently thank everyone that helped, either by donating, or by sharing the effort with others on Twitter, Facebook, etc. I’m incredibly grateful to the various communities that pitched in, moreso than I can readily express at the moment. Of course, my mom is similarly amazed, and looking forward to being able to get around far more easily and comfortably!

We will be shutting down the fundraiser properly later today, pending tying up a few loose ends with the site that’s hosting it. We’ll also be periodically putting out updates, especially once we have found and acquired a suitable van.

Thank you so, so much. <3

Distributed Systems and the End of the API (meta)

I just published a written distillation of my talk at PhillyETE 2013, Distributed Systems and the End of the API, over at the “writings” blog for the Quilt Project.

Take a look, especially if you are interested in distributed systems, CRDTs, the general suckage of how APIs work, or if you’re curious about what this Quilt thing is all about. (Spoiler / hint: the talk+post isn’t strictly about Quilt, but is very strongly related.) My inspiration for writing up the content of the talk comes largely from Michael Bernstein’s writeup of his RICON West 2013 talk, Distributed Systems Archaeology. Giving talks can be a compelling way to spread information and evangelize different (and hopefully better!) ways of thinking about problems, but depending on slide decks and video dumps is a poor way for people to discover and access that information. Giving it a proper home that is easily searchable and accessible to all (despite visual-, aural-, attention-, or time-related disadvantages) seems to be a total win, especially if one is hoping to have a lasting impact.

My apologies for the piece being so long (~7,250 words). I really didn’t want to disturb the single narrative, and so resisted splitting it up onto parts. Hopefully the length does not detract from the message. It’s very clear that my biggest failing as a writer remains my verbosity, something I’ll be watching closer than usual for the rest of the year. It would not hurt to work on more tightly-scoped, concise pieces, if only to be able to put some bounds on the time spent on the writing itself.

Theorizing the Web, an experience

Last week, I attended Theorizing the Web (TtW). I can say without hesitation that it was one of the most challenging, enlightening, and useful conference experiences I’ve ever had.  I’d like to provide a summary account of my experience, and maybe offer some (early, I’m still processing) personal takeaways that might be relevant to you, especially if you are involved professionally in building the software and technology that is part of what is theorized at TtW.

The first thing you need to know is that TtW is not a technology conference. Before I characterize it positively though, it’s worth considering the conference’s own statement:

Theorizing the Web is an inter- and non-disciplinary annual conference that brings together scholars, journalists, artists, activists, and commentators to ask big questions about the interrelationships between the Web and society.

While there were a few technologists in attendance, even fewer were presenting.  As it said on the tin, TtW was fundamentally about the social, media, art, legal, and political aspects and impacts of the internet and related technologies.

Before I enumerate some of my highlights of TtW, I want to offer some context of my own, a thread that mostly winds around:

Why did I go?

As a guy that creates software professionally, I have historically been fundamentally unconcerned with how what I build interacts with and is informed by the non-technical, those obfuscated social and political and higher-order economic forces and undercurrents that define how we interact and relate to each other.  In the typical engineer (and business owner) role, I have generally sought to optimize strictly for utility.  It’s not that what I’ve built has necessarily been to the social, political, or economic detriment of others; it’s that I’ve very rarely thought of how what I build defines and is defined by those forces.

In hindsight, that I developed this blind spot is surprising to me.  I received a fundamentally non-technical education at very liberal liberal arts college in New England, and so was aware of these topics to some degree in an academic setting and very personally, having come from a working-class family of little means compared to my peers. (I vividly recall being gobsmacked by the casual just-so way in which some other students talked about the Benz and Beamers their parents sent them off to school with.)  Further, I have always been politically active and consider myself to be socially and culturally aware (though, don’t we all?).

Nevertheless, that academic background clearly did not insulate me from the inuring socialization in a engineering culture. Part of the process of being “professionalized” within the software business and engineering practice was being trained in the often explicit denial of the political and social nature of our work. The manifestations of this are seen everyday online and in in-person dialogue, including adopting a live-and-let-live stance with regard to blatantly exploitative internet businesses and technology; minimizing the impact and importance of non-technical collaborators whom we rely upon or non-technical work we do ourselves in order to succeed; and dismissing by default any technical decision that is not made on strictly technical grounds.

To summarize, I’ve recently had two (related) realizations:

  • I find myself working within a community whose collective discourse is one where technical optimality is paramount and prioritized, even when non-technical concerns are known.
  • I personally have historically not given due consideration to how what I build is affected by its (and my) social, political, and economic context, or how what I build in turn affects others.

These things dawned on me over an extended period of time as I contemplated the full scope of Quilt (my current project).  While it is a software project with a technical footprint — it will manifest as code and libraries and tools and services — my objectives are fundamentally non-technical, and rooted in non-technical impacts of existing software and technology.  Considering that prior to this realization, I thought Quilt was a purely technical response to set of purely technical problems, this was a cognitive break on the order of nothing else I’d experienced before.  The obvious conclusion was that, to be successful, I must purposefully locate Quilt with respect to those powerful undercurrents that dictate the human condition. What I wanted to do was defined in large part by exigent sociological, economic, political, and legal forces, and the product of that work would hopefully have an impact on them in turn.

Once internalized, it was clear that my context and professional history guaranteed that I was not yet properly equipped to thoughtfully approach these questions.  So, just as I’ve been pushing myself to bone up on certain scholarly corners of technical domains, I started seeking out ways to become more aware of and attuned to the non-technical influences on and impacts of my work.

Attending Theorizing the Web was just the latest chapter in that effort: here was a gathering of mostly non-technical academics, educators, activists, and other commentators talking about how people are using, benefiting from, coping with, and being victimized by internet technologies and their applications. I wanted to gain their perspectives for exactly the reasons why I suspect many of my peers might discount them.

With that out of the way, on to some highlights and related thoughts.  There was much, much more to take in at TtW than I can or will make mention of here. Residuals of the streaming process are available for viewing now; it looks like each session is going to eventually be published on the TtW YouTube channel.

People are dying online

Though I was enthusiastic about TtW in principle, there’s always a degree of apprehension upon stepping into a new conference.  Thankfully, the very first session I attended put any unease I had to rest. “Small Data: Big Trends in the Little Ns” was a collection of four talks by investigators who decided that the best way to usefully study their subjects was by direct interview, observation, or analysis of data from very small cohorts.  The point here is not to gather statistically significant findings; rather, my read of the methodologies discussed by the speakers were aimed to allow for the development of a narrative around the particular social experiences being studied.

(I personally draw a connection between these sorts of inquiry and the use of inductive or intuitional reasoning of issues in mathematics or programming vs. the use of mathematical formalisms. Social narratives and inductive methods — at least in my experience — yield personal understanding, whereas statistical social inquiry and formal proofs often do not.)

Anyway: two of the presentations were particularly impactful for me, and both of them were centered on death and how expressions of grief manifest in online fora.  Molly Kalan focused on Facebook memorials (including pages of the deceased themselves, maintained and retained online as one might maintain a grave or shrine), while Timothy Recuber presented a curation of suicide “notes” left online.

The most intellectually fascinating part of Molly’s presentation for me was her discovery that there was an implicit social hierarchy that affected how people expressed their grief online.  That is, if someone “closer” to the deceased publishes a long, heartfelt eulogy, people that are less close (say, a work acquaintance vs. a close friend, or a cousin vs. the deceased’s mother) will try to calibrate their expressions of grief online to be shorter, less forceful, and essentially deferential to the closer party.  Even more interesting, when this hierarchy is violated (e.g. when a cousin publishes a more intense eulogy or memorial than a widow), both parties involved as well as third-party observers reported discomfort with the transgression.

Now, totally aside from the intellectual stimulation, the raw stuff of Molly’s presentation were examples of memorials from Facebook as well as individual stories of grief.  This was sobering and emotional, but that simply set the stage for Timothy’s study of online suicide “notes”.

Of course, once people were able to write things online and have them viewed by others, it was inevitable that such capabilities would be used by some to leave suicide notes rather than “classic” notepad, typewriter, and other printed methods.  But, I was unprepared for one of the centerpiece cases in Timothy’s study, that of Martin Manley’s suicide note.  Martin, an accomplished sportswriter and statistician, killed himself with a handgun on his 60th birthday. But, before doing so, he published his suicide “note”: a dedicated website containing dozens of pages of autobiographical detail, apologies and farewells to loved ones, extensive discourse on his rationale for suicide, and various social and political commentary.  Timothy’s presentation of Martin’s “note” took me totally by surprise; combined with the previous discussion about memorials, I had a very hard time keeping it together. At least I wasn’t the only one in the room that was so affected!

There’s a Mitch Albom quote on one page in Martin’s “note” that I think appropriately sums up the presentations on death and online memorializations:

Death ends a life, not a relationship.

While memorials have traditionally been fundamentally token reminders of loved ones lost, newer mediums make it possible for memorials to be ongoing, continuing relationships with the departed, in dynamic (and thus, sometimes uncanny and disturbing) ways. As such media are likely to become more and more sophisticated, it seems that the above quote will become less and less metaphorical as time passes.

I managed to snag Molly for a couple of minutes to ask her if the subjects in her interviews seemed aware of the potentially (inevitably) ephemeral nature of the memorials they were creating, given that Facebook is the steward of the data underlying those precious eulogies and memories. Her answer was that while some people did want to retain a personal copy of parts of loved ones’ memorials, basically none of her subjects appreciated the fact that those cherished artifacts were retained at Facebook’s discretion (and therefore, at the discretion of its investors, the market’s, etc).  To them, Facebook provides permanence.

This is particularly ironic given that Martin Manley’s note — the publishing of which he arranged through one of Yahoo’s services andpre-paid for for five years, in contrast to the free, advertising-supported model of Facebook — was taken down by Yahoo as violating their terms of service. I find this to be a unconscionable action coming from a company that, via its Tumblr unit, happily serves up hardcore porn, images and narratives of self-abuse, and virulent hate speech to all comers without restriction. Thankfully, Martin’s site’s content was captured by a number of different groups, and lives on at various mirrors, to which I have linked previously.

You don’t have to be “real” to have an impact

Later on the first day, I really enjoyed Molly Sauters‘ deconstruction of the saga of Amina Arraf, the purported author of the Gay Girl in Damascus blog, which rose to some acclaim and awareness as civil unrest in Syria accelerated in early 2011.  This, despite the fact that Amina was fictional; the author of the persona the blog was a male American student at the University of Edinburgh, who was found out only after writing on the blog (using a second fabricated persona) that Amina had been abducted by Syrian security personnel.  This prompted waves of online activism and a U.S. State Department investigation (because Amina was ostensibly a U.S. citizen living in Damascus).

Aside from the bizarre tale — and without going into the absurdities of straight white Western guys impersonating lesbian women living in the Middle East — Molly presented a fascinating characterization of the Amina persona as a digital “bridge figure”, a media presentation of “the other” (in this case, someone that is both gay and of Arab descent) that can establish a rapport with people in another context.  In particular, the claim is that Amina was perfectly positioned to appeal to Western, politically conscious liberals, which is borne out by the uproar among mainstream and social media calling for her release.

Of course, identity is a fluid and fragile thing, especially online, and hoaxes are not new. However, the story of Amina is notable as an example of “civic fiction” (a new term coined by Molly, apparently) in that, rather than actually being a bridge figure, she was really just a mirror.  Because she was fabricated by someone from the same context that she was created to appeal to, her story could only reflect the expectations, misgivings, and aspirations of her audience, i.e. those of an educated fundamentally Western woman struggling for democracy in a repressive regime.  This shared context is what ended up making the Amina story so appealing to Western journalists and media outlets, as her author was effectively trained by saturation in the media environment they constructed, and thus able to produce a narrative using the same tropes and patterns.

One of the last things Molly claimed was that even though Amina was a fabricated persona, she did “political work”.  I suspect that this term has particular semantics in political science or theory, but I interpreted it to mean that, despite the abhorrence of the impersonation (especially of someone in an “at-risk” or disenfranchised demographic), the fiction of Amina served its audience’s purpose in providing a bridge figure (despite her actually being a mirror), and was a genuine political actor (manifested in many ways, including by contributing to the narrative of the Syrian uprising and the coalescing of various activist communities when efforts to locate her after her arrest began).  The irony is that the power to do that work was granted by a media apparatus that blindly passed the Amina story along to the same audience from whence her creator came, instead of doing its purported job of mediating sources and identifying the fact (or, deception in this case) of the figure in question.

While reading further on this story, I came across a related, very pointed quote from Louise Carolin that I think is relevant in other social advocacy contexts:

[the first rule of being an ally is] don’t try to speak for the people you’re trying to support

The fungibility of identity was a recurring theme throughout the conference, and has been something I’ve bumped up against personally and professionally over and over. I still remember pining to play Alter Ego on my Commodore-64 (a game that offered the ability to simulate living another life, with different circumstances and decisions than your own), the impact that _why had (and still has) on friends of mine, and so on. I likewise remain fascinated by the Amina case study, how her persona was constructed, how the rest of the world largely accepted it until forced to do otherwise, and what all of this implies for identity on smaller stages and in different types of social spaces.

Stacks as States

On Saturday, Jay Springett gave a presentation that was framed with a question: why can Mark Zuckerberg call Barack Obama on the phone?  The punchline was that various “stacks” (i.e. sets of infrastructure that are housed within particular centrally-controlled, cross-national organizational silos, e.g. Facebook, Google, Twitter) are themselves sovereign, via exactly the same mechanisms true nation-states are.  While nations generally are defined by the lands and other natural resources they control, the network and computational sorts of “stacks” have equivalent corollaries in data, information architecture, computational infrastructure, citizenry in the form of dependent users, and effective international recognition on this basis as states themselves.  If you buy into this characterization, then it’s very clear why the executives of major centralized data and computation silos effectively have diplomatic relationships with heads of state: Obama doesn’t see Zuckerberg et al. as citizens of the United States, or even of the controlling parties of large corporations. They are peers.

Taken this way, revelations around the activities of the NSA and other Five Eyes agencies are even more plausible and “understandable” than they were before: these agencies also view these centralized silos as states (or, at the very least, as state-like actors), and thus the same signals intelligence activities that any spy agency might deploy against another nation is perfectly well applicable to any of the large “stacks”. That these silos happen to be incorporated and domiciled within U.S. borders may imply certain legal technicalities, but such things don’t change the fundamental ways in which these organizations are viewed and related to by “real” nations, and thus the calculus used by intelligence agency personnel when making operational decisions.

Jay provided a very compelling presentation as to the plausibility of this sort of characterization of the geopolitical nature of the centralized sources of information and computation that we rely upon today.  Additional resources he cites as good ways to further understand the political nature of infrastructure include Roads to Power and Seeing like a State.

I was personally very glad to have stumbled across Jay’s presentation, as it provided a set of starting points — and most importantly, a related vocabulary — towards a developing a deeper set of questions around the controlling structures around these stacks of infrastructure, and what individuals and communities can do to assert their own agency with regard to their own infrastructure.  Jay’s own #stacktivism concept (an activism-focused term and set of resources for starting to understand the social implications of infrastructure) is one of these.

In closing

A number of thought-bombs were lobbed in the closing “keynote” panel on “Race and Social Media”.  One of the first came early from Lisa Nakamura:

While social content spaces are often intended as socially agnostic, they never are in practice.

I believe this is a specialization of the distinction I drew above between technical and non-technical concerns.  When we build communications software, tools, and platforms, many of the features we consider and implement aren’t simply “cool” and useful, equally accessible and positive for all of the parties that are affected by them: they often define the shape of conversations and interactions, in ways big and small, obvious and subtextual. Easy examples include things like the ability to publicly tag others in photos, and even the simple option to declare one’s relationship status (chosen from a predefined set of possible types of relationships).

The most powerful shared moment of the entire conference in my opinion (despite my tearing up earlier the prior day) was at the end of the keynote, when Latoya Peterson gave a very compelling summation of the grounding roles of empathy and tolerance in a connected global culture:

It is a very very large world, and we need to exist in it together. What matters is that you love and trust people enough to want to be in the same space with them.  I don’t know shit about trans history or trans rights, but I love Mattie Bryce and I love Naomi Clark and I love all the fabulous trans game designers that I have met through being a gamer, and I want a world with them in it.  That is it, I don’t need to know anything else.  I need to understand what they need to be happy and what they need to be free, and then we work towards that together.

This got a thundering standing ovation from the audience, and rightly so.  Carrying that basic sentiment/intuition through each of our interactions and relationships with people with whom we have little shared context would surely make for a better world.


There’s so much more at TtW that fascinated, inspired, and touched me; I could go on and on, but the morning grows brighter, and work beckons.

So far, I have a couple of “takeaways” from TtW that are directly relevant to my own work and context.  These are not so much things that I learned directly, but perhaps some suspicions and half-thoughts that the conference either confirmed (which worries me re: bias, now looking for contrary indicators!) or helped me to conjugate more fully:

  • Likely as a convenient shorthand, people often talk about the extremes of particular aspects of system design: centralized and decentralized; ad-supported and user-paid; point-to-point and aggregated; tolerant and intolerant; anonymity and authenticated identity.  I am more and more convinced that these are extremes within a multidimensional space that must be large and complex enough to encompass all of human endeavour.
  • A common thread through many presentations was an acknowledgement of the power that things like Twitter, Facebook, Tumblr, etc. have in terms of shaping how people work with information and construct or choose the cultures of which they are a part.  More generally, ideology and technology inform and define each other; to remix Lisa Nakamura’s assertion regarding social content spaces, technology is often intended to be ideologically agnostic, but never is in practice.
  • Despite this awareness, there was an implicit (and sometimes very explicit) fatalism at TtW regarding the centralization of that power, that the economics and politics behind the current generation of networked social services are so powerful that the models they’ve developed are not only the only ones that will ever be considered viable, but that perhaps we have passed a point where opting out of such models will be considered socially, economically, or even legally unacceptable.  As someone that is very interested in building things that enable the disaggregation of computing systems and communication platforms (again, see the Quilt Project), I found this fatalism somewhat disheartening (though perhaps not without merit, esp. given the case compellingly made by Jay Springett that I mentioned earlier).Ironically, it may be exactly that fatalism among those that have thought most deeply about the issues around the centralization of power and infrastructure that may make addressing their root causes more difficult.
  • While thinking about these sorts of things while walking around Brooklyn in between sessions, I tweeted this:williamsburg-tweet-1
    Screenshot from 2014-04-29 10:38:59

I hope you enjoyed my write-up of Theorizing the Web, 2014. Maybe I’ll see some of you there, next year.

Buy a signed copy of ‘Clojure Programming’, help the EFF!

Update, 2014 Aug 29: Unfortunately, this fundraising effort did not pan out.  Only one individual reached out with a “pledge” for the EFF; rather than go through the rigmarole of collecting a single donation, I simply took him at his word that he donated the pledged amount, and set him up with a signed copy of Clojure Programming. Yes, this means I still have a pile of the books sitting idle.

Through a strange set of circumstances, I recently came into a decent-sized cache of copies of Clojure Programming (which I co-authored, in case the blatant self-promotion to the right didn’t tip you off already).  The only other likely option for them was to lay disused for some years, and then end up in the bin; so, I bought them (at a steep discount) from the prior owner, not quite knowing what I’d do with them.

If I didn’t live in the hinterlands, I’d just drop them off at the nearest gathering of Clojure enthusiasts; but, lugging boxes of books hours away to Boston or New York had little appeal.  My next thought was to simply sell them, but the economics are just crummy, given the PITA logistics of handling payments, boxing, and shipping for one book at a time, all for something like $15 or so net. (Yes, sorry, I’ll file this under #firstworldproblems.)

But, a better idea came eventually, one that I hope enough of you will cotton to to make an impact:

Buy a signed copy of Clojure Programming; all proceeds go to the Electronic Frontier Foundation

Surely you’re familiar with the EFF already; if not, you should be.

The “rules” here are very simple; basically, this is a first-price sealed-bid auction:

  1. Send me an email indicating how much you would like to donate to the EFF, $100 minimum, exclusive of the shipping necessary to get the book to you.
  2. The top 5 pledges received before March 5th, 2014 will receive a new copy of Clojure Programming, signed by me (FWIW, etc).  I’ll write whatever else you’d like in terms of a salutation, personal message, etc.
  3. The cumulative amount pledged will be donated to the EFF, in care of those that made those top 5 pledges.

If it’s not completely clear, I’ll not be keeping a single cent of the pledged amounts; everything will be going to the EFF.  In fact, I’d like to use Dwolla if possible for all donations, which would effectively eliminate transaction fees; I’m pretty sure the EFF can do more with that 3% than Visa, Mastercard, and Paypal.

Sound good?  Pledge away, and feel free to ask any questions here or via Twitter.

Results of the 2013 State of Clojure & ClojureScript survey

Two weeks ago, I opened up this year’s Clojure & ClojureScript survey.  Now, you get to see what everyone said, and we all get to speculate on what it means.

First, some process details:

  • The survey was open for ~7 days, from Nov. 5th – Nov. 12th.
  • I announced the survey here, on my personal Twitter feed, and via a total of four messages to the main Clojure & ClojureScript mailing lists.
  • 1,061 responses were received.

One immediately-surprising thing is that fewer people participated than last year; not by a staggering amount, but enough to make me pause.  Of course, there’s a ton of uninteresting reasons why that might be the case: the time of year the survey was offered, the new collection method being used (PollDaddy vs. a Google Docs form last year), the size of the survey (23 questions vs. 13 last year), and the peer presence of ClojureScript in the survey (which accounts for the increase in question count).  Of course, all of this comes with the caveat that I’m far from a professional pollster, so there are tons of factors that I’m surely unaware of that would impact participation (maybe some that I’m responsible / to blame for).

(Late note: people have mentioned that, in contrast to prior surveys, this year’s did not get any significant placement on Hacker News et al.  That may further explain the drop-off in responses.)

Per-question tl;dr

What follows is a super-brief summary of the results, with my own opinions interspersed.

Do you use Clojure, ClojureScript, or both?

The community is effectively split between those that use only Clojure, and those that use Clojure and ClojureScript.  Only 7% of respondents use only ClojureScript.

To me, this implies that ClojureScript has not (yet?) attracted a population looking to use it, and it only (as opposed to other languages that target JavaScript, e.g. CoffeeScript, that are used in conjunction with a diverse set of backend languages / architectures as appropriate).  A rosy speculation might be that those coming to ClojureScript from other languages are so enamoured of the language and its model that they also adopt Clojure, but it’s probably more realistic to say that most ClojureScript usage is simply a result of Clojure developers wanting to target JavaScript environments with a minimum of language and data model pain.

In which domains are you applying Clojure and/or ClojureScript?

In a few words, web development, open source, math and data analysis, and building commercial services and products using databases.  There aren’t a lot of surprises here.

Notable is that ~20% of respondents are using Datomic in some capacity.

The relative distribution of the domains really hasn’t changed since I started running the survey.  At this point, the only utility of this question is to limit one’s view of the rest of the results in terms of what people are working on.

Order these aspects of Clojure/ClojureScript to reflect how useful each have been to you and your projects…

It’s no surprise that functional programming, REPLs, immutability, “ease of development” (an ill-defined aspect to include in the list, I now realize), and host interop are hugely impactful; these are core to Clojure’s rationale.

On the other end of the spectrum, metadata and newer features like reducers and tagged reader literals are comparatively not getting a lot of love.  This is actually a bit unfair, especially with regard to metadata, but the stack-ranking nature of the question means that some useful bits were guaranteed to be lingering at the bottom.

What is your *primary* Clojure/ClojureScript development environment?

This question changed from prior years (people could choose only one development environment this time around), so comparisons with prior years would be inappropriate.

  • Emacs is preferred by over half of respondents, and nearly all of them are using cider/nrepl.el now; effectively no one is using SLIME or slimv anymore.
  • Likewise, vim users have largely moved over to vim-fireplace.
  • Light Table is the third most preferred development environment, just beating out Counterclockwise.
  • In a very short period of time, Cursive Clojure has overtaken the usage of the La Clojure IntelliJ plugin.

There are now a number of Clojure/ClojureScript implementations targeting runtimes aside from the JVM and JavaScript. To what degree are you aware of or using each of these implementations?

Very few people are using these alternative implementations, though up to 20% of respondents are evaluating at least one; the “winner” there is clojurec, which makes sense given some of the most popular complaints around Clojure, i.e. its general unsuitability for command-line utility development and the difficulty of using native libraries from within the JVM.

Re: Clojure

How would you characterize your use of Clojure today?

More than half of respondents are using Clojure at work, which is a big jump compared to the last two years, when only a third of respondents were so lucky.  This is nothing but good.

What version of the JRE/JDK do you target?

We are generally early adopters, and that carries over to JDK selection: 75% of respondents are using 1.7, 5% are on some pre-release of JDK 1.8.  JDK 5 is dead now, and JDK 6 is on its way.

What tools do you use to compile/package/deploy/release your Clojure projects?

This is another question where I changed the survey to force people to make one selection, so comparisons across years don’t make sense.  Leiningen dominates the Clojure project management / build space.

Name *one* language feature you would like to see added to Clojure.

This was a free-form question, and I’m not going to attempt to summarize the responses. I’d encourage everyone to click through to the full survey results and look at some of these yourselves (maybe filtered to focus on the “types” of Clojure programmers / usage you are interested in).

Update: Alex Miller has summarized this question’s responses into a ranked set of categories of features.  This is a great way to get an overall impression of what’s top-of-mind among participants without weeding through the raw responses yourself.  Thanks, Alex!

In general, are the following statements true when applied to the Clojure libraries available within your domain(s)?

This question attempted to gauge general sentiment with regard to library quality on a couple of different criteria.  In short, Clojure libraries are easy to find, their maintainers are receptive to feedback and patches, they are technically of high quality, but they’re not always very well-documented.  None of that is surprising or particularly different from last year.

What has been most frustrating for you in your use of Clojure; or, what has kept you from using Clojure more than you do now?

Clojure is not generally suitable for building command-line tools, though people wish they could use it for that (perhaps ClojureScript and/or something like clojurec will help here over time).  As in prior years, people remain unsatisfied with documentation and development environments.

“Staffing concerns” is new as the #2 reported frustration, which I think is significant: I certainly know that companies using Clojure have a hard time filling openings lately.  Perhaps this is correlated with (maybe) increased commercial use of Clojure, given many more people using Clojure at work this year; it may also be a reflection of current/recent macroeconomics.

What do you think is Clojure’s most glaring weakness / blind spot / problem?

Again, you should go look at the raw results to see what people highlighted as problematic areas in Clojure.  I will call out this response though, as it was both at the top of the list of responses for this question, and made me chuckle:

“Where are the docs?”

“Read the (tests|docstrings).”

“Did you just tell me to go fuck myself?”

“I believe I did, Bob.”

(Apologies to @jrecursive.)

Re: ClojureScript

How long have you been using ClojureScript?

ClojureScript is very new, and in general, all ClojureScript programmers are new, too: effectively all of us have been at it for a year or less.

How would you characterize your use of ClojureScript today?

Despite ClojureScript’s youth, over 25% of its users are using it at work.  I find that amazing, and is a testament to the relative maturity of the language, i.e. it started off benefiting from the lessons that were learned in building Clojure and bringing it to the point that it’s at today.  Of course, that doesn’t yet reflect in the maturity of ClojureScript’s implementation.  Things there are getting better fast, and will continue to do so.

Everyone else is basically just tinkering, which makes total sense right now.

Which JavaScript environments do you target?

Browsers dominate here, which makes sense.  However, people target a bunch of other environments with ClojureScript too, from node.js to app containers to plv8 to Riak’s mapreduce.  Basically, if it can run JavaScript, I’m guessing someone is going to target it with ClojureScript.

The tricky thing about this is what this implies for those of us targeting more than one environment with our Clojure[Script]ing: while 95% of a codebase may be perfectly portable among all sorts of runtimes one can target from Clojure and ClojureScript, many of the options available for dealing with that last 5% are suboptimal, especially insofar as adding an additional level of indirection to represent runtime differences conflicts with the typical objective of that 5%, namely performance-sensitive bits that need to touch runtime-specific / interop facilities.  Fixing / working around this has been a defcon 3 yak for me for some time, thus cljx…maybe it’ll help you out if you’re contending with the same issues.

Which tools do you use to compile/package/deploy/release your ClojureScript projects?

Just like with Clojure, Leiningen (with lein-cljsbuild) is the overwhelming favourite for ClojureScript build/project management.  This is no surprise given huge overlap between those using ClojureScript and those using Clojure.

Which ClojureScript REPL do you use most often?

The results here are very surprising, and sad to me: more than a quarter of ClojureScript developers don’t use a REPL at all.  Looking at the responses around what can be improved about ClojureScript, the ease of use of existing REPL options is easily the #1 reported problem, and is clearly preventing people from using what is reported more generally as one of the most useful parts of Clojure/ClojureScript.  This is absolutely something that is hurting ClojureScript adoption, especially insofar as one of the first things people reach for when language tinkering is the REPL and ways to make it work with one’s other tools.

I’m doing what I can to help this problem by working on Austin, an alternative project- and browser-REPL implementation that aims to make ClojureScript REPL-ing as easy and as indispensable as it is in Clojure.  If you’ve had a hard time getting ClojureScript’s browser REPL going reliably, or would like to not depend on e.g. Rhino for project-connected REPLs, take a look; it’s far from done, but what’s there is easier to use and somewhat more flexible than the baseline.

Name *one* language feature you would like to see added to ClojureScript.

Just like with the Clojure analogue, this was a free-form question that I’m not going to comment on here. Click through to the full survey results and look at some of these yourselves.

What has been most frustrating for you in your use of ClojureScript; or, what has kept you from using ClojureScript more than you do now?

As mentioned before, difficulty using REPLs is the biggest deal here, followed by “difficulty debugging generated JavaScript” (something that I know has been a big focus of David Nolen & co. with source maps and such).  Other big problems include using JavaScript libraries (something I’m queued to improve), followed by the eternal frustration around documentation, and my personal favourite, “coping with JavaScript”.

That last one is not something we can do much about very quickly in the ClojureScript community, but it’s definitely one I share; having relied on the JVM and JDK for the last 15 years, it can sometimes be incredibly frustrating to have to work around the shortcomings of the JavaScript runtime environment, language problems, and holes and misfeatures in the standard library.  Hopefully we’ll be saved eventually by some potential improvements coming from the ECMAScript standardization/evolution process.  In the meantime, perhaps there are some clever things we can do to blunt the pain a bit.

What do you think is ClojureScript’s most glaring weakness / blind spot / problem?

Here is where you can leave any general comments or opinions you have…

The last two questions both collected free-form responses, only the first of which is ClojureScript-specific.  The second is always my favourite part of the survey, where people can write anything they want about the survey, our languages, or our community; it’s overwhelmingly positive, and reminds me why I’m proud to be part of all of this.  The only one I’ll quote that appears a bunch:

Thanks for the survey Chas!

My pleasure, thank you for participating!

Survey data access

Complete access to the survey reports (with a pretty snazzy filtering and drilldown UI) as well as all the raw data are available here; the password for that shared view is “HvmqkIS3dx3”.

2013 State of Clojure & ClojureScript Survey

This is the fourth year in which I’ve offered up a “State of Clojure” survey.  As before, my intention is to get a sense for the size and overall level of activity in the Clojure community, and to capture a certain zeitgeist of the community’s mood, practices, concerns, and so on.  If you’re interested in history, you can see the results of all prior surveys:

The big change this year is that questions related to ClojureScript are included such that it roughly shares the limelight with Clojure.  In part, that’s selfish; I started using and contributing to ClojureScript seriously over the last 18 months, so I’m interested to have some perspective on what other users care about.  More importantly, there’s no denying that ClojureScript has matured significantly over that period, and has attracted a great deal more attention. Especially given its potential, it’s time it took its proper place in the survey as a peer implementation of the Clojure Principles we’ve all come to appreciate.

Results from the 2013 State of Clojure & ClojureScript survey are here.

This year, I’ve moved to hosting the survey with PollDaddy, which has graciously set me up with a ‘pro’ account; this will allow us to get far more advanced analysis out of the results than were ever possible with the primitive Google Docs form I’d used up until now.

As before, I’ll follow up with the results, some charts and graphs, and some sad attempts at witty commentary.  Of course, all of the raw data will be available as well.

Finally, please do what you can to spread around this survey to those that you know of that are working with Clojure and/or ClojureScript.