Dana Boyd on Pseudonyms

I'm late to notice, but Dana Boyd has a good article up on the case for pseudonymity. She emphasizes the safety issues, which I certainly agree about.

Something I hadn't fully processed is that many people are using Facebook as an example that real names work. Perhaps this argument is so popular because the Zuckerbergs have publicly emphasized it. At any rate, it's a weak argument. For one thing, quite a number of Facebook profiles are using pseudonyms. See Lady Gaga, Ghostcrawler, and Anne Rice. If the Zuckerbergs really are trying to shut down pseudonyms, they're doing a terrible job of it. Another reason is that, as Boyd points out, Facebook is unusual for starting as a close-knit group of college grads. The membership it grew from is a group of people relatively uninterested in pseudonyms.

Reading the comments to Boyd's post, it appears that the main reasons people are convinced about pseudonyms is the hope that it will improve the level of conversation in a forum. I continue to be mystified by this perspective, but it does appear to be what is driving the most opponents of pseudonyms. I just don't get it. Partially I'm just used to an Internet full of pseudonyms. Partially it's just too easy to think about perfectly legitimate activities that wouldn't be good to pop up if someone does a web search on "Lex Spoon". People interested in that stuff should instead search for Saliacious Leximus. They'll avoid all the nerdy computer talk and get straight to the goods they are looking for.

Overall, pseudonyms appear to be one of those divides where people on each side have a hard time talking over the gulf. Apparently is is perfectly obvious to many people that if Google Plus and Facebook embraced pseudonyms, then their members would get overwhelmed by harassment and spam. Personally, I don't even understand the supposed threat. Why would I circle or friend a complete stranger? If I had, why wouldn't I simply unfriend them?

The Web version of interface evolution

Nick Bradbury points out an important issue with web APIs:

I created FeedDemon 1.0 in 2003, and it was the first app I wrote that relied on web APIs. Now those APIs no longer exist, and almost every version of FeedDemon since then has required massive changes due to the shifting sands of the web APIs I've relied on.

There are a tangle of issues involved here.

One is that, for sure, web APIs are not a suitable way to build a self-contained system that will at least remain internally consistent indefinitely. You couldn't build a space probe using any web APIs that you don't control. By the time it got to Jupiter the protocols might well have changed. Even barring an intentional protocol change, the service might upgrade its software and accidentally break you.

Not all software is of this character, however. Most user-facing software is expected to stay compatible with the other software a particular user is taking advantage of. Most user-facing software has a mechanism for being updated after it's deployed.

The thought experiment I use here is to consider why the Lisp Machine is no use nowadays. These systems are very impressive; think Emacs, but with a better programming language, and with multiple for-profit companies writing professional software to run on it. Nonetheless, they are useless nowadays (and Emacs is as awesome as ever). That it is so is obvious, but what is the precise reason for it?

My best answer is that the world changed around them. Even without any explicit API break, Lisp Machines just don't have integration with other forms of software that its users would find important. That whole Internet thing is a simple example.

In general, most software is only useful if it is under active maintenance. The difference between zero maintenance and a little bit of maintenance is huge. If you are considering using software isn't under maintenance, run away! If you continue to use it, you will eventually find that you have become its maintainer yourself.

Which brings me back to APIs. APIs are never perfect, and so they evolve just like any other interface. The only way this is different for web APIs is that the clients do not get to choose when to upgrade. One day, the provider updates their software and it's simply on the new API. Gilad Bracha describes this as "versionless software".

Ideally, this evolution should involve discussion between the service provider and all of the clients. Exactly how those discussions work is a rich question that is similar to any other decision process by a number of stakeholders. For an API like one offered by Google, individual clients have very little influence on the API, so you have to decide whether to take it or leave it; part of that decision involves your expectation that the service provider will treat you well. In other cases, there might be a contractual agreement between a user of the service and its provider; in that case, any API changes could be worked out as part of negotiating the contract. In still other cases, a group of software users might meet in standards committees, as happens to some degree with the HTTP protocol.

In short, I really don't think that constant interface change is a fundamental reason to avoid web APIs. Instead, it's a fundamental part of most software development that you have to keep maintaining, whether or not the APIs you program against are accessed over the web. Instead, you should be choosy about what specific APIs you depend on. Just like you wouldn't want to depend on an ancient unmaintained hunk of software, you also wouldn't want to use a hyperactively maintained hunk of web service that has a completely different API from one week to the next. Think explicitly about the API evolution story for any service you depend on, and use your judgement.

Cloud9 is hitting limits with JavaScript

Cloud9 has a well-written call for adding classes to JavaScript:

Adding classes to JavaScript is technically not hard -- yet, its impact can be profound. It lowers the barrier to entry for new JavaScript developers and reduces the incompatibility between libraries. Classes in JavaScript do not betray JavaScript’s roots, but are a pragmatic solution for the developer to more clearly express his or her intent. And in the end, that’s what programming languages are all about.

Their argument about library compatibility seems strong to me. It is reasonable to write a Python or Java library that stands alone and has minimal external dependencies. With JavaScript, however, the temptation is strong to work within a framework like Dojo or JQuery just so that you get basic facilities like, well, classes. It's a good argument. If I were working on a large JavaScript code base, however, I'd be strongly tempted to switch over to Dart. It already has the basic language facilities they yearn for, and it's going to move forward much more quickly.

Dennis Ritchie passes

Dennis Ritchie, co-inventor of C and Unix, has passed away.

I first learned C at a summer camp for math enthusiasts. We implemented programs to generate fractals on Sun workstations (or was it SGIs?), and the language we implemented them in was C. I asked around about this interesting language, borrowed a book from someone, and soaked up the language like a sponge. I wish I could remember if the book was K&R, but I do remember reading through one of the first examples in it. The program read its input character by character and performed some transformation on them, perhaps converting them to uppercase, and printed out the result. I remember thinking it was a hard problem, and I remember a growing delight as the chapter broke the problem down into smaller pieces that mapped perfectly to C. I read over and over that ten line program, savoring the while loop and the stdio calls and the looping variable named "c" (or was it "ch"?).

Several years later, I gained access to the Unix machines at Clemson, and it was computing nirvana. The machines had a ubiquitous C compiler, a suite of Internet programs, preemptive multi-tasking, a good scripting language, a good shell, and a windowing operating system to run it all in. Compared to Windows 3.1, DOS (because Windows was a resource hog), batch files, debug.exe, and Pascal, these machines just felt right. It felt like I'd been walking with a fifty pound backpack for miles, and now I could set aside that backpack and walk more lightly.

Unix and C are just that good. At the time, those systems were more than a generation ahead of the IBM, Apple, and Commodore computers everyone was using at home. Nowadays, the number of Unix machines has only grown. Android, Apple, and ChromeOS machines all run Unix. If you can't beat 'em, join 'em.

Ritchie was instrumental in this revolution. Though few seem to have actually talked to the guy, the web is filled with testimonials. Here are a few of them that I have run across:

• Wired
• Lambda the Ultimate
• Herb Sutter
• ReadWrite Enterprise
• Rob Pike
• Ars Technica
• NPR News

Schmidt on federal policy

Eric Schmidt testified before Congress on its technology policy, and he tells the Washington Post that he is not happy.

Much of the issue he blames on age. For example:

And inevitably what happens is everyone says ‘yes,’ yet inevitably on the Hill you have an older gentleman or lady. The staffers—and the staffers are young—the staffers get it. They’re 25, 30 years old and they all get it. So that’s what we depend on. And of course we’ve hired ex-staffers as well. They all know each other. So that’s how it really works. And I believe what we’re doing is extremely defensible if it’s around ideas. I would have a lot of trouble if we in our industry started following the other kind of lobbying.

I'm not sure I agree. I know a lot of younger people that haven't thought through the horror that search neutrality will be if it goes through. I think there's a more fundamental problem computers are changing quickly. Search engines didn't exist twenty years ago, and twenty years from now, they will be completely different. How is it realistic for Washington to regulate something that completely changes every couple of decades?

I admit I appreciate his suggestion about how to improve the state of IT in the U.S. even further:

A classic example is H-1B visas. Now, the following arguments are so obvious, it’s hard for me to believe that anyone would believe that they’re false. These industries are full of very smart people. There are very smart people who don’t live in America. They come to America, we educate them at the best universities, they are smarter than I am, and then we kick them out. If they stayed in the country, let’s just review: They would create jobs, pay taxes, have high incomes, pay more taxes than the average American, and generally increase the GDP of the country. I hope my argument is clear, and if it isn’t I’ll start screaming about it. It’s the stupidest policy the government has with respect to high tech. So you have this conversation and people say “yes,” and you say, ”This is the single thing that you can do that will lead to innovation occurring in our country, and the future economic wealth of our country.” And then they don’t act.... It’s stupid. So my point is that if you want to get a sense of how to screw this up, to put it negatively, then make it harder for us to bring in the world’s smartest people.

Tell 'em, Eric!

Dart spec is online

Google has posted a technical overview and a language specification for Dart, their new programming language for web browsers.

In short, the language is a skin around JavaScript. It provides syntax for parts of JavaScript that are left to convention, and it is designed to be easily compilable to JavaScript. It has optional types, class definitions, and a module syntax.

The type system has some controversial aspects, in particular an explicit choice not to bother about soundness. If I understand correctly, assigning an apple to a variable holding bananas would cause an error, but assigning an unknown fruit to a variable holding bananas would not. The idea is to pick up the egregious errors and otherwise leave the programmers alone.

Hat tip to Lambda the Ultimate, which has several interesting discussions in the comments.

The jlouis blog has a detailed breakdown of what's in the language. Delightfully, he includes the following homage to Blade Runner:

If all you know is Javascript, the language is probably pretty neat. But for a guy who has seen things you wouldn't believe. Haskell ships off the shoulder of MultiCore CPUs. Watched OCaml glitter in the dark near TAPL. All those moments will be lost in time, like tears in rain. Time to die.

What every guide says about child safety on the Internet

At the same time that Blizzard and Google are fighting for real names only on the Internet, children's advocacy groups are fighting for exactly the opposite. Take a look at the top hits that come up if you do a web search on "advice to children online".

First there is ChildLine, a site targeted directly at children. Here is the entirety of their guide on how to stay safe:

How do I stay safe when playing games online?

• Don’t use any personal information that might identify you. This could be your full name, home address, phone number or the name of your school.
• Use a nickname instead of your real name and chose one that will not attract the wrong type of attention.
• Look out for your mates. Treat your friend’s personal details like you would your own and do not share their details with others.

Not only do they suggest not using real names, it is pretty much the only advice they give.

Next is Safe Kids, a site targeted at parents. This site has a more detailed guide on things you can do to help a child say safe. Here is their number one suggestion under "Guidelines for parents":

Never give out identifying information—home address, school name, or telephone number—in a public message such as chat or newsgroups, and be sure you’re dealing with someone both you and your children know and trust before giving out this information via E-mail. Think carefully before revealing any personal information such as age, financial information, or marital status. Do not post photographs of your children in newsgroups or on web sites that are available to the public. Consider using a pseudonym, avoid listing your child’s name and E-mail address in any public directories and profiles, and find out about your ISP’s privacy policies and exercise your options for how your personal information may be used.

Third up is BullyingUK, a site dedicated to bullying in particular instead of general child abuse. Here are their first two pieces of advice for Internet saftey:

• Never give out your real name
• Never tell anyone where you go to school

The real names movement is not just out of touch with BBS culture and with norms of publication. It's also out of touch with child safety advocates.

Real names proponents talk about making Internet users accountable. Child advocates, meanwhile, strive for safety. Safety and accountability are in considerable tension. To be safe on a forum, one thing you really want is the ability to exit. You want children to be able to leave a forum that has turned sour and not have ongoing consequences from it. To contrast, real name proponents hope that if someone misbehaves and leaves a forum, there is some outside mechanism to track the person down and retaliate. That might sound good if the person tracked down is really a troll, but it's a chilling prospect if the person being hunted is a child.