Enforcing coding conventions

It’s Black Friday which means that in most of the United States people are out shopping taking the advantage of supposedly great deals. I’m not indulging because I try to only buy stuff when I absolutely need instead of getting something just because it’s cheap. However the one thing that I did buy was the Kindle edition of the Joel Spolsky edited “The Best Software Writing”. It’s a collection of talks and articles about software. I could probably have gotten all the material for free online, but I decided to pay the $9.99 to actually get the Kindle edition. It’s the first actual Kindle book that I bought and I spent a good hour today reading it.

The very first article in the collection is “Style is Substance” by Ken Arnold. It is a suggestion to do away with differing coding formats and conventions in programming languages and instead having a single style for the language that is written into the language’s grammar. Thus if you write a program that violates the format rules, it’s not just ugly or bad form — it’s actually an incorrect program that will not compile. The suggestion is probably not a very popular one. In particular, programmers tend to be rather defensive about these sort of personal preferences — coding style, editor, version control tool, all have been know to trigger religious wars (and still often do).

Personally, I can understand the lure of having a single, undisputed code format that is enforced by the compiler. No more spending time figuring out where one block ends and another begins. No more spending precious mental cycles figuring out someone else’s conventions. One of the reasons I like Python is that it’s such a clean, yet flexible language. But on the flip side, I’ve generally been a fan of letting programmers use whatever tools they like as long as they get the job done. From that perspective, coding convention is just another tool and people should be allowed to use whatever one makes them work better.

However, the argument that code formats are just another personal preference doesn’t really hold up. In particular, unlike editor color schemes or other such preferences, code is something that is meant to be shared with other people. One of the greatest lessons I’ve learned from SICP is that programs must be written primarily for people to read and only incidentally for computers to execute. Since code will be shared, it makes sense to take measures that ensure that it will easily readable and comprehensible by other people. Having different coding is less like everyone using a different editor and more like everyone using a different XML schema to exchange documents. OK, it’s not quite so extreme, but it can be close.

If you’re someone writing a compiler or a language and you decide to enforce a single format, the next question is: which one? I would say for current popular languages like C, C++ or Java trying to answer such a question is a futile effort. It’s not that you couldn’t change a compiler to implement a particular style. The problem is rather that there are already too many conventions in place and you’d have civil war if anyone tried to enforce a particular format at the compiler level. If we are to take the idea of a single correct format seriously, it has to be implemented in a new, or at least not-completely-mainstream language. Haskell already has whitespace indentation built into the language. Instead of using curly braces to enclose statements in a function definition, you can use indentation in a manner similar to Python. This is built into syntax and violating the indentation rules will cause the compiler to fail.

Go takes a different approach. Instead of writing format rules into the grammar and compiler, there is a program called Gofmt which will reformat any syntactically correct Go format into the standard Go format. It can also be used as a syntax translator meaning that as the Go language changes, Gofmt can be used to automatically upgrade programs written in an older version of Go to a newer version as long as the changes can be described as syntax transformation rules. Gofmt is a powerful program and sets a high standard for language and developer oriented tools.

So will the languages of the features have strict formatting that minimize the amount the time we waste mentally translating between formats? Maybe. But I doubt that it will be considered a standard part of mainstream languages any time soon. While we have curly brace languages people will continue to expect that the various conventions of the current curly brace languages will also be applicable. Stylistically different languages like Haskell (and to some extent Go) will probably lead the way in changing the way we think of conventions and programming style. It’s interesting and a bit intimidating to see how far the bar for new programming languages has been raised in recent years, but that’s a topic for another blog post.

What are you thankful for?

It’s Thanksgiving Day here in the US of A and that means in a few short hours millions of people will be sitting down to wonderful feasts of turkey, stuffing, mashed potatoes, gravy and the like and in the process express their gratitude for whatever is important in their life. And it just happens to be the first snow of the season for us in eastern Pennsylvania. All of that makes me happy.

In keeping with Thanksgiving tradition I’d like to take a blog post and reflect on what it is I’m thankful for. There are the usual things for which I’m thankful for — my parents, a roof over my head, warm clothes and a reasonably full stomach. But I’m also thankful for things which aren’t of the bare necessities variety. In particular I’m thankful for computers, the great advancements of recent times, the fact that I’ve found something I love doing and that people seem to be willing to pay large sums of money for.

Over the last few months I’ve come to the realization that if we didn’t have computers, I don’t know what I would do with my life. I do like other things — reading, writing, music, physics, history, economics to some extent, but I don’t see myself being able to do any of them as a full time job. What’s perhaps even more amazing that almost all I’ve learned about computing has been on the backs of essentially free tools and services. Again, I don’t know what I would do if I had to pay hundreds or thousands of dollars for developer tools. Thanks to the rise of Firefox, Apache and the web we all owe some thanks to free and open source software, even if we’re not programmers or hackers.

I’m grateful that I can afford multiple machines running a wide variety of languages, compilers and other tools. I’m grateful that I don’t have to wait overnight for my punchcards to come back so that I can fix a typo. And I’m really really grateful that I’m not running an operating system that crashes a dozen times a day taking all my data with it. I’m grateful that almost all the information I need to feed my interests is available for free on the Internet — that I don’t have to pay some large corporation or government to access something that has been created by other free individuals (basic bandwidth charges not included). I’m grateful that I can carry around the Internet in my pocket, as well as more books and musics than my great-grandparents had access to their whole lives. I’m also grateful that I can turn all of it off if I really wanted to (and sometimes that comes in very handy).

I’m thankful to the giants on whose shoulders I stand on every day, often for hours on end (sometimes just to admire the view). I’m thankful to people who are just starting to stand on my shoulders for showing me that I can stand up straighter and carry more weight with less effort. I’m thankful to be surrounded by people who willingly give their time and effort to make me a better person.

In a word, there’s a lot I’m thankful, a lot of which I barely even think about. And now excuse me while I go stand by the window looking at the snow falling on the trees and be thankful that I have a rather nice view out the window.

The exploding computer test

I came across an article about the exploding computer test. The gist of it is this — if you’re current computer met with some sort of catastrophic failure and was irrecoverable, how long would it take you to get up and running on a new machine? For me the test is a bit less demanding since I have multiple computers set up that could be pressed into service at a moment’s notice. But for argument’s sake let’s say that I am given a fresh new machine. Here’s what I’d do.

Install OS X or Linux

If I got a blank OS X machine things would go a bit faster. But if I got a stock Windows machine (like both my main computers were) then I’d start by putting Linux on it. If I was in a rush it would be Ubuntu which AFAIK has the fastest, simplest install. If I had a little more time I’d install Arch Linux since that’s what I’m more comfortable with, even though it has a longer initial setup time.

Install Git, Emacs and Chrome/Firefox

These are the three basic programs I need to get work done. I’m supposing that I already have some kind of terminal program since both Linux and OS X have them by default. On Ubuntu or Arch all of these are just a few commands away. They’d take a bit longer in OS X, but not really long enough to make much of a difference. With that done I can move on to retrieving all my data.

Cloning git repositories or getting stuff off Dropbox

Once I have Git getting back to a working state is mostly a matter of just cloning the repositories I need from my server. Everything I work on alone is in a Git repository and all my groupwork is in Dropbox. Getting all this back is just a few minutes work at most. If I was going to be working a lot on stuff living in Dropbox I’d install the client too. If nothing else, I would definitely get my system configuration repo and my Emacs setup repo since I consider them both absolutely essential to getting work done quickly.

Install compilers, interpreters, debuggers etc.

By this point I have my generic setup done. The last part is installing whatever project specific things I need. For example, if I need to work on my thesis I’d get GCC, GDB, Flex, Bison and Ruby. If I wanted to work on one of my JavaScript experiments, I’m all set because all I need is a browser my js2-mode for Emacs. But most of these are things I’d installed as I needed and I could get started on work again without waiting to have everything installed.

How long would it take?

The biggest variable here is the OS install time. For a Mac it’s basically zero, while for Arch it could be an hour or two. But like I said, if I was in a hurry I’d just install Ubuntu and be done with it. But even factoring in that uncertainty, it shouldn’t take more than a handful of hours. I’m hesitant to give an exact amount, but if I started right after lunch I would certainly be getting work done well before dinner time. Without having to do an OS install I could probably be up and running within the hour.

It’s been a long long time since I’ve actually had to set up a work machine from scratch. I’m a bit surprised as to how little I need to get to a work setup again. I remember when I was in high school getting back to working meant installing Windows, Office, Firefox, a Java environment called BlueJ and a bunch of other little things all of which took a good amount of time to install. I’m definitely at the stage when where my tools and workflow are very different from the average users. As the days go by I’m only becoming better and faster at getting stuff done, but that’s a matter for another blog post.

You are a Turing machine

As part of my graduate school search and application progress I came across a talk by Dr. Manuel Blum about being a graduate student. What stood out most to me was the part where he tells us how we’re all Turing Machines:

You are all computer scientists.
You know what FINITE AUTOMATA can do.
You know what TURING MACHINES can do.
For example, Finite Automata can add but not multiply.
Turing Machines can compute any computable function.
Turing machines are incredibly more powerful than Finite Automata.
Yet the only difference between a FA and a TM is that
the TM, unlike the FA, has paper and pencil.
Think about it.
It tells you something about the power of writing.
Without writing, you are reduced to a finite automaton.
With writing you have the extraordinary power of a Turing machine.

Like Dr. Blum tells us: Think about it for a moment. We have the extraordinary ability to not only read and think, but also to record our thoughts and our learnings. But what’s just as important is that writing and recording is not a passive process. The very act of writing our thoughts requires us to go through them again, organizing and editing. In fact, I would say that if you’re involving writing at some part of your thinking process, you’re doing it wrong.

While writing is a way for you to cycle through your own thoughts and self-edit, talking about your thoughts and ideas is just as powerful a thinking technique. I’ve found that having the chance to bounce ideas of someone can be a godsend when I’m stuck on a hard problem.

I had a chance to go through both of these processes today. I’m building a programming language as part of my honors thesis, but I was having some serious doubts as to the point of it and the way I was implementing it. When I showed up for my weekly meeting with my advisor, I didn’t really expect to walk out with a solution, but that’s what happened. We talked about the goals of the language, concurrency vs parallelism, applying the scientific method and a number of other small details.

If I had just walked away with that, my problem would have been solved. But I decided to take an hour to sit down and write it all down. The result was the first Parley Blog Post which captures the main ideas behind Parley. I should have been blogging about Parley from the start (and I think that would have helped me be a bit farther ahead than I am now) but late is better than never.

Writing is important. It’s helpful and it helps you think and organize your thoughts. But it’s also time-consuming. Let’s face it: writing takes time and most of that time we’d rather spend doing something else (probably writing code). As with all important things in life, if you really value it you make time to do it. However, it helps if you’re a really fast typist (and have a good keyboard). The good thing is that if you’re writing out your thoughts and using it to improve your thinking process, you don’t have to keep it to yourself. Thanks to our networked world, anything that you write can be instantly shared with almost anyone you want. That means that not only are you doing yourself a favor by writing stuff down, if you post to a blog or mailing list you’re also helping other people out. We’re already at the point where the sum total of human knowledge is far far more than any one person can comprehend so it becomes increasingly important that when people to find something or reason about something that they put it down for people after them to easily find.

In conclusion: you are a Turing Machine. Writing things down is a very effective way to improve your thinking and communicating your thoughts to other people for effectively no extra cost. Since writing stuff down takes time, it’s also in your best interest to learn how to type.

For the art of the hack

I think computing should be fun. Both programming and using them should be fun and if not easy, at least not menial and the rewards should be worth the time and effort put into it. Many of us write code on a daily basis, read about programing, blog about programming and generally consider it much more than a job. But after years and hours spent hunting bugs, dealing with incomplete APIs, non-existent documentation and multiple layers of questionable usefulness, it’s not hard to feel jaded and just a little bit fed up with writing code. At times like that it’s really helpful to see fun little projects which remind us about why we became hackers in the first place.

A latent gift

The first is a latent gift from the hacker formerly known as _why the lucky stiff. He was a hacker in the truest sense of word. Not only was a prolific programmer, he was a pretty darn good teacher (I believe he preferred the term “freelance professor”) and had a wonderful sense of humor. He wrote a number of great teaching tools including Hackety Hack and Try Ruby. _why suddenly disappeared from the Internet in 2009 but most of his projects have been collected on Github. Today on the Hackety Hack blog there was a post about how the author had completely by accident discovered a complete vector editor with a color picker and support for drawing shapes.

It’s a rather masterful hack. A very useful little program hidden almost in plain sight just waiting for the unsuspecting user to stumble upon it and experience a “WOW” moment. It reminded me of all the little wow moments I had (and still have) when I realized that I could make the computer do just about anything I wanted with the right incantation. As the author says, finding the little gem doesn’t just make you say “that’s cool”, it also makes you wonder why you never came across it and how _why managed to slip it past you. It brings out the hacker in all of us.

One line at a time

I’ll admit that I’m not entirely excited about the rise of the browser as an application platform, but the doubts I have are somewhat balanced when I see things like a complete website tucked into a simple command line. Eneko Alonso’s website is a really neat example of the power of JavaScript and the result is a hacker’s delight. Anyone who’s spent any time in front of a command prompt (UNIX or not) will be instantly at home.

Again, it’s a really neat little hack. It’s not going to change the world, it’s doesn’t solve interesting research problems, it’s just something that makes you smile and say “that’s cool”. It serves a purpose and solves a problem (showing Alonso’s website) and does it in a fun, novel way. Perhaps just as importantly, it flies in the face of what most people would consider a typical personal website. Would you send it to a potential employer or graduate school? If you were looking for people who shared your sense of humor and your love of the hack, then yes, you would.

Hackers first, programmers second

The more I interact with people in the field (mostly via the Internet) the more I’m convinced that we are hackers first, programmers second and that our use of computers is mostly incidental. If we lived in age without computers we would have been greasemonkeys, artists and inventors. Some of us would probably have built the first computers. It’s not really about computers, or programs or code. It’s about solving interesting problems, doing fun things and coming up with useful, quirky and uplifting inventions. Computers just happen to provide the quickest and cheapest way of doing all those things (and just as importantly, telling other people about them).

And it’s not just confined to computers either. Take a look at  Hack a Day and you’ll come across people building all sorts of interesting and some downright weird things out of all sorts of components. Within the next few decades we’re likely to see a similar trend spread through biology (though at this point, I’m not entirely sure that it’ll take the same form as the computer hacker movement). Even today, people are hacking books, business, social service and so many incredibly varied things.

The art of the hack lives on.