The Brain-Hand Barrier

I’ve never been a particularly fast typist. Despite reading Steve Yegge’s very entertaining Programming’s Dirtiest Secret once every few months or so, I’ve been stuck in the 40 to 50 words-per-minute range for a few years now. Most of the time, this is not a big problem, for multiple reasons. In the last few months, I’ve been mostly writing code, not words (as witnessed by the rather low rate of posts on this blog). When you’re using a fairly succinct and powerful language (like OCaml) and working on research code, the major bottleneck to getting things done is often your thinking speed, not your typing speed. And for the rest of the times there are well-chosen Emacs keybindings deeply ingrained into your muscle memory.

I’d like to start writing more honest-to-goodness words—I’m pulling this blog out of the mothballs, I’m keeping a daily log of my research work and possibly a personal journal. And that’s on top of the usual emails and IMs and other sundry typing activities. As I’ve been ramping up my word count, I’ve been noticing something curious that’s purely anecdotal and quite possibly, completely wrong. But this is my blog and something is often better than nothing so I’m going to put it here for all eternity.

I claim (completely without proof) that when writing words (at least non-technical words) the bottleneck can often be your fingers. If you’re a slow typist (or an adequate typist, like me) you find yourself frantically trying to get ideas and thoughts down before they all slip away like water between your fingers. As a result, increasing typing speed can actually be better in at least two ways: first, typing faster lets you get raw thoughts down much faster leaving you time to come back and edit later. I know that a lot of people subscribe to the philosophy of writing slowly, even going so far as to using pen and paper to slow themselves down. Personally, I’m in the Hemingway camp — write drunk; edit sober. Since I have absolutely no intention of becoming an alcoholic, I’ll go with “write fast; edit slow”. It’s boring I know, but I like my liver and my brain cells.

Second, for a certain type of personality (including me), knowing that you’re fast enough to get something down without a major interruption in whatever else you’re doing makes you more likely to actually put it down, rather than having it banging around inside your head. For more on why getting things out of your head is helpful, I point you to the last book I read Overwhelmed: Work, Love and Play When No One Has the Time and a tl;dr review/article of the same name.

Both of the above are benefits from fast typing, apart from the professional benefits you might get (for which I point you back to Steve’s post).

So to conclude: type fast, type lots, edit slow, publish some. There’s probably a rant about RSI and how the Hobbit movies could have been made better and shorter with a good editor that can be extrapolated from that last sentence, but that will have to wait for another day.

Amazon’s Digital Wonderland

A few weeks ago I found myself in Seattle, WA. Contrary to popular belief, it was a rather bright and sunny few days (if somewhat chilly). Here’s an obligatory picture of the Sky Needle.

Sky Needle

Anyways, on the first day there I fought a mostly losing battle against travel-induced tiredness (I was up at 4:30 in the morning) and walked around downtown for a while, somewhat zombie-like. I spent the most of the next day in one of Amazon’s new buildings attending their first ever PhD Symposium. I got to meet Amazon employees like Swami Sivasubramanian, one of the creators of Amazon’s Dynamo database, as well as fellow graduate students like Rahul Potharaju. The day was full of interesting presentations and the breaks in between were packed with lots of cool conversations. I presented my current project, Merlin(excuse the visuals) and got some good feedback. All-in-all it was a great day, I had a wonderful time and I hope Amazon keeps having more of these research Symposia.

But that’s not what this post is about. Personally, I think of Amazon as a retailer first and a technology company second. In fact, I’ve even written a post about their exemplary customer service. Even though I’ve known about EC2 for years and have used both S3 and Glacier as personal backup, the idea of Amazon as a technology company has always been at the back of my mind. In fact, it was only while attending the symposium that I really thought about the full weight of Amazon as a technology services company.

After coming home I looked up the keynote from Amazon’s recent Re:Invent conference. The keynote shows off some of their more interesting recent technology (including new EC2 instances) as well as client technologies built on top of it (including companies like Netflix and Vimeo). I also stumbled across Dave Winer’s post on Amazon’s support of static JavaScript applications and why that’s so interesting and important.

The more I think about it, the more I like Amazon. They make incredible technology, employ lots of really smart people and have a refreshingly honest and direct business model in an industry dominated by advertising and harvesting user data. From computation, to storage, to scalable DNS, Amazon offers a suite of services that’s just about stunning in its breadth. Though I’ve had little use for their services personally (apart from Glacier for backup), I can see myself extensively using their systems and technology if I was building any of type of scalable, distributed service.

Even as I write this, I’m trying to come up with excuses for trying out more of their technology. What would I build? I honestly don’t know. But looking at the range of Amazon technologies and thinking about the possibilities reminds me of the feelings I got when I first started programming and learning about computers.

In many ways, the world has changed since I started writing code about 12 years ago. I had a lot of fun writing LOGO and BASIC programs and then hacking together little Perl scripts. Today I find myself wondering what the loosely coupled services and technologies offered by Amazon and other cloud computing services enable. I wonder if the new programmers of today, still learning on primarily single-threaded, single-box computing platforms, should be encouraged to move on to the brave new world of instantly accessible, practically unlimited computing power. I wonder what we’ll achieve if we were to take distributed, connected computation as the starting point, rather than the state of the art.

As an ending note, let’s think about Microsoft. It’s become standard to talk about Google as today’s Microsoft, but I’m starting to wonder if that title doesn’t rightfully belong to Amazon. I’m not talking about monopolistic activities or questionable business practices, but rather their similarities in making computing more popular. Microsoft’s goal (ostensibly) was to put a computer in every household. Amazon, for its part, has commoditized high-powered computing and distributed systems and made them available to people with modest budgets. I suppose the more things change, the more they stay the same.

Sunday Selection 2013-10-13

Around the Web

Advice to a Young Programmer

I’ve learned a lot about system design and programming since I started grad school two years ago. I’m still learning a lot as I use new tools and techniques. This post does a good job of summarizing an experienced programmer’s advice to someone younger and newer to the craft.

Why Microsoft Word Must Die

I’m quite happy to say that I haven’t used Word in years. I don’t have a copy installed and I can’t remember the last time I needed to edit a Word document. I use LaTeX for most of my writing (everything from applications and academic papers to my resume). For the rare occasion that I need to open a Word document, Google Docs is more than adequate. Charlie Stross is one of my favorite newer science fiction authors and like most of his technology-related writing, this piece is on point about why the modern Microsoft Word is simply bad.

Less is Exponentially More

This article about why Go hasn’t attracted more C++ programmers is over a year old, but as a student of language design it’s interesting to see how language features interact with programmers’ needs. If you’re interested in programming languages or write lot of C++ code this is a worthwhile read.

Video

Jiro Dreams of Sushi

I’ve been meaning to watch this documentary for a long time, but finally got around to seeing it last night. It’s about Jiro Ono, and 85-year-old sushi master and owner of a tiny 3-star Michelin sushi restaurant in Japan. At its heart it’s a story of a man’s quest for perfection and devotion to his craft. Though it’s ostensibly about the art of sushi, I think there’s a lot for any professional can learn. It reflects a way of life and devotion to purpose that we rarely see in day-to-day life. You can catch it on Netflix streaming and on Amazon Instant Video (it’s not free for Prime members though).

Uncertainty about the future of programming

I finally got around to watching Bret Victor’s “The Future of Programming” talk at DBX. It did the rounds of the Intertubes about two months ago, but I was having too much at the Oregon Programming Languages Summer School to watch it (more on that later). Anyway, it’s an interesting talk and if you haven’t seen it already, here it is:

You really should watch it before we continue. I’ll wait.

Done? Great. Moving on.

While the talk generated a lot of buzz (as all of Bret Victor’s talks do), I’m not entirely sure what to take away from it. It’s interesting to see the innovations we achieved 40 years ago. It is a tad depressing to think that maybe we haven’t really progressed all that much from then (especially in terms of programmer-computer interaction). While I’m grateful to Mr. Victor for reminding us about the wonderful power of computation combined with human imagination, at the end of the talk, I left wondering: “What now?”

The talk isn’t quite a call-to-arms, but it feels like that’s what it wants to be. Victor’s 4 points about what will constitute the future of programming show us both how far we’ve come and how far we have left to go. However, like his other talks, I can’t help but wonder if he really thought through all the consequences of the points he’s making. He talks about direct manipulation of information structures, spatial and goal-directed programming and concurrent computation. His examples seem interesting and even inspiring. But how do I translate the broad strokes of Mr. Victor’s brush to the fine keystroke of my everyday work? And does that translation even make sense for more than small examples?

For my day to day to work I write compilers that generate code for network devices. While I would love to see spatial programming environments for networks and compilers, I have no idea what that would look like. If I’m building sufficiently complex systems, (like optimizing compilers or distributed data stores) the spatial representations are likely to be hundreds of pages of diagrams. Is such a representation really any easier to work with than lines of code in plain text files?

While I’m all for more powerful abstractions in general, I’m skeptical about building complicated systems with the kinds of abstractions that Bret Victor shows us. How do you patch a binary kernel image if all you have and understand is some kind of graphical representation? Can we build the complex computation that underlies graphical design systems (like Sketchpad or CAD tools) without resorting to textual code that lets us get close to the hardware? Even the Smalltalk system had significant chunks of plain text code front and center.

Plain text, for all it’s faults, has one big thing going for it — uniformity. While we might have thousands of different languages and dozens of different paradigms, models and framework, but they’re all expressed as source code. The tools of software development — editors, compilers, debuggers, profilers, are essentially similar from one language to the next. For programmers trying to build and deploy real systems I believe there is a certain benefit in such uniformity. Spatial programming systems would have to be incredibly more powerful for them to be seriously considered as an alternative.

I am doing the talk some injustice by focusing on spatial programming, but even in the other areas, I’m not quite sure what Mr. Victor is talking about. With regards to goal-directed programming, while I understand and appreciate the power of that paradigm, it’s just one among many. Concurrent and multicore is great, but a lot of modern computation is done across clusters of loosely connected machines. Where does the “cloud” fit into this vision? Mr. Victor talks about the Internet and machines connected over a network, but there’s no mention of actually computing over this network.

I believe that Mr. Victor’s point in this talk was to remind of an era of incredible innovation in computer technology, the good ideas that came out of it and how many of those ideas were never realized (and that there hasn’t really been such an era of imagination since). I can appreciate that message, but I’m still asking the question: “So what?”

Building complicated systems is a difficult job. even with plain old text files we’ve managed to do a pretty good job so far. The innovations between then and now have been less flashy but for me, at least, more helpful. Research into distributed systems, machine learning and programming languages have given us powerful languages, tools and platforms which may look mundane and boring but let us get the job fairly well. Personally I’m more interested in type systems and static analyses that let me rule out large classes of bugs at compile time than in interfaces where I connect boxes to link functionality. While I hope that Mr. Victor’s vision of more interactive and imaginative interactions with computers becomes a reality, it’s not the most important one and it’s not the future I’m working towards.

Sunday Selection 2013-06-02

Happy June Everyone! Hope your summer is off to a good start. Here’s a quick round-up of interesting stuff from the last week of May.

Around the Web

What happened to the Internet productivity miracle?

This isn’t the first article (and it certainly won’t be the last) to ask the question of what effect our technology is really having on us. This one approaches the question from a different angle: why haven’t the documented booms in productivity in the early part of the last decade kept going till the modern day?

Open-plan offices make employees less productive, less happy and more likely to get sick.

I spend most of my time working in Cornell CS’s open-plan Systems Lab. Even though it’s open-plan, it’s quite spacious, the desks face away from each other, it’s generally quiet and it’s easy to ignore things around you and focus on work. At the same time, I still like having an office where I can close the door (and everything else). This article gives a summary of reasons why open plan offices are a bad idea and backs them up with references to studies and surveys.

A Perspective: Developers vs Microsoft

I’ve always had a mild interest in how changing technologies affect the communities and developers that depend on them. It’s interesting to read about how Microsoft’s changing APIs and platforms have attracted and then driven away the developers that build on top of them

Video

The Forge – For Anybody Hurting

I’m lucky to not have lost a family member or a close friend to suicide, depression or any other form of mental illness. However, I do know people who have been affected by it. And while I don’t really believe that watching a single video will cure depression or prevent suicides (though it may save a few people), I do think that this video has a message that’s worth listening to.