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.

Rust to OCaml via FizzBuzz

Last month fellow PL grad student Lindsey Kuper wrote a post about the Rust programming language and used the FizzBuzz problem as a running example to demonstrate Rust’s pattern matching features. While reading the post what was struck me was the resemblance to the OCaml language. After reading the post I sat down and ported Lindsey’s code to OCaml. The resulting code is on Github as a gist, feel free to take a look and fork away.

Lindsey’s Rust code and my OCaml code look practically identical (modulo syntactic differences like braces and semicolons). Both languages seem to support similar basic types and matching on them. I haven’t looked into Rust into any detail, but it seems like an interesting language. I’ve been using OCaml a fair amount over the past few months and I’ve come to miss its type system and pattern matching when working in other languages. I’m looking forward to seeing those features in a systems programming language and am particularly curious about how it will interact with an object syntax. There’s a big tutorial with lots of interesting stuff, so I’m looking forward to more exploring.

For your convenience, here’s the OCaml code: