Zen and the Art of Programming

The Great Ruby Shootout (July 2010)

2010-07-21T22:12:55Z

The Great Ruby Shootout measures the performance of several Ruby implementations by testing them against a series of synthetic benchmarks. Recently I ran Mac and Windows shootouts as well, which tested a handful of implementations. However this article reports on the results of extensive benchmark testing of eight different Ruby implementations on Linux.

The setup

For this shootout I included a subset of the Ruby Benchmark Suite. I opted to primarily exclude tests that were executed in fractions of a second in most VMs, focusing instead of more substantial benchmarks (several of which came from the Computer Language Benchmarks Game). The best times and least memory allocations out of five runs are reported here for each benchmark.

All tests were run on Ubuntu 10.4 LTS x86_64, on an Intel Core 2 Quad Q6600 2.40 GHz, 8 GB DDR2 RAM, with two 500 GB 7200 rpm disks.

8 implementations

The implementations tested were:

Ruby 1.8.7 p299
Ruby 1.9.1 p378
Ruby 1.9.2 RC2
IronRuby 1.0 (Mono 2.4.4)
JRuby 1.5.1 (Java HotSpot(TM) 64-Bit Server VM 1.6.0_20)
MagLev (rev 23832)
Ruby Enterprise Edition 2010.02
Rubinius 1.0.1

JRuby was run with the –fast and –server optimization flags.

Disclaimer

Synthetic benchmarks cannot predict how fast your programs will be when dealing with a particular implementation. They provide an (entertaining) educated guess, but you shouldn’t draw overly definitive conclusions from them. The values reported here should be assumed to be characteristic of server-side — and long running — processes; they should be taken with a grain of salt.

Time Results

Please find below the execution times for the selected tests. Timeouts indicate that the execution of a single iteration for a given test took more than 300 seconds and had to be interrupted. Bold, green values indicate the best performer out of each test.

Warning: The bm_primes.rb benchmark was originally written to aid the development of the Prime class. As such in 1.9.2 it was rewritten in C, which makes it a poor representation of implementation performance. This benchmark will removed in the future.

If you are not interested in the individual test results, the information presented in the table above is summarized directly below:

  Ruby 1.9.2         JRuby
Min.   : 0.013   Min.   : 0.382
1st Qu.: 3.258   1st Qu.: 3.051
Median : 4.543   Median : 4.997
Mean   : 9.262   Mean   : 9.180
3rd Qu.: 8.573   3rd Qu.: 8.969
Max.   :45.009   Max.   :48.850

    MagLev         Ruby 1.9.1
Min.   : 0.351   Min.   : 0.015
1st Qu.: 2.140   1st Qu.: 3.387
Median : 6.069   Median : 6.205
Mean   : 9.100   Mean   :10.860
3rd Qu.: 9.266   3rd Qu.:11.559
Max.   :51.221   Max.   :46.849

 Ruby 1.8.7         IronRuby
Min.   : 0.708   Min.   :  3.601
1st Qu.: 5.102   1st Qu.: 10.505
Median : 8.380   Median : 12.912
Mean   :18.785   Mean   : 26.539
3rd Qu.:24.793   3rd Qu.: 36.115
Max.   :75.653   Max.   :135.204

   Rubinius           REE
Min.   : 0.484   Min.   : 0.584
1st Qu.: 3.087   1st Qu.: 4.343
Median : 9.636   Median : 6.660
Mean   :13.232   Mean   :15.036
3rd Qu.:17.674   3rd Qu.:21.336
Max.   :73.050   Max.   :61.960

For the sake of convenience, I also produced a box plot from the successful data points:

There are a few considerations based on these results that I feel are worth mentioning:

As you can see Ruby 1.9, JRuby and MagLev converge towards a similar performance level according to these tests.
Ruby 1.9.2 manages to squeeze in a bit of extra speed when compared to Ruby 1.9.1 (which is a welcome improvement).
Ruby 1.9 seems to be either much faster than Ruby 1.8 or roughly as fast, depending on the test. This appears to be in line with what I’ve seen in real world programs. There are programs that will only receive a 10-20% boost from 1.9, while others improve drastically. The results really depends on what a program spends its time doing.
Performance wise, Rubinius is really starting to be a much more serious contender.
Ruby Enterprise Edition is slightly faster than Ruby 1.8.7, to the extent where this is clearly visible in almost all of the tests.
IronRuby running on Mono was the worse of the lot.

Memory Results

The following table shows the approximate memory consumption for each implementation when running each benchmark:

Summarized:

  Ruby 1.9.2        Ruby 1.9.1
Min.   :  4.320   Min.   :  4.580
1st Qu.:  4.378   1st Qu.:  4.695
Median :  6.285   Median :  6.920
Mean   : 20.795   Mean   : 15.669
3rd Qu.: 10.162   3rd Qu.: 11.383
Max.   :171.500   Max.   :100.570

   Ruby 1.8            REE
Min.   :  3.040   Min.   :  8.220
1st Qu.:  4.290   1st Qu.:  9.682
Median :  7.745   Median : 15.565
Mean   : 20.698   Mean   : 27.014
3rd Qu.: 11.273   3rd Qu.: 38.620
Max.   :103.520   Max.   :125.910

  Rubinius           MagLev
Min.   : 37.63   Min.   : 81.74
1st Qu.: 39.78   1st Qu.: 82.52
Median : 45.48   Median : 83.53
Mean   : 65.70   Mean   : 96.29
3rd Qu.: 58.22   3rd Qu.: 98.10
Max.   :215.33   Max.   :175.85   

    JRuby
Min.   : 49.04
1st Qu.: 71.23
Median :176.72
Mean   :169.41
3rd Qu.:209.04
Max.   :404.06

And finally, in graph form:

A few considerations on memory:

Memory readings for IronRuby were not available, so they were not included.
Ruby 1.9.2 uses the least amount of memory (as one might expect).
JRuby was by far the most memory intensive of the group.
Ruby Enterprise Edition used less memory than 1.8.7 in a few tests, but overall was more memory hungry than 1.8.7. This is really odd and entirely unexpected.

Linux Vs. Windows

This shootout and the Windows one were both performed on the same machine, thus we can compare how the same implementation perform under different operating systems. The only adjustment that’s required is the timeout. Every result longer than 60 seconds from this shootout needs to be considered a timeout, because the previous shootout did so as well.

It is commonly believed that Ruby performs much better on Linux than on Windows (with the exception of IronRuby). Let’s find out if these test results confirm that notion.

Ruby 1.8.7:

Ruby 1.9.2:

JRuby:

Finally, in chart form (yellow entries are on Windows as indicated by the labels containing W):

To use a beloved MythBusters expression, this myth is confirmed.

Note: As requested by a few commenters, here is a comparison of IronRuby as well (.NET 4.0 Vs. Mono 2.4.4):

Conclusion

In conclusion, let me just state that it’s nice to see several implementations getting faster. Ruby 1.9.2, JRuby, MagLev and Rubinius are all becoming serious competitors and working their respective ways closer to a similar performance level. If you think these benchmark shootouts are becoming boring, then the results are becoming more stable and predictable. I suspect that as time goes on, performance will not be the real distinguishing factor when choosing a Ruby implementation, other features will be.

In-Depth Book Review: Practical Clojure

2010-07-20T04:22:38Z

Title: Practical Clojure
Authors: Luke VanderHart and Stuart Sierra
True pp.: 198
Publisher: Apress
Published on: June 2010
ISBN-13: 978-1430272311
Rating: 6.5/10

Published in June 2010, Practical Clojure by Luke VanderHart and Stuart Sierra is the latest Clojure book to hit stores. Despite the Clojure 1.0 jar shown at the beginning of the book, this title tries to cover the current version of the language, including references to concepts that will be introduced by the upcoming 1.2 version.

The target audience of this book is programmers who are absolutely new to Clojure. It didn’t strike me as being particularly aimed at developers who are coming from the Java camp, or the Lisp camp; in this regard, the book is rather “background agnostic”, even though Lisp programmers will feel much more at home than Java programmers will, due to the nature of the language itself.

The authors of the book are clearly well versed in this new language (Sierra is part of Clojure/core, the equivalent of the A-Team in Clojureland) and their confidence with the concepts presented is demonstrated throughout the book. Their explanations tend to be clear and to the point. Longer discussions are occasionally included when required to introduce concepts that are novel to most programmers, like the Software Transactional Memory (STM), refs, atoms and agents.

The book starts out by presenting a short but well-argued case for why Clojure is a worthwhile language, and then focuses almost exclusively on the core of the language. I’m afraid they do so to the detriment of the ecosystem surrounding Clojure. The authors don’t talk about how to install Clojure, recommend editors and IDEs (albeit a few are casually mentioned), or how to use build tools like Ant, Maven or Leiningen.

clojure.contrib, a fundamental extension library, is barely mentioned and there is no coverage of other important libraries or emerging frameworks. For instance, perhaps expectedly, Compojure (a web framework) and Incanter (a statistical and graphical environment) are only mentioned as examples of DSLs, however examples of their usage are not provided. (I believe the authors mistakenly refer to Compojure as Enclojure, which is a different project).

Despite the narrow focus, Practical Clojure doesn’t shy away from complex subjects and manages to include a chapter on Java interoperability, parallel programming, metaprogramming, and performance considerations. It does so briefly however, favoring a cursory presentation of the fundamental concepts rather than in-depth coverage, which would provide the reader with the degree of confidence required to approach real world problems.

The core language is covered in a manner that acts as both a tutorial and a reference. Major concepts, data structures, and common functions are presented to the reader with an endless supply of tiny examples. It’s easy to fly through them, but typing along in the REPL will be a far more valuable exercise for readers who hope to retain the information presented.

This leads us to another shortcoming of this book, which is the lack of more structured and complex examples. When I define their examples as “tiny”, with very few exceptions, I really mean it. For the first few chapters of the book the examples don’t get much larger than calculating the square root of a number through Newton’s method or adding contacts to an address book. Most of the other examples do a good job of illustrating the point they are trying to make with one, two, or just a handful of lines of code.

This is an actual sample of the kind of examples you’ll find throughout the book to illustrate many core API functions:

user=> (reduce + [1 2 3 4 5])
15

Note that this approach is didactically valid, because it isolates the function to show exactly how it works. After dozens of these functions though, you may expect larger examples to show how to integrate the use of some of these functions and data structures you’ve learned about. Such examples are seldom included. Furthermore, the book lacks any exercise for the reader. Foundational books that fail to offer many articulated examples and that lack exercises, tend to make it hard for the reader to retain the information and get some hands-on practice.

I have lots of respect for short books that get to the point and avoid wasting the reader’s time. K&R is notoriously acclaimed thanks to its clear and concise nature. However, Clojure is not C, and I feel that the 198 pages fall a little short when it comes to introducing this wonderful language to new readers. There is more to Clojure than simply surveying the language itself, even though I suspect that certain readers may appreciate this extremely narrow focus.

Overall the book is well-edited, despite the presence of minor issues. Aside from a few typos (e.g., “becauseall” on page 79), readers may find the formatting to be slightly inconsistent at times. For example in chapter 5 when presenting sequences, after the map function has been introduced, the font for the subsequent functions is substantially decreased for no apparent reason. Readers may be misled into thinking that the functions presented afterwards are somehow different from the previous ones, when in fact they’re all defined in clojure.core. In Listing 6-3, at page 103, the authors present their first “complex” example (the address book) and they do so by using, among others, doseq. This macro was not introduced before that page nor is it really explained within the example.

From a physical standpoint, this book is a rather thin and wide paperback. A small font, coupled with small margins and a wide layout, imply that the readability of the book suffers a little. The paper itself is off-white, fairly thick and slightly textured, not as pleasant to the touch as other books by Apress or most other technical publishers, even though I recognize that this is a matter of taste (some people may actually love it because of these characteristics).

With two introductory Clojure books on the market, drawing comparisons is unavoidable. Stuart Halloway’s Programming Clojure is a slightly older book (published in May 2009), which grants Practical Clojure a distinct advantage. This is not to say that Programming Clojure is obsolete, on the contrary it’s still a valid choice, but it doesn’t illustrate some of the new features that are available today. For example, in chapter 13 Practical Clojure introduces protocols and datatypes that will be available in Clojure 1.2 for the first time. Given that Halloway’s book was published more than a year ago, there was no possible way he could have included such powerful abstractions at the time.

Despite being older and less methodical than Practical Clojure, Programming Clojure tends to offer more complex examples. In the introduction of Programming Clojure you’ll see examples which Practical Clojure fails to include until much later in the book. Practical Clojure, the subject of this review, may leave you wanting for more practical examples of how all the language features fit together. Whereas Programming Clojure may leave you longing for more consistent explanations of how each part of the language works on its own.

Practical Clojure and Programming Clojure are competitors in the marketplace, but it wouldn’t be a bad idea to get ahold of both, because they complement each other quite well, in my opinion. Having to pick just one, I would probably recommend Practical Clojure, given its more consistent and up to date presentation. The sizzle offered by Programming Clojure, can be found to a much greater degree in upcoming and less introductory books, such as The Joy of Clojure. In this sense, reading Practical Clojure first followed by The Joy of Clojure, would be a solid learning path (Clojure in Action is another worthy addition, but it doesn’t replace The Joy of Clojure, which is a real gem).

In conclusion, Practical Clojure is not the Clojure equivalent of the highly praised Practical Common Lisp, from the same publisher. Reading it cover to cover and typing all the snippets included within, will not give you enough knowledge to start writing complex, idiomatic Clojure programs out of the gate.

However, if you are learning Clojure today, I do recommend this book. It’s a clear, well thought-out, concise introduction to the language that will give you a solid foundation as you go on to learn more about Clojure and Lisp in general.

How to setup Clojure from scratch

2010-07-13T21:11:49Z

My previous post about Clojure generated quite a bit of interest, so I thought I’d follow it up with something a bit more concrete. I primarily wrote this article for a friend who asked me for guidance on how to set it all up; and while this isn’t he only way to setup Clojure, I hope it will help other people who are also getting started with this great language.

As some people pointed out, setting up your Clojure environment can be slightly challenging. For example, when you install Ruby or Python, you can expect a Read-Eval-Print Loop (REPL) such as IRB or IDLE to be ready for you to use right out of the box, whereas the current version of Clojure (version 1.1) does not include an interactive top-level.

This post explains how to setup a Clojure environment step-by-step, including a working clj script (the common name for Clojure’s REPL). For this post I used the clj script contained within the Getting Started guide on Wikibooks as a base, but I built on top of it , so as to customize and improve it. In writing this post, I’ve made the assumption that you’re using a *nix environment. My instructions will be Mac OS X specific, even though it should be a breeze to adapt them for Linux, if required.

Step 1: Download and Build Clojure

The first step is to download and build the latest version of Clojure. (Please note, I used bit.ly below for code formatting reasons.)

$ cd /tmp
$ wget http://bit.ly/clojure
$ unzip clojure-1.1.0.zip
$ cd clojure-1.1.0
$ ant

This will generate several jars for us, including clojure.jar, which we’re interested in. Aside from clojure.core, we are also interested in clojure.contrib, a collection of useful libraries and functions that are often used in Clojure programs. To download and build clojure.contrib, follow these instructions:

$ cd /tmp
$ wget http://bit.ly/clojure-contrib
$ unzip clojure-contrib-1.1.0.zip
$ cd clojure-contrib-1.1.0
$ ant

This should generate a clojure-contrib.jar file. We can now proceed to copy both the clojure.jar and clojure-contrib.jar files to a convenient location. (You can copy the files with a single line, but for formatting reasons I split the operation into two copy operations).

$ mkdir -p ~/Library/Clojure/lib
$ cd ~/Library/Clojure/lib
$ cp /tmp/clojure-1.1.0/clojure.jar .
$ cp /tmp/clojure-contrib-1.1.0/clojure-contrib.jar .

Note that on Linux, you’d choose a different location (e.g., /opt/clojure/lib).

Step 2: Install rlwrap

Before we can proceed with creating a fancy clj script, we need rlwrap, which will make our interactive prompt much more friendly. On Mac OS X, if you are using MacPorts, you can simply run the following:

$ sudo port install rlwrap

Step 3: Create a clj script

Now we can finally finally create a clj script and save it as ~/Library/Clojure/clj:

#!/bin/sh
breakchars="(){}[],^%$#@\"\";:''|\\"
CLOJURE_DIR=$HOME/Library/Clojure/lib
CLOJURE_JAR=$CLOJURE_DIR/clojure.jar
CONTRIB_JAR=$CLOJURE_DIR/clojure-contrib.jar
CLOJURE_CP=$CLOJURE_JAR:$CONTRIB_JAR:$PWD

if [ -f .clojure ]; then
	CLOJURE_CP=$CLOJURE_CP:`cat .clojure`
fi

if [ $# -eq 0 ]; then
	exec rlwrap --remember -c -b $breakchars \
                -f $HOME/.clj_completions \
                java -cp $CLOJURE_CP clojure.main -i $HOME/.clojure.clj --repl
else
     exec java -cp $CLOJURE_CP clojure.main -i $HOME/.clojure.clj $1 -- $@
fi

Make it executable and symlink it to a convenient place on your path (e.g., ~/bin):

$ chmod a+x ~/Library/Clojure/clj
$ ln -s ~/Library/Clojure/clj ~/bin/.

At this point we almost have a working script. Before declaring it fully functional, let’s take a look at three files this script references:

.clojure: This file is optional and is located in the same folder as the scripts you want to execute. It can be used to include further jars in your classpath.
~/.clj_completions: Includes a list of Clojure functions for tab completion (courtesy of rlwrap).
~/.clojure.clj: Your Clojure startup file. It’s the first Clojure file that’s run when we start the REPL or execute a script. We’ll use this to add a couple of nice functions to the default clj REPL, but you can add anything you’d like to load at startup.

Step 4: Create a startup file

By default, clj will not have an exit function. You can either CTRL+D or enter a call to System/exit. This is not a big deal, but I like the idea of exiting with a simple (exit) call (as one does with Ruby and Python). Fortunately, we can add this function to the startup file. Furthermore, for learning purposes, few things beat having the source function which reveals the source code of built-in Clojure functions. This too can be added to ~/.clojure.clj:

(use 'clojure.contrib.repl-utils)
(defn exit [] (System/exit 0))

(exit) will now exit the REPL and source will reveal the source code as shown below:

user=> (source peek)
(defn peek
  "For a list or queue, same as first, for a vector, same as, but much
  more efficient than, last. If the collection is empty, returns nil."
  [coll] (. clojure.lang.RT (peek coll)))
nil

Step 5: Create a ~/.clj_completions file

As explained in the Clojure Wikibook referenced above, you can create the .clj_completions file by running the following from the REPL or as a script (e.g., clj myscript.clj):

(def completions
    (reduce concat (map (fn [p] (keys (ns-publics (find-ns p))))
                        '(clojure.core clojure.set clojure.xml clojure.zip))))

(with-open [f (java.io.BufferedWriter. (java.io.FileWriter. (str (System/getenv "HOME") "/.clj_completions")))]
    (.write f (apply str (interleave completions (repeat "\n")))))

This will populate the file .clj_completions with a list of 500+ symbols. You can now run clj and try tab completion by inserting a few characters and then pressing tab. For example:

mbp:~ acangiano$ clj
Clojure 1.1.0
user=> (re<tab>
re-find                ref-min-history        repeatedly
re-groups              ref-set                replace
re-matcher             refer                  replicate
re-matches             refer-clojure          require
re-pattern             release-pending-sends  reset!
re-seq                 rem                    reset-meta!
read                   remove                 resolve
read-line              remove-method          rest
read-string            remove-ns              resultset-seq
reduce                 remove-watch           reverse
ref                    rename                 reversible?
ref-history-count      rename-keys
ref-max-history        repeat

There you have it, a complete setup of Clojure from source to clj. You can find information about setting up your favorite editor/IDE on the Assembla Wiki.

Note: As pointed out by Phil and other commenters elsewhere, the easiest way to get started these days is probably to install cljr, a standalone REPL and package manager. My post outlines how to do it from scratch (as you can deduct from the title), just like we used to before these tools were released. You may however consider the pre-packaged solution instead.

Thoughts on Clojure

2010-07-09T20:28:02Z

Lisp has had a tremendous impact on the world of programming. Even though Common Lisp and Scheme — the two main Lisp dialects — may not be considered mainstream today, several popular languages have been influenced by one or both of them.

It isn’t stretching things too much to say that both Ruby and Python can be seen as slower, easier (for beginners), object-oriented, infix Lisp dialects.

Some may say Ruby is a bad rip-off of Lisp or Smalltalk, and I admit that. But it is nicer to ordinary people. — Yukihiro “Matz” Matsumoto

Ruby and Python aren’t intimidating and remain very approachable for absolute beginners. Furthermore, their approachability is not confined to the language design itself, but transcends into the community and ecosystem that surrounds them.

I’m not here to discuss how languages like Ruby and Python managed to become more popular than major Lisp dialects nowadays. I’d rather focus on how these gentler introductions to functional programming are acting as gateway drugs to Lisp for many developers.

A community that values metaprogramming and is obsessed with the construction of DSLs (Domain Specific Languages) like the Ruby’s is, will no doubt find in Lisp a valuable ally. Plus, if you know Ruby inside and out, you should find Lisp to be easy enough to learn.

To attract Ruby developers though, Lisp has to offer something more than just a set of powerful features. You could say that Rails is enough of a reason to learn and use Ruby. But what is Lisp able to solve all that better than Ruby? I’ll answer that question by focusing on a specific dialect of Lisp, that I and continually more Ruby developers are getting into: Clojure.

It wouldn’t be fair to characterize the Lisp community as stagnant, but Clojure is definitely a welcomed dose of new blood. Clojure is a JVM-based modern Lisp designed for concurrency, which elegantly includes a set of carefully chosen features that are not easily found in mainstream languages.

In my opinion, Clojure has three main advantages over Ruby:

It’s much faster than Ruby, which makes it a better choice for intensive processing. (FlightCaster for example, uses both Rails and Clojure. Rails for the “front-end” and Clojure for the heavy lifting/forecasting.)
It greatly simplifies concurrent programming, making the language more future-proof as hardware manufacturers continue to produce processors with more CPU cores.
Clojure emphasizes functional programming and tries to minimize side effects.

Clojure’s interoperability with Java resolves the issue of only having a few available libraries, which often affects new languages. It also helps in getting people to use the language within the enterprise world where Java still dominates.

Of all the “new” languages out there, I find Clojure to be the most fun, interesting and pragmatic: it’s something worth getting excited about. I don’t really care if it turns out to be the next Ruby or not, it’s a language that’s worth knowing and using. (If you haven’t tried it yet, a decent, short introductory book is the recently published Practical Clojure.)

Clojure’s popularity may even bring more attention to Lisp in general (for example, most must-read literature uses Scheme or Common Lisp). Perhaps then, it may indirectly help introduce more traditional Lisp dialects to a new generation of programmers.

The pursuit of excellence in programming

2010-07-15T00:12:05Z

As I write a series of thoughts on the pursuit of excellence in programming, I must preface my essay by asking you to ignore that I wrote these words. I invite you to evaluate the opinions and ideas presented here not ad hominem, but rather on the basis of their own merits. It would be easy to otherwise mistakenly dismiss them with the infamous question posed by Steve Jobs to a blogger: “What have you done that’s so great?”.

This is to say that I talk about the ambitious and noble goal of achieving excellence in programming, fully conscious of not having achieved said excellence. For the time being, I don’t feel like I can point my finger at something that would impress Steve Jobs (or less critical observers). I’m just a traveler on the journey of learning, with a desire to share his experiences and plans.

Two visions of intelligence

Mastering a complex discipline such as programming requires a great amount of learning over the course of several years, perhaps even decades. Maximizing one’s ability to learn is therefore an early investment that can quickly repay itself.

The biggest impact on my ability to learn was caused by a shift in the way I considered the matter of intelligence. There are mainly two ways to think about it. You can either consider intelligence to be a static, intrinsic ability or a more dynamic, cultivable characteristic of human beings.

Cognitive scientists and psychologists conclusively determined that people who perceived intelligence as a dynamic characteristic, outperformed and were more successful than people who internalized intelligence as an intrinsic, static ability.

It’s worth noting that it’s not really important whether intelligence can actually be developed through application. It’s the perception of it that forges students’ approach to learning.

This difference in perception is often conditioned by early parenting. Kids who are encouraged to work hard to achieve results and are praised on the basis of their effort, tend to develop a perception of intelligence and results as something they can work on. Other kids are conditioned to think that they are doing well because they are “smart” and that their intelligence alone will most likely lead them to success.

Society has a fascination with genius, and parents like to fancy their little ones to be several standard deviations better than the norm, but conditioning children this way has dangerous and counterproductive consequences.

Kids who are labeled and praised because of their “innate capabilities”, will often suffer from an overconfidence that will affect their ability to challenge themselves through the depths of the unknown, because they feel it would threaten their status. What if they fail? It would mean, in their eyes, that perhaps they are not the smart person they have been assumed to be all along. We all have seen such kids failing here and there, and quickly making excuses such as, “Oh, I wasn’t trying at all”.

A parent who is cultivating a kid’s interest in hard work, may be more likely to encourage their child with words such as, “It’s OK. Keep studying, and you’ll definitely do better next time”. A parent proposing a model of static intelligence, may justify their child’s failure in a given subject by concluding that “maybe you are not cut out for subject X”. [1]

When facing failure, the “static intelligence” child may crumble under the weight of his own demise, as if failure was a reflection of their intrinsic value rather than a temporary speed bump and occasion for growth. A “dynamic intelligence” child will simply try harder next time. Genius or not, excellence and mastery of any subject requires hard work and many “smart” kids fall short when the bar is raised high enough so that “smartness” alone won’t cut it anymore. This usually corresponds with the switch from high school to college.

I’m very familiar with all of this, because I was one of those kids. I was labeled by my parents and science teachers as a “genius”. Even psychologists at school, who came to help us figure out what careers we were better suited for, ended up telling me that I could pursue virtually any career (at the time I was interested in nuclear physics) and that according to their (virtually meaningless) IQ tests I would be classified as a “genius”.

Please note that the problem wasn’t so much the label. Most smart kids figure out that they are smart on their own rather quickly. The real problem was that I wasn’t taught the value of long-term intellectual effort. Effort itself was considered as being somewhat detrimental to my status. Not only was I supposed to succeed, but I supposedly had to do so without putting forth any effort (a “utopic” ambition).

One of the first example of this that I can remember is when my father “caught me studying” for a few hours the same book before a test in middle school. He told me something along the lines of “Why do you need to study? A genius like you should figure out the test without studying.”. It’s absurd, I know, and probably one of the dumbest things my — otherwise bright — father has ever told me. As a young kid though, such a statement can have a strong impact on you.

Another example has to do with Latin. My teacher was a palm reading, crazy cat lady and I had no respect for her from the start. So I didn’t pay attention in class, on top of not studying Latin at home, I set myself up for failure. When the first translation assignment came around, I got a mildly negative score. My less than professional teacher told me, “Oh I thought you were good, but I guess you are not”. Afterwards my father added to this by saying something along the lines of, “Well, don’t worry, I guess languages are not your strength.”.

Boom. That was enough for me to stop having any interest in Latin and completely ignore a subject at which I wasn’t excelling. Nobody could tell me, “You are stupid because you don’t understand Latin,” if I didn’t try at all. So I was the high school kid who did advanced Calculus stuff on his own for fun, when my classmates where struggling with Algebra, yet I pretty much sucked at Latin. (In retrospective, the thought patterns required to excel at Latin where not very different from those required to excel at math or mastering English as a second language. I suspect that had I put in some effort I could have been very good at, and actually enjoyed, the subject.)

Over the years I had to readjust this perception entirely. By falling on my face more than once, I learned that excellence is only achieved through a combination of talent and effort. The real genius may lie in the ability to put in thousands of hours of focused study and practice, in the pursuit of whatever one person is trying to learn and understand.

If people knew how hard I worked to get my mastery, it wouldn’t seem so wonderful at all. — Michelangelo

By this new definition, I was a complete idiot who had to entirely learn from scratch how to appreciate the value of effort to hone and develop his “talent” (which is nothing but a seed on its own).

Learning to learn

Being very interested in programming, computer science, mathematics, and science in general, I decided at some point that I had to entirely change my attitude towards learning if I were to master any of those disciplines. Effort was now more important than intelligence on its own, and I would feel satisfied only when doing a really good job in the pursuit of something challenging, that couldn’t be achieved by sheer “talent”.

The saddest thing in life is wasted talent, and the choices that you make will shape your life forever. — Calogero ‘C’ Anello from A Bronx Tale

In the process, I started to internalize a few principles and I dealt with issues related to both the art of learning and the art of programming.

An awful feeling

There is a cognitive bias known as the Dunning-Kruger effect [2], in which subjects who are inexperienced or less competent within a given discipline, tend to overestimate their abilities (they are in other words affected by illusory superiority [3]).

The other side of this coin is that the more you study, the more you realize how little you know and how much there is to know (a concept put forward by Socrates back in the days of Ancient Greece). This is both a pleasure and a discomfort. There is a huge amount of satisfaction in finding things out. Yet, being in doubt and fully aware of how little you know tends to be an unpleasant side effect all learners have to live with. Doubt truly is the water that’s fundamental for the growth of the flower of intellectual curiosity. [4]

My approach in this case is to embrace and dominate my ignorance and fears. Whenever there is a concept that I feel particularly ignorant about or that is way over my head, I try to tackle it as if my life depended on it. There are still countless things I’m ignorant about, but this approach as really paid off for me over the years.

If you are trying to learn a whole branch of computer science or mathematics, it will take a long time, so you may want to start first with smaller “fears” that can be mastered, at least at an introductory level, in a short amount of time. Rather than thinking, “Oh yeah, I should really learn Git”, for months, act on the thought. The essential knowledge to work with Git or Hg doesn’t take months to learn (assuming you have a need for either of these particular tools).

But you are in this for the long run, so don’t be afraid of improving your craft by studying advanced topics that require a bigger commitment in terms of time as well. There is no royal shortcut, mastery of our craft will require thousands of hours of dedicated study and practice.

Theory and practice

Masters of any intellectual discipline tend to have good working knowledge of both theoretical and practical aspects. Pursuing excellence in programming requires the study of many insightful books that will widen your view of the field and as a result necessarily improve your craft.

Working with books alone is not enough though. Programming requires writing and reading programs every day for years. That’s why I have a rule: I refuse to go to sleep if I haven’t read and written some code on a given day (this doesn’t include the code I write for work, of course). So far, this rule has had a positive impact on my ability to code.

It is a mistake to think that the practice of my art has become easy to me. I assure you, dear friend, no one has given so much care to the study of composition as I. There is scarcely a famous master in music whose works I have not frequently and diligently studied. — Mozart

Breadth Vs. Depth

As we progress in our journey towards the pursuit of excellence in programming, a question that will no doubt pester people’s minds is whether one should go for breadth of knowledge, or depth. There are countless programming languages, paradigms, methodologies, technologies, et cetera.

The truth of the matter is that if we are to become GrandMaster programmers, we cannot ignore either of them. In practice, depth has a much stronger impact in the way we construct software. It is through deep understanding that we can see the whole through the parts. There is therefore value in specializing in just a few languages and technologies, and really mastering them in-depth.

Getting things done in software development requires a certain pragmatism and proficiency with the tools at hand. There is no escaping it. Depth is therefore necessary, but not sufficient.

I find that the web is particularly good at covering the breadth aspect of things. There are always new and interesting areas I can learn about and experiment with. I don’t need a whole 600 page book to get a feeling for — or to better understand — certain technologies that are not crucial to my area of specialization.

While there are quite a few exceptions I could mention, I’d say that I tend to use the Internet as an aid for horizontal scaling of my knowledge, and books for vertical scaling. And again, more often than not, the depth level is mostly determined by the amount of time, practice and effort I put into it, rather than the media I’m using.

Where to find time

One of the objections I hear often, particularly when it comes to reading books is, “I don’t have time!”. In a few extreme cases, that may actually be true, but I think that most people severely underestimate how much time is “wasted” on a daily basis (even just surfing online).

Breaks are extremely important, and I’m not advocating any regime of incessant study. I simply know how crucial it is to be constant. It’s a marathon, not a sprint.

My second rule is: I refuse to got sleep if I haven’t read at least a chapter of a book that day. Very often I get caught up in the book I’m reading or working through, and end up getting through much more than just one chapter (it really depends on the book, of course). But for me the rule is clear: no sleep allowed until one chapter has been read every day.

Try this approach and you’ll see that reading doesn’t have to take up much time, yet doing so you can still read several books (including technical ones) every month.

We are what we repeatedly do. Excellence, then, is not an act but a habit. — Aristotle

For certain books, it is convenient to have the book in PDF format on your computer, as you switch from the book to the editor/console and back. However, generally speaking the computer tends to be quite distracting and thoughts like “I’ll just check my email quickly” can easily lead to hours spent doing something else.

For this reason I prefer to read from a paper book which is also easier on the eyes for extensive reading after a day in front of a computer screen. Even if I’m using the computer at the same time to input code, the physical presence of a book next to my laptop is enough to remind me that I shouldn’t get distracted online. (For me the depth and focus required by books is also an antidote to the re-wiring that the web tends to do to our brains. [5])

By the way, a few days ago Amazon announced a gorgeous, brand new graphite color Kindle DX [6]. I think I may pull the trigger and get it for my upcoming 30th birthday. Buying numerous paper books is expensive, and given the price of Kindle books, this move would end up being cheaper in the long run. The large e-ink display almost looks like paper and the device is not as distracting as an iPad (you read on a Kindle, and that’s it). Plus, it’s lighter than most technical books and surely takes up less space in your home.

Achieving focus

With so much going on within the programming world, distractions are easy to come by. My approach is to focus only on the given macro-task at hand. If I’m trying to learn about process calculi for example, then for the next few months my “learning time” will be ruthlessly dedicated to that subject, as if the rest of the programming ecosystem stopped in time.

Then there is focusing at a micro-task level. Learning about a given subject can always be divided into a long series of smaller steps. When I’m focusing on one such, tiny step, then everything else ceases to exist (or at least in theory).

One trick I use to achieve solemn focus on micro-tasks, whether reading code, writing code, or reading a technical book, is the use of the Pomodoro Technique [7]. In short, I use timer software [8] which alerts me when 25 minutes (a pomodoro) have passed, and gives me a 5 minute break for each pomodoro. Every 4 pomodoros, I can take a longer break.

When I first started using this technique I thought it was mostly a gimmick and I had a hard time taking breaks. I just wanted to keep going and the “tracking” seemed silly. However, I must say that it strikes an elegant balance between the desire to focus for extensive periods of time and the importance of taking regular mini-breaks.

This approach has become routine for my mind now, so even if it is just a gimmick, it’s still a good way for me to get focused and “in the zone”.

Aiming for sprezzatura

The pursuit of excellence requires a huge drive from within, and a fundamental dissatisfaction with just being good at a given discipline. I believe this is true regardless of the profession at hand.

As I progress in my journey, I’m discovering how the key is to make the pursuit of excellence a habit. This goes against my nature of being an intellect sprinter, but I’m in for the long run and I’m really learning to enjoy the, marathon like, process.

My long-term goal is to program with sprezzatura [9], where the process is so internalized and part of my subconscious that it almost looks effortless (as if the act of programming was committed to muscle memory). It will be an overnight success, 15 years in the making.

Regardless of the improvement level achieved, I will always have the joy, privilege and need to continue to learn for the betterment of myself and my craft. When there is no set destination, the journey is what really matters.

Ancora imparo. (I’m still learning.) — Michelangelo

Notes

[1] These concepts are explained, in a much more eloquent manner, in the early chapters of the excellent book, The Art of Learning by Josh Waitzkin.

[2] Dunning-Kruger Effect on Wikipedia.

[3] Illusory Superiority on Wikipedia.

[4] For more on the importance of doubt in science, check out the beautiful epilogue in What do you care what other people think? by Richard P. Feynman.

[5] For more on this phenomenon, read The Shallows by Nicholas Carr.

[6] The new Kindle DX on Amazon.

[7] The Pomodoro Technique.

[8] Pomodoro for Mac OS X.

[9] Sprezzatura on Wikipedia.

Translations

Carlos Marcelo Cabrera translated this article into Spanish: La búsqueda de la excelencia en la programación.

The Great Ruby Shootout (Windows Edition)

2010-07-04T07:19:35Z

This post contains the results of a Ruby shootout on Windows that I recently conducted. You can find the Mac edition, published last month, here. I was planning to have this one ready much sooner, but a couple of serious events in personal life prevented that from happening. Be sure to grab my feed or join the newsletter to avoid missing the upcoming Linux shootout.

The setup

For this shootout I included a subset of the Ruby Benchmark Suite. I opted to primarily exclude tests that were executed in fractions of a second in most VMs, focusing instead of more substantial benchmarks (several of which come from the Computer Language Benchmarks Game). The best times out of five runs are reported here for each benchmark.

All tests were run on Windows 7 x64, on an Intel Core 2 Quad Q6600 2.40 GHz, 8 GB DDR2 RAM, with two 500 GB 7200 rpm disks.

The implementations tested were:

Ruby 1.8.7 (2010-01-10 patchlevel 249) [i386-mingw32] (RubyInstaller)
Ruby 1.9.1 p378 (2010-01-10 revision 26273) [i386-mingw32] (RubyInstaller)
Ruby 1.9.2 dev (2010-05-31) [i386-mingw32] (experimental)
JRuby 1.5.1 (ruby 1.8.7 patchlevel 249) (2010-06-06 f3a3480) (Java HotSpot(TM) 64-Bit Server VM 1.6.0_20) [amd64-java]
IronRuby 1.0 x64 for .NET 4.0

JRuby was run with the --fast and --server optimization flags.

Disclaimer

Synthetic benchmarks cannot predict how fast your programs will be when dealing with a particular implementation. They provide an (entertaining) educated guess, but you shouldn’t draw overly definitive conclusions from them. The values reported here should be assumed to be characteristic of server-side – and long running – processes and should be taken with a grain of salt.

The results

Please find below the execution times for the selected tests. Timeouts indicate that the execution of a single iteration for a given test took more than 60 seconds and had to be interrupted. Bold values indicate the best performance for each test.

Conclusions

Despite a couple of errors and a few timeouts, JRuby was the fastest of the lot, which can be seen as impressive ~~if we consider that this is Windows we are talking about after all~~.

Ruby 1.9.1 and 1.9.2 were almost as fast as JRuby on these tests. With a few exceptions, the performances of the two 1.9 implementations were, expectedly, very similar.

JRuby, 1.9.1 and 1.9.2 were all faster than the current MRI implementation, which can be seen as a prerequisite as we move, as a community, away from Ruby 1.8. Finally, it’s worth noting that IronRuby’s performance was however in line with that of Ruby 1.8.7.

Update (July 3, 2010): The following box plot compares the various implementations for the tests for which all the implementations were successful. Only times for the largest successful input number were used in those tests where multiple input numbers were tested.

How Microsoft is changing the programming world

2010-06-24T01:35:38Z

Several years ago I knew a programmer, we’ll call him Joe, who fancied himself to be a great developer. He was a senior developer at “Big Co.”, who received a large enough pay check to just as easily compensate a few junior developers.

The guy had Microsoft certifications, as expected of one in his position, and he appeared to know Visual Studio inside and out, just as you’d imagine.

What was surprising for me at the time, was that as I got to know Joe better, I slowly started to realize that the guy was absolutely clueless about programming beyond the scope of the Microsoft bubble.

He had never used Linux in his life, nor was he interested in learning about it. He wasn’t aware of tools like CVS or SVN. He didn’t seem familiar with the ideas behind unit testing or Agile methodologies; words like “refactoring” were outside of Joe’s vocabulary.

How about other programming languages or paradigms, like functional programming? Nope, nothing there either. He knew Visual Basic 6 and VB.NET, C# (the first release at the time) and a bit of C++. That’s it. And he was proud of it. As I enquired further in an attempt to figure out what he was all about, he didn’t mind admitting to a complete ignorance of what wasn’t printed on Microsoft paper.

What’s interesting is that, despite his cluelessness – due to a strict adherence to the Microsoft view of the programming world – and perhaps a lack of intellectual curiosity, the guy did manage to be somewhat adequate at his job. Not spectacular by any stretch of the imagination, but good enough to keep his well paid job.

Joe simply didn’t care about tools and techniques that fell outside of the narrow, yet mainstream, beaten Microsoft path.

Over the years I’ve met countless Joes. In fact, if I were to generalize and characterize many Microsoft developers in the early 2000s, Joe would come to mind like an unpleasant stereotype.

I tell this story not to criticize Joe or to claim that Microsoft developers suck. On the contrary, my argument is that Microsoft will be a key factor in terms of enabling functional programming to become mainstream. In fact, what Microsoft is doing is introducing .NET developers to functional programming, one piece at a time.

Just a few days ago I was reading the blog of a guy who seemed happy to discover a cool “new” function called Zip in LINQ (hey Haskell programmer over there, stop laughing, you are disrupting my article). These days following blogs by Microsofties is in fact like witnessing some sort of Renaissance, with plenty of talk about exciting features that are clearly borrowed from the functional programming community.

The evolution of C# and Visual Basic, LINQ, and more recently the inclusion of F# as a fully supported language within the .NET Framework 4.0, all indicate Microsoft’s new outlook towards functional programming. F# in particular is essentially OCaml for .NET, and has been received with open arms by the Microsoft community (as far as I can tell).

There are very few books by mainstream publishers on OCaml. On the other hand, F# already has a rich ecosystem of printed books that have been published by O’Reilly, Apress, Wrox, Manning, and likely in the near future Microsoft itself. On top of that there are titles devoted to LINQ and countless books on the recent, more functional oriented, C# and VB.

I’m not measuring the popularity of programming languages by the availability of books alone, but it’s clear to me that there are millions of Joes out there who are ready to learn these new concepts that are now being put out and promoted by Microsoft. It doesn’t matter that they’re not new or that they’re borrowed from other programming languages like Ruby, Python, LISP, ML, Haskell, etcetera.

The end result of Microsoft’s new approach is that now Joes everywhere are getting exposed to functional programming (masses of people who would otherwise be virtually shielded from the rest of the programming world).

Microsoft may no longer be the influential powerhouse it once was, but I think it is fair to acknowledge the impact it’s currently having on making functional programming, or at least some degree of it, more mainstream.

Update: Initially I used the name “Dick” (short for Richard) to identify the programmer I talked about in this story. It was meant to be a humorous double entendre, but turned out to somewhat distract certain readers from the key points that this article was actually about. As well it seems that some people felt I was coming across as being strongly against Microsoft developers (which I’m not in the least). As a result, some readers ended up being offended by this post, which was never my intention. I don’t love political correctness, but I feel that replacing the name “Dick” with “Joe” instead ends up detracting less from the heart of the article.

Ten recent programming books that will make you a better developer

2010-06-21T12:23:03Z

Programming is the type of discipline that requires countless hours of dedication to reading and writing code, rather than purely theoretical learning from books. Yet programming books can be enlightening and provide guidance while one attempts to hone their craft in the pursuit of mastery.

In this post I’ll share a (necessarily incomplete) list of relatively new books that I believe will make most developers better programmers. By “new”, I mean books that have been released recently (within the past three years), that haven’t become classics yet or appeared in everyone else’s list of recommended programming books. Hence, you won’t find SICP, TAoCP, PFDS, etc.

Please note that each of them deserves (and probably will receive at some time) a lengthy review. Here I simply state in a brief manner why I think they are important.

1. Introduction to Algorithms, Third Edition

OK, this is cheating a little. “Introduction to Algorithms” is both a classic and a book on everyone’s list. However, I opted to include it because not everyone knows that it was recently (September 2009) released in its third edition. The book received a major upgrade to the existing content and exercises, as well as including new, modern algorithms. Any programmer working through this book, or revisiting it, will learn valuable, foundational knowledge.

2. The Annotated Turing

Alan Turing wrote a classic paper in 1936 with the title: “On Computable Numbers, with an Application to the Entscheidungsproblem“. It was a paper on Turing machines and the limits of computability, which had a major impact on computer science and the development of the computer you are reading this post on. Every programmer/computer scientist should get ahold of this paper and read it. Unfortunately, it isn’t exactly easy to grasp if you are not used to reading research papers. In “The Annotated Turing”, Petzold does a marvelous job of dissecting the paper (and its errata), providing ample explanations and background information over 18 chapters (360 pages vs 36 of the original paper). It manages to be rigorous while still being accessible. If this book doesn’t arouse your interest in computer science, chances are nothing will.

3. Growing Object-Oriented Software, Guided by Tests

This book takes two fundamental pillars of modern software development, Object-Oriented Design and Test-Driven Development, and clearly illustrates how to apply the best practices of each to build and maintain complex software. I don’t know of many developers who couldn’t learn something new about TDD in the context of OOP from this book. A must read.

4. Clean Code

While on the subject of Agile development, I can’t help but recommend “Clean Code” by Uncle Bob. It compliments “Growing Object-Oriented Software, Guided by Tests” perfectly by focusing on how to improve and refractor code to get rid of code smells. You can think of it as a very succinct version of Code Complete 2, with a strong focus on Agile craftsmanship. The examples, as per the previous book, are in Java but that shouldn’t be much of an issue for the open-minded developer.

5. Leading Lean Software Development: Results Are not the Point

Lean principles deriving from the Lean manufacturing world have been effectively translated and adapted to the field of software development. This book explains how to lead a team to success through lean software development in detail to team leaders and mentors. Having obtained a Lean Six Sigma yellow belt many years ago, this book definitely gave me a few flashbacks. If you are not familiar with the concepts presented, you’ll definitely find it food for thought. Building software requires far more than just writing quality code, and the techniques presented here are valuable, even if you don’t fully buy into this methodology.

6. Growing Software

While on the subject of leadership, if you are in charge of software development at a small company or startup, you want to read this book. My interest in this title came from the fact that its author (Louis Testa) works as a Senior Engineering Manager at Galois, a company that uses Haskell as their technological advantage (and hired Don Stewart of Haskell fame). “Growing Software” delivered on my expectations and is full of hands-on advice on how to deal with the whole workflow surrounding the creation of software from the idea all the way to the sale and support of a product.

7. The Art of Debugging with GDB, DDD, and Eclipse

Debugging is an invaluable skill and one that is often left out from introductory programming books. Being able to effectively debug code is what separate professionals from beginners, and productive programmers from frustrated ones. This book is ruthlessly practical with many advanced techniques for debugging on Linux/Unix. It’s well worth its price in my opinion.

8. Applied Mathematics for Database Professionals

Assuming you already have a decent understanding of relational databases, and are not too scared of mathematics, this book will really bring your knowledge of how databases work to the next level, in turn improving the design, schema evolution, and SQL queries you’ll create afterwards.

9. Programming Collective Intelligence

If you are building web applications that do more than simply CRUD operations on your data, you’ll want to read this book (with examples in Python). The motivated, intermediate developer will learn how to efficiently solve complex problems related to machine learning and intelligent web algorithms from this book. It’s a very accessible introduction to tough subjects and one of the most interesting books I’ve read in some time.

10. Coders at work

To conclude this list, I wanted to include a book that’s aimed at showing programmers how some of the best programmers and computer scientists do their work. I previously enjoyed Founders at Work, and this version about programming is just as good. It’s inspiring, fun to read, and rich in insight and advice.

A new domain name for Zen and the Art of Programming

2010-06-20T10:42:12Z

For years Zen and the Art of Programming has been hosted on my domain antoniocangiano.com. However, I’ve decided to switch it over to a new one, programmingzen.com. This move was done for two main reasons: first, it is sometimes hard for native English speakers to communicate and remember my name. Second, my blog isn’t so much about me and my life, as it is about the world of programming.

As I look towards the steps that are required to bring my blog to the next level, I decided it was time to make the switch to a new domain. I’d like to transform Zen and the Art of Programming into a blog that every programmer could potentially be interested in subscribing to, not just people who are into Ruby or following me.

The good news for you is that you don’t need to do a thing. Every internal link has been permanently redirected to a corresponding programmingzen.com link, with the exception of the homepage. I’m now using antoniocangiano.com as a sort of minimalist virtual business card, from which I link to my email, Twitter, Linkedin, my three blogs (this, my personal blog, and my math blog), as well as my book and ThinkCode.TV.

Stay tuned for lots of interesting new content, which I plan to post more frequently. Meanwhile please feel free to let me know what you think about this new change; I’d really welcome your thoughts.

Would you use a Mac mini as your development machine?

2010-06-17T11:29:15Z

Apple just released a brand new, gorgeous looking Mac mini. This major upgrade brings us two different models: a desktop one and a server version (priced at $699 and $999, respectively).

Equipped with a HDMI port, the desktop edition of the Mac mini makes for a perfect Home Theater PC. It’s small and stylish, and as such is a great fit in your living room. Most of the reviews I’ve read focus on its use as a highly capable HTPC (despite its lack of a Blu-Ray drive).

However, I see the new Mac Mini in a different light. At $700 it is far too expensive for a HTPC, yet it’s ideal as an entry-level machine for web, Mac, and iOS development (it’s almost as cheap as a Hackintosh, minus the headache).

Mac Minis will do the job and be more than capable thanks to their adequate, albeit not spectacular, hardware specs. If my MacBook Pro were to die today, I would definitely consider purchasing one for development purposes. Would you?