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.


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


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:

Sunday Selection 2012-04-28

Around the Web

Minecraft, Scrolls, 0x10c: The past, present and future of Mojang as seen through Notch’s eyes. I’m not much of a gamer, but I do like making cool stuff and I love reading about people who are making amazing, beautiful things. Notch is the creator of Minecraft and the anticipated 0x10c and this interview is full of interesting tidbits.

The Terrifying Reality of Long-term Employment As a recent college graduate who has chosen the temporary sanctuary of the ivory tower, the job market is something I can afford to avoid, but it’s still something at the back of my mind. The state of the current market makes me wonder if we need to rethink jobs and value structures in an age where long-term stability is increasingly rare.

The Boston Marathon Bombing: Keep Calm and Carry On. I usually don’t write about current events, partially because I’m never quite sure what to say, and partially because I’d rather not add to the noise if I don’t have something useful to say. That being said, I’m all too happy to point in the direction of people who I think are actually making level-headed and rational comments about the current state of affairs. Bruce Schneier is certainly one of those people and I can’t help but wonder how different the world would be if people like him were in charge of our security.


Capsule: The Developer’s Code Journal. I find that keeping a record of things I’ve done through the day is very useful. It’s a good estimator of where my time went through the day, and an empty log is a sign that things didn’t go quite right.  I normally have a text file on my phone that I just dump everything into. Capsule looks like an interesting solution for programmers (both teams and individuals) to keep a quick and dirty log of what they’ve been up to. I’m probably going to put it on my Linode for a week and give it a try.

Coding standards are communication tools

I’ve been writing a lot of C code over the past few months. It’s been fun and I’ve learned a good amount about writing solid, low-level, procedural code. While cranking out code I’ve also been developing a simple coding standard, mostly for my own use and based on on the K&R standard. I’m not working with a particularly large group (and probably won’t be anytime soon) so I won’t be asking anyone else to follow these standards anytime soon. They don’t follow the rest of the code 100% either. But even being essentially the lone hacker on the project, I’ve found sticking to a standard helpful.

C is a great language but often I want to say things as part of the program that I can’t put in the code. For example, there are often things about variables that aren’t captured by the type and even if they are, I don’t want to have to look up the type every time I see the variable to get that information. But by following simple rules about how my variables are named, I can pack in a lot of information. For example, a plural name is an array, a name prefixed with num_ indicates that it holds the number of something in the system, a name prefixed with rv_ means that it stores the return value from a function (probably for error handling). Outside of variables, function names are verbs, locally defined types meant to be private are CamelCased, exposed types have a _t suffix. Of course, these don’t apply in all cases and some amount of discretion is involved.

Following a standard like the above has a double benefit: first I can think less when it comes to naming things and it prevents casual naming conflicts. Secondly, as I hinted to above, it’s a communication aid. There’s a certain amount of information that is encoded into the language’s syntax and semantics. This layer is checked and enforced mechanically at compile time. But a coding standard allows for a secondary, optional layer that can convey more information without expanding the language standard (and allowing teams and individuals to develop their own, suited to the task at hand).

Note that I’ve mostly talked about naming conventions and I haven’t said anything about formatting. Personally I think formatting conventions are less important and helpful. It can be annoying to read code that is formatted differently across files (or in the same file), but I think the benefits to be gained from consistent formatting are less than that for consistent naming. In fact, I think that formatting issues should be eliminated by having a tool that will automatically reformat code to a single standard. I have the Go language’s gofmt tool in mind, but I’m sure there are others. (This is also one of the pet peeves I have with Haskell: it’s apparently really hard to write an auto-indentation tool for its syntax)

One caveat is that I have no personal experience as to what effect a coding standard has across a large group. I’ve found two articles arguing against coding standards on teams, but they’re both far too emotional and hand-wavy for me to take them seriously. Personally I would be wary of a developer who can’t adapt to a coding standard in a reasonable amount of time. That being said, there are definitely more important things than adhering to a standard (getting working code for one). However, I do think that coding standards fit into a larger culture and system of good coding practices. These include things like code review, appropriate use of version control and proper communication channels to talk about bugs and feature changes.

To conclude, a coding standard can be a great tool for personal uses. In some ways it frees up my limited mental RAM to think about more important things. It also allows me to pack more information into my code, outside of what the language syntax or semantics allow. I’m less certain of the benefits for large groups and as Emerson puts it, a foolish consistency is the hobgoblin of small minds. That being said, I’d like to believe that a good coding standard (with formatting mechanically enforced) along with practices like code review can lead to a higher code quality.

Sunday Selection 2012-12-09

Around the Web

A Funny Thing Happened on the Way to Academia

As my third semester as a PhD student draws to an end, I’m starting to think about what to do in the long term: what kind of a career I want to have, what kind of problems I want to focus on, etc. This piece is an interesting look at how research in computer science can coexist with making an impact in the real world today.

Trouble at Code School

I’ve been a Teaching Assistant for two semesters, but I haven’t really been on the front lines of teaching students. That being said, from what little experience I have introducing newcomers to programming that both teaching and learning beginning programming is no easy task. Luckily, with the growth of education-based startups and the resurgence in academic CS programs we’ll probably see interesting approaches in the near future.

GitHub vs Skyrim

Giles Bowkett manages to come up with interesting perspectives on a regular basis. This article talks about about GitHub and Skyrim and how the way they encourage team dynamics may lay the foundation for a new way of organizing companies and teams. Perhaps the most insightful idea is that the very definition of an office or workspace is not only changing, but gradually becoming irrelevant as work becomes increasingly distributed.

From the Bookshelf

Surely You’re Joking Mr. Feynman

I first read this book years ago in school and it was probably the first book to show me that you can fill a life with equal parts work and fun. This book probably played an important, though subconscious part in my decision to stay in academia for the time being. Even if you’re not a scientist or and academic, this book is worth reading and learning from. Life is supposed to be fun.