Rys Sommefeldt

Programmer productivity is king

My ongoing adventures in Ruby have given me a new insight into the importance of programmer productivity in the success of any given programming system. I define system here to be not only the programming language, but everything surrounding the language that the programmer also has to make use of to create and execute useful programs.

Ruby as a programming language has many — quite glaring in places — flaws, at least as far as my opinion goes. However, I can overlook almost all of them in light of the richness of the rest of the Ruby system that goes along with it. The standard library has a very well specified set of scalar primitives, collections and functionality that goes incredibly well with Ruby’s expressive syntax and copious syntactic sugar.

irb, and more recently pry (the tool that actually prompted this blog post), are first-class REPLs and debugging tools that let you prototype code and debug running programs without the wasteful, time-consuming fucking tedium of the compile-run or save-request development models of other programming systems without similar tooling, or support for something like a REPL at all.

The community-supported gem and bundle system, along with rvm, make choosing a Ruby, along with the application- and system-specific supporting code you need, a doddle. Swapping to and experimenting with new Rubies is trivial, and can be tried per-application invocation or request, often without actually changing the application or web server binaries or runtime configuration.

Rack as a well-defined, well-specified web application middleware has made it trivial to write portable Ruby web applications while not giving a shit about what eventually serves it in development or production, resulting in myriad solutions like Pow that take all of the pain out of configuring your application server.

I remember the horror of setting up my development environment at Plusnet, in order to get started at the company and again when changing development machines. It was a running joke of an experience, suffered by ploughing through an out-of-date, poorly maintained set of instructions that gave you something that was supposed to look like the live application and data environment, but in reality gave you some poor bastard representation that barely worked.

It was a rotten spaghetti trail of symlinks, broken opcode caching and Apache configuration, executed by an almost completely random version of PHP. Start work for Plusnet without Linux experience in those days and it took literally days if not weeks of constant tuning and bothering other people who were trying to be productive while they wrestled with the same shit, in order to get something that executed all of the code in production.

The equivalent in modern Ruby would take minutes. We eventually ended up architecting a virtualised environment at Plusnet to mitigate that disaster, but even that, elegant as it was in the end, was overkill. All that just to sugar coat the horrible programming system they used. It makes me shiver just to think about it.

This isn’t to say that putting Ruby into production on the Internets in web application form is painless — Phusion Passenger I look at you most of all. However, it is much simpler than almost anything else I’ve tried in the same space.

The end result is that programming in Ruby, at least for me and the things I’m writing, doesn’t feel like a fight against the system. The language is only fractionally responsible for that; it really is the tooling, documentation, great standard library, package management, excellent REPLs and operating system agnosticism that really works in its favour.

If only all programming were this much fun.