We’ll always have native code

A few days ago my friend Greg Earle pointed me to an article with the provocative title of “Hail the return of native code and the resurgence of C++“. While the article provides a decent survey of the state of the popular programming language landscape, it misses the point when it comes to why VM-based or interpreted languages have become popular (and will continue to be so).

The reason why languages running on managed runtimes are and should continue to be popular is not quite as simple as relief from manual memory management or “syntactic comforts” as the author puts it. While both are fair reasons in and of themselves (and personally I think syntax is more important than is generally considered) the benefits of managed runtimes are more far reaching.

As Steve Yegge put it, “virtual machines are obvious“. For starters most virtual machines these days come with just-in-time compilers that generate native machine code instead of running everything through an interpreter. When you have complete control over your language’s environment there are a lot of interesting and powerful things you can do, especially in regards to the JIT. No matter how much you optimize your statically generated machine code you have far more information about how your program is actually running at runtime. All that information allows you to make much smarter decisions about what kind of code to generate.

For example, trace-based virtual machines like Mozilla’s Spidermonkey look for “hotspots” in your code: sections that get run over and over again. It can then generate custom code tuned to be fast for those cases and run that instead of the original correct but naive code. Since JavaScript is a dynamically typed language and allows for very loose, dynamic object creation, naive code can be very inefficient. Thus the runtime profiling is all the more important and can lead to massive speed improvements.

If you’re running a purely native-compiled language you miss all the improvements that you could get if you reacted to what you saw at runtime. If you’re writing an application that is meant to run for long periods of time (say a webserver for a large, high-traffic service) it makes all the more sense to use a VM-based language. There is a lot of information that the VM can use to do optimizations and a lot of time for those optimizations to kick in and have a definite performance benefit. In robust virtual machines with years of development behind them you can get performance that is quite comparable to native code. That is, unless you’re pulling all sorts of dirty tricks to carefully profile and optimize your handwritten native code in which case all bets are off. But honestly, would rather spend your days hand-optimizing native code or writing code that actually does interesting things?

Personally, I hardly think a new C++ standard is going to usher in a widespread revival of native code. C++ has problems of it’s own, not the least of which is that it simply a very big language that very few people fully understand (and adding features and constructs doesn’t help that). A fallout of being a complex language without a runtime is that writing debugging or analysis tools for it is hard. In Coders at Work both Jamie Zawinski and Brendan Eich denounce C++ to some extent, but Eich adds that his particular grievance is the state of debugging tools that have been practically stagnant for the last 20 odd years. Being fast, “native” or having a large feature list is not nearly sufficient to be a good programming language.

All that being said, there is definitely a place for native code. But given the expressive power of modern languages and the performance of their runtimes I expect that niche to keep dwindling. Even Google’s new Go programming language, which is ostensibly for systems programming and generates native code has some distinctly high level features (automated memory management for one). But if you’re building embedded systems or writiing the lowest level of operating systems kernels you probably still want to reach for a fast, dangerous language like C. Even then I wouldn’t be surprised if we see a move towards low-level unmanaged kernels fused with managed runtimes for most code in some of these places. Microsoft’s Singularity project comes to mind.

We’ll always have native code (unless we restart making hardware Lisp machines, or Haskell machiness) but that doesn’t mean that we’re going to (or should) see a widespread revival in low-level programming. I want my languages to keep getting closer to my brain and if that means getting away from the machine, then so be it. I want powerful machinery seamlessly analyzing and transforming source code and generating fast native code. I want to build towers on top of towers. You could argue that there was a time when our industry needed a language like C++. But I would argue that time has passed. And now I shall get back to my Haskell and JavaScript.

Just for fun

Let me tell you about Sunday. Sunday was, among other things, uncomfortably warm here in Ithaca, NY. And a combination of being woken up much earlier than I wanted and skipping breakfast guaranteed that I was quite cranky all morning. But anyway, by 1pm I was decently well fed and had a mini-conversation with my advisor while standing in the sandwich line (which of course involved a good amount of programming language talk). Being in a considerably better mood I decided to avoid the heat by heading over to Starbucks and writing some code.

For most of last semester I had been working on an Actor library in Ruby to do some fun little concurrency experiments. I had been wanting to take my code (which has very rough in the way that only research projects can be) and turn it into a proper Ruby actor library. On Sunday I started down that path.

I had been aware of some prior art in this area, in particular the excellent Revactor library. Until yesterday I hadn’t actally taken the time to dig deep into it. When I did, I was devastated. Revactor is beautiful, well thought-out, flexible powerful, elegantly implemented. With the exception of a few aesthetic details it’s everythng I wanted my own library to be and more. It was devastating because it seemed like all I could do was reinvent the wheel. What’s the point of writing or making something if someone’s already done it before and better? It’s the kind of crushing hopelessness I feel sometimes as a language researcher: it seems like Lisp did everything, 30 years ago, and did it better.

So after banging my head against the table for the better part of an hour (and wondering why the girl sitting next to me had two straws in her iced tea) I decided to go for a walk. At almost 6pm it was still uncomfortably warm but after ten minutes I found myself at the steps of the computer science building (unsurprisingly). I walked in, claimed a couch and started writing some code.

My new project isn’t brilliant research, it’s not scalable and high-performance, it’s not an infinitely reusable library with unit and regression tests. It’s just a little hackish thing I threw together in an hour. It doesn’t do very much yet but offers the promise of many hours of fun hacking ahead. It’s a fun personal project that scratches a little itch and is a lot of fun to code up. I’m writing a combination of C and Ruby, I’m living in Emacs and my terminal and I’m having a lot of fun at it. After a long, long time I’m having fun writing code and remembering why I got into this gig in the first place.

The thing is, at the end of the day, I sling code because I like to. Because it’s fun. If it stops being fun I might as well just give it up and hang up the keyboard (or keep the keyboard and write words instead of code). As Andrew Appel says, not all of us want to be logicians, some of us just want to be hackers. I like math and logic and performance analysis as much as the next guy, but I also like just the pure, raw feeling of code. I remember the allure of the machine as a mysterious black box – a well of infinite potential if only you could figure out how to bend it to your will. I remember a time when we used to be explorers – poking and prodding our systems, seeing how they reacted, how they bent, how we could change them and restore them, how we could make them do what they weren’t meant to do. I remember that it used to be a whole lot of fun. Yesterday I remembered all that and had a lot of fun doing it.

I don’t know why you do what you do, but I hope it’s fun. I hope that when you go to work everyday it’s because you really, really want to, because you can’t see yourself doing anything else that’s as fun. Feel free to change the world, to make it a better place to live in, to support and help the people around you, but please have fun while doing it.

Shell scripting: the silent hero

In 5+ years of using Linux I’ve never really taken the time to learn shell scripting. A combination of using mostly graphical tools, Emacs and other scripting languages means that I’ve rarely found myself in a position where I’ve had to depend on a shell script. In fact the most I’ve done is writing short aliases for longer commands I use on a regular basis. When I needed to do automation I generally fell back on Python (and more recently Ruby). I prefer using a small, uniform set of tools so I tried to do as much as I could within a bunch of Python scripts.

I’ve been doing some data collection work for my thesis and normally I would have been perfectly fine using Ruby and Rake for automation. Rake is Ruby task runner, similar to good old Make but with all the power of Ruby behind it. But I needed to run the same set of tasks under different Ruby VMs (specifically MRI and JRuby). So some of the automation needed to be outside of Ruby. I currently have a shell script that uses RVM to set the Ruby VM, runs a set of Rake tasks, changes over to another VM and repeats the Rake tasks. Each VM sends output to a different file. In between each iteration of Rake tasks, the shell script drops in the iteration number into the output file for that VM. I could have had this happen inside Ruby by passing the iteration number to the Rake task, but it’s easier to put it in from the shell script.

I’m using the BASH shell, mostly because it’s what comes default on Linux boxes, but I think what I’m going to say will be true of other shells like zsh as well. Shell scripting is a powerful tool for lots of reasons. Firstly the scripting language itself is pretty full featured. It may not be as clean and “batteries included” as Python or Ruby, but there’s enough there to get a lot done. Variables, conditionals, loops and functions are all there and the syntax is pretty relaxed compared to some languages (especially when it comes to interpolating strings or commands with variables). BASH also plays to the strengths of the Unix philosophy. It works well with the small, powerful UNIX utility programs and the idea that “everything is a file”. Being able to directly run programs and then pipe the results around is an extremely flexible way to get things done. IO redirection is also very powerful, especially if you’re working with files (like I am).

Perhaps the best thing about Bash scripting (that has been inherited by Perl, Python, Ruby and the rest) is that you can get stuff done with very little knowledge of shell scripting. It’s just as easy to pick up new tricks and tools as you go along. Personally, though I had only used aliases for years I was able to move up to functions, loops and conditionals in just a few hours. I wouldn’t say I’m a proficient shell scripter, but I could certainly hold my own against some ugly automation task at this point. Admittedly having a few years experience in similar languages helped as I knew what to look for.

I’m very glad I got a chance to add shell scripting to my personal arsenal of programming tools. For me, I’m not going to sit down with a book to study shell scripting in any formal way. I’ll keep my current knowledge tucked away in my brain for future reference and pulling it out (maybe adding to it) when I need to. It’s definitely a learn-as-you-go skill for me, but one that I’m glad to have.

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.