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.

Throttling via the event queue

Here's a solution to a common problem that has some interesting advantages.

The problem is as follows. In a reactive system, such as a user interface, the incoming stream of events can sometimes be overwhelming. The most common example is mouse-move events. If the OS sends an application a hundred mouse-move events per second, and if the processing of each event takes more than ten milliseconds, then the application will drift further and further behind. To avoid this, the application should discard enough events that it stays caught up. That is, it should throttle the event stream. How should it do so?

The solutions I have run into do one of two things. They either delay the processing of events based on wall-clock time, or they require some sophisticated support from the event queue such as the ability to look ahead in the queue. The solutions that use time have the problem that they often introduce a delay that isn't necessary; the user will stop moving the mouse, but the application won't know it, so it will add in a delay anyway. The solutions using fancy event queues are not always possible, depending on the event queue, and anyway they make the application behavior more difficult to understand and test.

An alternative solution is as follows. Give the application a notion of being paused, and have the application queue Unpause events to itself to get out of the paused state. The first time an event arrives, process it as normal, but also pause the application and queue an Unpause event. If any other events arrive event while the application is paused, simply queue them on the side. Once the Unpause event arrives, if there are any events on the side queue, drain the side queue, process the last event, and queue another Unpause event. If an Unpause event arrives before any other events are queued, then simply mark the application unpaused.

This approach has much of the advantages of looking ahead in the event queue, but it doesn't require any direct support for doing so. It also has as good of responsiveness under system load as appears possible to achieve. If the system is lightly loaded, then every event is processed, and the system is just as responsive as it would be without the throttling. If the system is loaded, then enough events are skipped that the application avoids backlogging further and further behind. If the load is temporarily high, and then stops, then the last event will be processed promptly.

The one tricky part of implementing this kind of solution is posting the Unpause event from the application back to the application itself. That event needs to be on the same queue that the other work is queuing up on, or the approach will not work. How to do this depends on the particular event queue in question. For the case of a web browser, the best technique I know is to use setTimeout with a timeout of one millisecond.

Kudos to Princeton for an open-access policy

It seems that Princeton has adopted an open-access policy for the papers their faculty publish.

...each Faculty member hereby grants to The Trustees of Princeton University a nonexclusive, irrevocable, worldwide license to exercise any and all copyrights in his or her scholarly articles published in any medium, whether now known or later invented, provided the articles are not sold by the University for a profit, and to authorize others to do the same.... The University hereby authorizes each member of the faculty to exercise any and all copyrights in his or her scholarly articles that are subject to the terms and conditions of the grant set forth above.

The legalese is making my head spin, but I think they are saying that the university gets full access to all faculty publications, and that the university is granting all faculty full access to their own publications. As a programmer, I yearn to write it in a more simple way, and probably to drop the "for a profit" part. Still, the spirit is there. Anything published by a Princeton faculty member will not be hidden exclusively behind a paywall.

Hat tip to Andrew Appel, who emphasizes that this policy is compatible with ACM's paywall:

Most publishers in Computer Science (ACM, IEEE, Springer, Cambridge, Usenix, etc.) already have standard contracts that are compatible with open access. Open access doesn't prevent these publishers from having a pay wall, it allows other means of finding the same information.

This is true, but I find it too gentle on ACM. The ACM is supposed to be the preeminent association of computer-science researchers in the United States. They would serve their members, not to mention science, if they made the articles open access. Charge the authors, not the readers.