Anatomy of a One-Liner: FizzBuzz in Haskell

In the NashFP group, a gang of functionally inclined Nashville area geeks recently organized by Bryan Hunter, we decided to share implementations of the classic FizzBuzz problem in various functional languages. I took my first shot in Scheme and then decided it was time to dust off my Haskell. On my first attempt I waded through the syntax enough to get something working, but it included several named functions and was clearly more code than was necessary to solve the problem. As I began to look for ways to shorten it, I remembered that a year or two ago Bryan had written a FizzBuzz implementation in Erlang that was short enough to tweet. Obviously this became my new goal.

I managed to whittle it down below 140 characters, but its readability suffered quite a bit. I thought it might be fun to dissect here bit by bit, and it might even come out shorter and more readable. I keep learning new tricks in Haskell and in the general functional approach that offer new opportunities to make my code shorter and more streamlined. You might learn some of these here, or if you have any pointers to offer me in comments, I would love to learn some from you as well.

In case you're not familiar with FizzBuzz, it is a programming exercise in which goal is to list integers from 1 to 100, replacing those divisible by 3 with the term "Fizz," those divisible by 5 with the term "Buzz," and those divisible by both 3 and 5 with the term "FizzBuzz."

For this exercise I will be using my favorite IDE, the REPL, in this case GHCI, the Glasgow Haskell Compiler Interactive.

Let's start with the input range. We ultimately want to go from 1 to 100, but let's start with 1 to 15 just for brevity of output while we evolve this thing.

Prelude> [1..15]
[1,2,3,4,5,6,7,8,9,10,11,12,13,14,15]

To apply a function to each member of this list, we could use the map function or a list comprehension, which should be shorter, so let's try that. We'll start with a simple identity comprehension, which will do nothing for us. This step is just about making ourselves a place to do some work.

Prelude> [x | x <- [1..15]]
[1,2,3,4,5,6,7,8,9,10,11,12,13,14,15]

Let's try the Fizz substitution for multiples of 3. Note that the else case needs the show function to convert the integer to a string since Haskell lists must be homogenous.

Prelude> [if mod x 3 == 0 then "Fizz" else show x | x <- [1..15]]
["1","2","Fizz","4","5","Fizz","7","8","Fizz","10","11","Fizz","13","14","Fizz"]

Now for the Buzz case for multiples of 5:

Prelude> [if mod x 3 == 0 then "Fizz" else if mod x 5 == 0 then "Buzz" else show x | x <- [1..15]]
["1","2","Fizz","4","Buzz","Fizz","7","8","Fizz","Buzz","11","Fizz","13","14","Fizz"]

This works up through 14, but I hate to add another case, and it's already getting too long due to repetitive code. Under normal circumstances I might look to extract a method here, but we're working on a one-liner, so let's try another way. The factor mappings must be stated, and the most concise way I know is as a list of tuples.

Prelude> [(3,"Fizz"),(5,"Buzz")]
[(3,"Fizz"),(5,"Buzz")]

Now we need a way to iterate through this list, run the divisibility test, and make the appropriate substitutions. First off we need to give the mapping list a chance to dance with each element in the list of integers. We can do this by tucking it into a tuple with the integer inside the comprehension.

Prelude> [(x,[(3,"Fizz"),(5,"Buzz")]) | x <- [1..15]]
[(1,[(3,"Fizz"),(5,"Buzz")]),(2,[(3,"Fizz"),(5,"Buzz")]),(3,[(3,"Fizz"),(5,"Buzz")]),(4,[(3,"Fizz"),(5,"Buzz")]),(5,[(3,"Fizz"),(5,"Buzz")]),(6,[(3,"Fizz"),(5,"Buzz")]),(7,[(3,"Fizz"),(5,"Buzz")]),(8,[(3,"Fizz"),(5,"Buzz")]),(9,[(3,"Fizz"),(5,"Buzz")]),(10,[(3,"Fizz"),(5,"Buzz")]),(11,[(3,"Fizz"),(5,"Buzz")]),(12,[(3,"Fizz"),(5,"Buzz")]),(13,[(3,"Fizz"),(5,"Buzz")]),(14,[(3,"Fizz"),(5,"Buzz")]),(15,[(3,"Fizz"),(5,"Buzz")])]

The resulting list can now be used as the input for another list comprehension, where we can take another shot at applying our divisibility tests. Once again we will start with an identity comprehension just to get our terms in place before we put them to work. Since each element of the list is a 2-tuple, we can go ahead and give each member a variable, f for factor and n for name.

Prelude> [(x,[(f,n) | (f,n) <- [(3,"Fizz"),(5,"Buzz")]]) | x <- [1..15]]
[(1,[(3,"Fizz"),(5,"Buzz")]),(2,[(3,"Fizz"),(5,"Buzz")]),(3,[(3,"Fizz"),(5,"Buzz")]),(4,[(3,"Fizz"),(5,"Buzz")]),(5,[(3,"Fizz"),(5,"Buzz")]),(6,[(3,"Fizz"),(5,"Buzz")]),(7,[(3,"Fizz"),(5,"Buzz")]),(8,[(3,"Fizz"),(5,"Buzz")]),(9,[(3,"Fizz"),(5,"Buzz")]),(10,[(3,"Fizz"),(5,"Buzz")]),(11,[(3,"Fizz"),(5,"Buzz")]),(12,[(3,"Fizz"),(5,"Buzz")]),(13,[(3,"Fizz"),(5,"Buzz")]),(14,[(3,"Fizz"),(5,"Buzz")]),(15,[(3,"Fizz"),(5,"Buzz")])]

Now we can add a filter to the new comprehension to get only the pairs whose factor evenly divides the integer.

Prelude> [(x,[(f,n) | (f,n) <- [(3,"Fizz"),(5,"Buzz")],mod x f == 0]) | x <- [1..15]]
[(1,[]),(2,[]),(3,[(3,"Fizz")]),(4,[]),(5,[(5,"Buzz")]),(6,[(3,"Fizz")]),(7,[]),(8,[]),(9,[(3,"Fizz")]),(10,[(5,"Buzz")]),(11,[]),(12,[(3,"Fizz")]),(13,[]),(14,[]),(15,[(3,"Fizz"),(5,"Buzz")])]

That's closer, but that comprehension is still returning the factor-name pair, and we're only interested in the name, so let's make that adjustment.

Prelude> [(x,[n | (f,n) <- [(3,"Fizz"),(5,"Buzz")],mod x f == 0]) | x <- [1..15]]
[(1,[]),(2,[]),(3,["Fizz"]),(4,[]),(5,["Buzz"]),(6,["Fizz"]),(7,[]),(8,[]),(9,["Fizz"]),(10,["Buzz"]),(11,[]),(12,["Fizz"]),(13,[]),(14,[]),(15,["Fizz","Buzz"])]

This is starting to bear some resemblance to the result we're after, but notice that our Fizzes and Buzzes are still coming out in lists. We might grab the head of the list, but the FizzBuzzes have two elements, and we don't want to drop one. We need to concatenate them, which we can do with the concat function.

Prelude> [(x,concat [n | (f,n) <- [(3,"Fizz"),(5,"Buzz")],mod x f == 0]) | x <- [1..15]]
[(1,""),(2,""),(3,"Fizz"),(4,""),(5,"Buzz"),(6,"Fizz"),(7,""),(8,""),(9,"Fizz"),(10,"Buzz"),(11,""),(12,"Fizz"),(13,""),(14,""),(15,"FizzBuzz")]

Now we have a list of tuples, each containing one value that we want and another that we don't. First we'll add a show to the x to make them the same type so we can compare them.

Prelude> [(show x,concat [n | (f,n) <- [(3,"Fizz"),(5,"Buzz")],mod x f == 0]) | x <- [1..15]]
[("1",""),("2",""),("3","Fizz"),("4",""),("5","Buzz"),("6","Fizz"),("7",""),("8",""),("9","Fizz"),("10","Buzz"),("11",""),("12","Fizz"),("13",""),("14",""),("15","FizzBuzz")]

Now that the elements in the tuples are the same type, we can use the max function to make the choice between them.

Prelude> [max (show x) (concat [n | (f,n) <- [(3,"Fizz"),(5,"Buzz")],mod x f == 0]) | x <- [1..15]]
["1","2","Fizz","4","Buzz","Fizz","7","8","Fizz","Buzz","11","Fizz","13","14","FizzBuzz"]

Now all that's left to do is to remove some readability spaces to squeeze it down and blow up our input range to give us 100 inputs instead of 15.

Prelude> [max(show x)(concat[n|(f,n)<-[(3,"Fizz"),(5,"Buzz")],mod x f==0])|x<-[1..100]]
["1","2","Fizz","4","Buzz","Fizz","7","8","Fizz","Buzz","11","Fizz","13","14","FizzBuzz","16","17","Fizz","19","Buzz","Fizz","22","23","Fizz","Buzz","26","Fizz","28","29","FizzBuzz","31","32","Fizz","34","Buzz","Fizz","37","38","Fizz","Buzz","41","Fizz","43","44","FizzBuzz","46","47","Fizz","49","Buzz","Fizz","52","53","Fizz","Buzz","56","Fizz","58","59","FizzBuzz","61","62","Fizz","64","Buzz","Fizz","67","68","Fizz","Buzz","71","Fizz","73","74","FizzBuzz","76","77","Fizz","79","Buzz","Fizz","82","83","Fizz","Buzz","86","Fizz","88","89","FizzBuzz","91","92","Fizz","94","Buzz","Fizz","97","98","Fizz","Buzz"]

78 characters. Not too bad. Please let me know if you see where I could shave off some more.

Roman Numerals Kata in Ruby, Take II

Last week I posted a screencast of my take on the Roman Numerals kata in Ruby. It was Corey Haines who encouraged me to do that, and he was gracious enough to take the time to watch it and offer some suggestions. We both thought it might be interesting if I did another iteration of it and discussed the changes. His two main concerns were that (1) it would have been nice to see the pattern extracted sooner and (2) there must be a way to introduce the zero case without blowing up all the tests.

Here is the first video for reference:



It would have been nice to see the pattern extracted sooner. In the first version, I let quite a few similar cases accumulate before making the inconsequential adjustments necessary to cultivate the uniformity that opened the door to bringing them together in the loop body (about 6 minutes in). The kata process of solving the same problem over and over has led me to a question I have not faced before: how much of the knowledge acquired in previous runs is it fair to apply in the current one? When do we rehearse the discovery process, and when do we simply benefit from the discovery? I've got a feeling I could spend the rest of my life pondering this question.

 There must be a way to introduce the zero case without without blowing up all the tests. This happens around 6:42. I told Corey that this one was a matter of honesty. I knew that introducing the recursion without the zero case would blow everything up because I had seen it happen before. But I thought coding for it without first seeing the test failure felt like cheating, like skipping the first step in the red-green-refactor dance. After giving it more thought, I see where I was off. Only new tests should be red. The red that I allowed to happen was not a new test but a bad refactoring. Yes, test coverage is our safety net while we refactor, but still we should never intentionally fall off the trapeze.

It was short-sighted to introduce the recursion without the trivial exit case in the first place. We all know that such a case is a necessary part of recursion, and it is not cheating to introduce it in a refactoring without waiting for everything to blow up first. I introduced the recursion much earlier this time (1:45). Granted, I knew unfairly that was the direction I would go eventually, but still I coded only what was necessary to get to green. This change in approach addressed both problems; it allowed the pattern to be extracted earlier, and I never broke all my tests. As an added bonus, this also enabled me to shave three minutes off the time.

Here is the new version is set to the fourth movement of Mendelssohn's Piano Trio No. 2 in C minor:

Geek Ballet: Roman Numerals Kata in Ruby

For a while now I've been a fan of code kata screencasts set to music. The musical accompaniment accentuates how beautiful code can be, and frames it to be appreciated as an artistic endeavor, even though it is still a logical exercise. I think of it as geek ballet. Corey Haines first introduced me to this art form, and he recently encouraged me to try one of my own, so here it is. It was more work than I expected, but it was good fun, and I learned a lot. In the same way that writing about any subject forces you to understand it better, demonstrating how to practice forces you to practice more.

In this video I'm using Ruby with RSpec, AutoTest, and Growl notifications. The music is the fourth movement of my favorite symphony, Dvorak's 9th in E minor.

Enjoy.

Set-Based Operations: They’re Not Just For Databases

What do you think of when you hear the term set-based operations? I have always thought of that as a database concept. Set-based operations address or operate on multiple data elements, seemingly in parallel, as opposed to iterating through and executing operations one by one. I was introduced to this concept in the context of SQL in relational databases, and it was a struggle at first. My brain was more naturally predisposed to think in terms of iterating over a list, doing one thing at a time.

I remember first running into this mismatch of approaches writing my first SQL Server triggers. (Let's pretend for the moment that this is not a holy war topic.) I intuitively wanted to do a particular thing with each row that was inserted into a table. I wanted to deal with the inserted column values as scalar values.

update inserted_row set full_name = @first_name + ' ' + @last_name

My problem was that since an INSERT can affect multiple rows, and a trigger fires once per INSERT, an INSERT trigger has to handle all the inserted rows at once. So of course the mechanism provided is the INSERTED virtual table rather than a group of variables like I wanted.

update people
set full_name = people.first_name + ' ' + people.last_name
from inserted join people on inserted.id = people.id

I had to learn to think in terms of sets instead of items. In my group of very young and inexperienced developers, there were several that really struggled with making this leap. This was in the good ole days before SQL Server supported cursors. (Sorry, I'm really not to trying to incite a riot here.) So for quite a few years there, I thought of executing operations on multiple data elements as being done in a set-based manner in SQL,

select sum(salary) from employees

and iteratively in the other languages I used, such as VB, JavaScript, C#, etc.

var total = 0.0;
foreach (var employee in employees)
    total += employee.Salary;

Then along came lambda expressions. This is of course faulty chronology, since lambda expressions were introduced well before I was born. But it was years later that dear Ruby introduced me to the beauty of lambdas. They afford us the ability to specify what needs to be done with each element without bothering ourselves with the particulars of crawling through lists.

employees.map{|employee| employee.salary}.inject(:+)

And of course they found their way into .NET as well.

employees.Sum(employee => employee.Salary)

This syntax is more concise, more declarative, more about intention than implementation. This is all good, but is it anything more than syntactic sugar? I'm a syntactic sweet-tooth myself, but there is more value here than that. We have separated the concern of getting the data we want, from that of dealing with a particular looping construct or iteration implementation. The same lambda can be used regardless of whether we want to iterate through the list serially, spawn threads to execute in parallel, wrap the operations in a transaction, or whatever.

I have recently been programming some matrix math, which has got me thinking about set-based or matrix-based operations as opposed to the more conventional iterative approach. Your geek core might be harder than mine, but I had not used matrices and vectors since high school. In case you don't want to go do any additional reading on matrices, here are a few insultingly simple examples that should be fairly intuitive to read:

1. Multiply a matrix and a scalar:

| 3  1  5 |                   | 6  2 10 |
| 0  2  2 |    *    2    =    | 0  4  4 |
| 6  3  4 |                   | 12 6  8 |

2. Multiply a column vector and a row vector:

| 2 |                             | 2  4  6 |
| 0 |    *    | 1  2  3 |    =    | 0  0  0 |
| 4 |                             | 4  8 12 |

3. Multiply a row vector and a column vector (note matrix multiplication is not commutative):

                    | 2 |
| 1  2  3 |    *    | 0 |    =    | 14 |
                    | 4 |

I was pleasantly surprised to find matrix support libraries for pretty much every language I thought to check for them. Just for fun, let's look at two ways to solve each of these simple examples, each with a different language.

Example 1 in Ruby

Iterative approach:

matrix = [[3, 1, 5], [0, 2, 2], [6, 3, 4]]
for i in 0..2
  for j in 0..2
    matrix[i][j] *= 2
  end
end
# matrix => [[6, 2, 10], [0, 4, 4], [12, 6, 8]]

Matrix approach using the core Matrix library:

require 'matrix'
matrix = Matrix.rows([[3, 1, 5], [0, 2, 2], [6, 3, 4]])
p matrix * 2 #=> Matrix[[6, 2, 10], [0, 4, 4], [12, 6, 8]]

Example 2 in C#

Iterative approach:

int[] column = {2, 0, 4};
int[] row = {1, 2, 3};
var product = new int [3, 3];
for (var i = 0; i < 3; i++)
    for (var j = 0; j < 3; j++)
        product[i, j] = column[i] * row[j];
// product => {{2, 4, 6}, {0, 0, 0}, {4, 8, 12}}

Matrix approach using the Math.NET Numerics library:

var column = new DenseMatrix(3, 1);
column.SetColumn(0, new double[] {2, 0, 4});

var row = new DenseMatrix(1, 3);
row.SetRow(0, new double[] {1, 2, 3});

var product = column * row;
// => 2,4,6
//    0,0,0
//    4,8,12

Example 3 in Python

Iterative approach:

row = [1, 2, 3]
column = [2, 0, 4]
product = 0

for i in range(3):
    product += column[i] * row[i]

# product => 14

Matrix approach using the NumPy library:

from numpy import *

row = matrix('1 2 3')
column = matrix('2; 0; 4')
product = row * column #=> [[14]]

You can see how this approach eliminates a layer or two of loops from your code as well as the accumulation code of adding up sums or whatever. There may not be a huge benefit in these simple cases, but when addressing problems of more realistic complexity this can work wonders for both readability and performance. I have used these matrix constructs mostly in the context of algebraic summations over matrix elements, which are used heavily in various machine learning algorithms such as linear regression and neural networks.

The next time you start to write some looping code, take a second to think about whether there might be another way to go. Chances are that you can accomplish the same thing with less code that will read better and often run faster.

Problems Already Solved

Somewhere I recently heard someone say something like, "Programming is easy; all the interesting problems have already been solved by mathematics." I was a bit taken aback by this at first, but it got me thinking about what problems I am solving when I write code. When I'm programming, am I more often addressing a real-world problem, or some kind of software problem? How much of my code is spent on converting, transforming, serializing, deserializing, logging, formatting, validating, and error handling? Usually too much to be very interesting. It's all plumbing, but what I really want is water.

If I look at the systems I have worked on professionally, an alarming number of them do exactly the same thing, regardless of the business or the problem domain. It's just setting up a place to store data, a way to present it to users, and a way to translate it back and forth. There is still the question of where and how to build in domain logic and intelligence, and that's where most of the interesting debates take place, but this is still a woefully small slice of the pie. Maybe this is why I love writing command line programs. Come to think of it, maybe this is also why I love writing unit tests. There's no user interface, no data persistence, just logic. Okay, you're right, there is still setup and teardown plumbing, but it's not too hard to keep that stuff separate and out of the way. I also love working through the Project Euler problems. The programs feel pure. Just find the answer, and that's it.

I recently completed an online course in machine learning from Stanford Engineering. I loved it. It covered common applications of machine learning such as reading human handwriting, recognizing objects in images, and recommending movies and music. These applications are driving major features of Gmail, Facebook, Amazon, Netflix, and Pandora, to name a few. I was surprised to find that most of the course focused on math. The programming part was not much more than an afterthought. We did programming exercises in a language called Octave, but the work could have been done in any language. These problems are solved by math, not by programming. The programming just does the math. It's a lot like the role your calculator plays in your calculus class. You solve the problems; the calculator just does the math.

I was intrigued by the scene in the The Social Network where Zuckerberg has the idea and hacking skills to slam Facemash together, but he has to ask his buddy Eduardo Saverin, not a code slinger, for the "key ingredient": a ranking algorithm. The problem has already been solved by mathematics.

There are countless opportunities in the world today to make a dent in the universe by applying some existing mathematical solution to a modern problem. I'm looking for one.

Compassion-Driven Development

I have been developing software for a pretty long time now. I have worked on a lot of systems in a lot of different environments. In several of these places my orientation process included a visit to the place where the end users were, a call center or client site or whatever, to see what they did and how they used the system. Oddly enough, this usually happened once when I first started, but pretty much never again.

I recently wrapped up a project that afforded me an opportunity I had never had before as a software developer. I sat with my end users every day. I lived with them. This may sound like a bad idea, and in many cases it might be, but in this particular context I loved it. I have never had such a tight feedback loop. I could push out a new feature and within five minutes hear someone down the row yell, "Hey, look at this!"

Not only did it give me the chance to experience their reactions to my work, but more importantly it gave me the chance to see what they needed. While we geeks love to complain about users asking too much, sometimes they ask too little. Being in the midst of these folks gave me the chance to see them doing what they did everyday. They were working with a legacy system that left a lot to be desired in the way of user experience, and they had come to accept far too many inconveniences as facts of life. They were doing so many manual tasks that were easy to incorporate into the system. They had built processes around design flaws and browser limitations.

They may have had ideas, complaints, and requests, as users always do, but they often overlooked the most obvious things. There is pain in every job, and sometime users can't quite imagine how software improvements could relieve it. Or maybe they've lived with the pain for so long that it no longer occurs to them that they're wasting time and energy. Being with these folks every day as they worked gave me the chance to say to them, "You should not have to do this."

I call this Compassion-Driven Development.

C# REPL

I started a new job recently that has taken me from a primarily interpreted, dynamically typed existence to one that is primarily compiled and statically typed. More specifically, I have gone from Ruby back to C#. This transition is only around my day job; I still love dynamic languages. But since I spend a good bit of time at work, this has affected a significant chunk of my programming life.

So what is my primary pain point coming back to the .NET world after a couple of years of peace, love, and Volkswagen minibuses? No surprises here; it's Visual Studio. In my day-to-day work I do everything I possibly can in VIM. So light, so immediate. Please don't make me open Visual Studio. It is so slow in everything that it does, even just opening and closing. You know, I'm not always creating a multi-tiered enterprise solution with three UI alternatives and seven WCF services. I very often want to write just one or two lines of code to clarify my understanding of some language behavior or some detail of the framework. It is at these times that I most resent waiting two minutes for the IDE to open. And please don't make me create a new solution just to run one line of code. Can't I just get straight to the language for a second?

One thing that Ruby got me addicted to was the instant feedback afforded by irb. Irb stands for "interactive Ruby." It is nothing unique; it's just Ruby's REPL. If you're not familiar with this term, a REPL is a read-evaluate-print loop. It's a command line shell in which you can type a line of code and have it execute immediately and print the result. For you Visual Studio folks, it's kind of like the Immediate Window, but it doesn't require a paused executing application.

Of course the REPL was not born with Ruby. I think it originated with LISP (before I was born), but you get one with Python, Scala, Haskell, Perl, Prolog—lots of languages. Modern web browsers with good debugging tools provide a REPL for JavaScript, but I prefer the one you get with Node. You might notice that these are all non-Microsoft languages, but my first experience with a REPL was in BASIC, and it was there in the version that came with MS-DOS back in the early 80s.

What is so special about a REPL? If programming is the way we communicate to a computer what we want it to do, must there be so much ceremony around saying anything at all? Writing an application is like writing a book. A small program might be more like a personal letter. But what if you just want to say something, or ask a single question? What's the largest integer value? Can you implicitly cast a float to a Boolean? What happens if I try to add a decimal and a null? What date is ninety days from today? Can you square a list of integers in one line of code? This is where the REPL shines. It's more like a conversation.

If you're like me, you've been spoiled by a REPL in another environment, and now you're spending your days in .NET, you've got to be mourning the loss of that instant feedback. If this a luxury you have never had, I'm telling you now what you've been missing. The good news is that there is a C# REPL in Mono. I don't know why I have not heard more talk about it, but it is a big deal to me. It is totally worth installing Mono for, even if you use it for nothing else.

Just head over to mono-project.com and install Mono. You don't even need MonoDevelop (although it is worth checking out). Add Mono's bin folder to your path, and you've suddenly got this at your disposal:

C# in a REPL. No Visual Studio. No project. And if that's not cool enough for you, it's Mono, so it works on OS X and Linux, too. Use wisely. Enjoy.

Underwater

Remember on Fear Factor when they used have people go underwater and pick a lock or solve a Rubik's cube or eat some disgusting animal part? Did you ever think about how you would approach that challenge? I always think about these things. I don't know why, because I will never be on one of those shows, but if I were, I would have thoroughly considered my approach.

If I'm going underwater, and I need to get something done, I will be focused from the start. I've got 30 seconds' worth of oxygen in my lungs; I can't just dive in, turn a couple of flips, wave at the camera, and maybe plan my dinner menu for the week. If I do that, I'm definitely not going to get the lock open. Fortunately, as my body gets desperate for oxygen, the survival instinct will kick in, and I'll go scrambling for the surface. So I may fail, but at least I won't die.

Unfortunately I was not born with similar instincts for dealing with my computer. I have one thing I need to do. Maybe I need to send one email. Maybe I need to check tomorrow's weather. Maybe I need to make one tiny update to some web page. It doesn't matter what is. I need to hold my breath, dive in, do the thing, and get back to the surface. But my mind does not have the same fearful respect for the internet that it has for water.

I go in casually, oblivious to the danger, with no sense of urgency. I look at email, RSS feeds, Twitter, Facebook, CNN, Reddit. I willingly expose myself to every source of distraction conceivable. If I see anything interesting in one of these places, it pulls me further in. What's worse, if I don't see anything interesting in one of these places, I'm just stupid enough to think about where else I might look to find something interesting. It's a black hole. At this point I have already failed to meet my goal, to accomplish my one meager task, whatever it was. But the really tragic part is that I don't have the sense to scramble back to the surface to catch my breath. I'm already lost, and now the giant leech has attached itself to my life clock, gently sucking away the hours.

Computers are my livelihood, and I enjoy them. It's hard to imagine life without them, but sometimes I like to try. Yes, they may make our lives hundreds of times easier and more efficient, but as good as they are at helping us get things done, I think they might be even better at helping us not get things done. Don't get me wrong; I'm not going anti-tech on you. I'm just wishing there were a way to automate self-discipline.

There's no app for that.

Io - The Language

As a participant in the NashDL Book Club, I've been working my way through Bruce Tate's Seven Languages in Seven Weeks. To be fair, we only meet once every two weeks, and we're hitting one language per meeting, so in our case it's seven languages in fourteen weeks. The first language we looked at was Ruby, which is of course an interesting language, but one that most of us were familiar with already. The real fun of this book is learning new languages, so I'm excited to have moved on to language number two, Io.

It must be acknowledged that this is a terrible name for a programming language if only for its ungooglability. It might as well be named Stack Space or Garbage Collection. This dynamic language is primarily inspired by Smalltalk, which I have had very limited experience with. Io is prototype-based, which makes me relate it to JavaScript, but Io is more strictly prototype-based. In JavaScript you can make a function act like a class and use it to create objects, but in Io there is nothing that even resembles classes. Types of objects are defined by building up prototypes and cloning them. The genesis of all things is the clone method of the Object type.

Person := Object clone
Developer := Person clone
IOer := Developer clone

All types are wide open to be modified in most any way, similar to the way classes are in Ruby. Properties and methods can be added, removed, and redefined at any time. Of course, this opens the door to both magic and disaster, so hack responsibly.

Io has an extremely simply syntax and some handy features that lend themselves nicely to creating DSLs. For example, to define the meaning of curly braces, you just create a method called curlyBrackets. Same with squareBrackets. Io also lets you define your own operators. This takes me straight to when Uncle Bob said that what killed Smalltalk was how easy it was to make a mess. It looks to me like that part of the Smalltalk legacy has been preserved here. It's very cool, but it reminds me of Inception when Ariadne starts getting too creative with her architecture. Sure, she is able to fold the world over on top of itself, but then she's got some seriously agitated projections to deal with.

Io is not the fastest language out there, but it might make up for that with some nice features for concurrency and asynchronous i/o. Anyone up for a new implementation of node.js? Might be fun.

I don't know if I will ever use Io in real life, but I have found it useful for helping me to think in a more prototype-oriented manner, which is necessary for writing good JavaScript. I'm still working to make amends with JavaScript after years of trying to treat it like C#. I think it's starting to forgive me. Thanks, Io.

Whitespace: And Now, For Something Completely Different

We've probably all heard it said that any fool can write programs that a compiler can read, but a great developer writes programs that a human can read. Of course some languages lend themselves to human readability more than others. I have often heard Perl picked on as a "write-only" language. Well, I recently ran across a language that puts Perl in the clear.

Check out Whitespace. If you've got a place in your heart for ridiculous languages, you'll eat this one up.

On Software and Music - In With the Old

As one of the many software developers who are also musicians, I have always been fascinated by the frequent bundling of the gifts and passions for these two endeavors and what they have in common. I have always said that writing code and writing music feel a lot like the same process to me, like they're using the same parts of the brain. Music and code are certainly similar in many ways. Both need structure and coherence. Each work must be unique in some way, or it is meaningless. Both must follow some set of rules. What set of rules to follow is a creative choice. Sometimes you can even make up your own rules, but failure to follow them will pose a threat to the cohesion of the work. Once the rules are established, you may occasionally, carefully, and mindfully, make some real magic by breaking them.

Looking at these similarities causes me to wonder about their differences. If the creative processes are so similar, what about the products thereof? One difference I notice is that music seems to be much more durable than code. The software world is in so many ways all about "the new hotness." The music world also has this element, but old music is much more present in the world than old code. Not that old code doesn't have its own nostalgic place our hearts. This is the magic of Mame and cool projects like the AppleSoft BASIC Interpreter in JavaScript and FC64. It's why people buy Donkey Kong machines on eBay. The musical side of this nostalgia would be listening to Van Halen I or Synchronicity or Frampton Comes Alive or whatever you remember listening to as a kid.

But what about the work that we consider to be truly significant? In the music world we still study Stravinsky, Mendelssohn, Beethoven, Mozart, Bach, Gabrieli, even Gregorian chants, not as nostalgia, but as work that is still relevant and valuable today. Where is this reverence for history in software? What is the difference? Is it in the platform evolution? Each new computing device to hit the market seems to render last month's model instantly obsolete. The arsenal of musical instruments over the years has progressed more by expansion than by evolution. The new does not generally displace the old. We've added saxophones, steel-stringed guitars, drum kits, electric pianos, electric basses, synthesizers, and on and on, but the symphony orchestra still looks pretty much like it did three hundred years ago.

This is one of the things that I find so fascinating about all the recent movement in the field of functional programming. It's old! LISP was developed in the 1950s, and we're studying this approach today not because it tells where we've come from, or because we have fond childhood memories of it, but because it is valuable to us right now. I have never seen this happen before in this field. Maybe it's just because I'm getting old, but I'm intrigued and excited to see "the new hotness" can be something that is older than I am.

We Want the Func! - Moving Toward Functional Programming

In the last year I have heard/read where Uncle Bob has been talking about discovering the twenty-six-year-old treasure of a book The Structure and Interpretation of Computer Programs. It happened enough times that I decided to check it out. The book is available free of charge here. The language used in the book is Scheme, an implementation of Lisp. I hadn't written or read any Lisp since college, but even then I really liked it.

At the time I had no idea of the concepts of functional vs. imperative programming. We didn't talk about immutability; I just thought it was interesting that you had to use recursion where you would normally have used a loop.

About fifteen years later I found myself learning XSLT. While here we do have the <xsl:for-each> element, I once again discovered that if I wanted to count from one to ten, I had to use recursion. That didn't throw me so badly, but what did throw me was the <xsl:variable> element. Maybe it was just the name and my own notions of how a variable is used. I thought I should be able to do this:

<xsl:variable name="x" select="1" />
<xsl:variable name="x" select="$x + 1" />

But nope. Once x is defined, that's it. No one was there at that moment to offer me the term immutability, but there it was. Little did I know that a few years later, linear processing speed would be maxed out, having bumped its head on the laws of physics, and this concept would give traction to something of a programming revolution in pursuit of scaling via concurrency.

After a decade or so of studying Gang of Four and Fowler, honing our OO skills, now .NET geeks are delving into F#, JVM nerds are digging into Clojure and Scala, and Erlang and Haskell are finding their way out of the classroom and into the business world. Even though web developers have been writing client-side code in JavaScript for the last fifteen years or so, most of us never noticed what great functional capabilities it had until recently when jQuery showed us what kind of magic a more functional approach had to offer. And why should all that magic be confined to the client side? Along comes node.js, bringing all that non-blocking functional goodness to the server, or wherever you might need it.

Anders Hejlsberg, king of Turbo Pascal, Delphi, and C#, has been talking lately about the future of programming languages and how important functional capabilities will be to keep them moving forward. This video is a little over an hour long, and it's all good, but if you don't have that much time, at least watch his overview of what functional programming is, which starts about 21 minutes in. It is excellent. He says so much with the simple phrase, "more like math." He also says some interesting things about "islands of functional purity" in the context of more conventional data-oriented (mutable-state) applications.

So what is my point here? Simply that there a lot of us who might just be starting to feel like we've made the transition from procedural to object-oriented programming, and we need to be aware of this functional movement and do what we can to embrace it and adapt to it. It's a very different way to think about solving problems, and it's a lot of fun. Onward and upward! There's more to life than inheritance.

Breaking the Ice with IronRuby

I'm a Windows guy and a Ruby guy, so of course I was disappointed at the recent developments around Jimmy Schementi's job change and what Microsoft is doing with the IronRuby team. I want to believe what some other folks are saying about the reports of IronRuby's death being greatly exaggerated, but it still doesn't look too good to me. A few days after this buzz started going around, I started thinking about what I'm doing about it. I'm using Ruby on Windows quite a bit, and there are not a lot of us, but I'm doing all my Windows work on MRI (Matz' Ruby Interpreter). I have IronRuby installed, but I don't use it for anything but an occasional experiment.

If I really care about the future of IronRuby, I need to be a little more supportive, maybe even (dare I say it?) get involved. I recently discovered the new Iron Languages Podcast and learned that there are three (count them) IronRuby MVPs. I honestly didn't know there were any. Anyway, I got inspired to start trying to work IronRuby into my life somehow.

I am a little concerned about how compelling most not-already-Ruby-infected .NET developers will find IronRuby without any Visual Studio tooling. That makes it more of a .NET for Ruby folks than a Ruby for .NET folks. So I thought I would try using it for some of my normal Ruby stuff, the same way I might spike JRuby or Rubinius. Can I do some simple BDD with VIM, rspec, and autospec with Growl?

The first thing I did was to clean up my installation. If you don't have other versions of Ruby installed, the stock IronRuby install works just fine. They've replaced the commands ruby and gem with ir and igem, but if you install autotest or rspec or any other gem that you might call directly from the command line, you can run into conflicts if your MRI gems and your IronRuby gems are both in your path at the same time. I manually removed IronRuby from my path and added it to my pik list. Now I just use pik to choose IronRuby, and it handles the path changes for me.

By the way, if you have IronRuby installed in a directory with any spaces in the full path, it's going to cause you some trouble down the road with certain gems, so do yourself a favor and put it somewhere other than under C:\Program Files\.

I installed some of my favorite gems rspec, autotest, and autotest-growl, which all installed fine because they don't use native extensions. Then I got started on Uncle Bob's good old prime factors kata. You know what? It pretty much worked! The tests ran fine when triggered by saving files. I had a small problem with autospec's handling of Ctrl-C to force the tests to run on demand. It seemed to handle it twice, which caused it to exit, which was less than helpful. But other than that, it appeared to run just like MRI. Even my Growl notifications worked. Love me some Growl.

Now that I've got IronRuby acting like Ruby, I need to get it acting like .NET. I'll save that for another day. Stay tuned.

Hey, you got Ruby in my JavaScript!

I am a big fan of Ruby's Enumerable module. I has some crazy useful methods that get mixed into every array. I have said before that I wish I could somehow use Ruby's Enumerable module in every other language I use. I don't know about every other language I use, but if we're talking about JavaScript, it's pretty doable.

For example, let's look at the find_all method from Enumerable. According to the documentation, when called on an object enum and passed a block block, it returns an array containing all elements of enum for which block is not false. The following line will give us the integers from 1 to 10 that are divisible by 3:

(1..10).find_all {|i|  i % 3 == 0 }   #=> [3, 6, 9]

It's like a little query engine on your arrays. Don't you wish we could do this in JavaScript? Something like this:

[1, 2, 3, 4, 5, 6, 7, 8, 9, 10].findAll(
  function(x) {
    return x % 3 === 0;
  }
)  //=> [3, 6, 9]

Well, one very nice thing about JavaScript is that we can add methods to any object's prototype, and then any object of that type will have that method on it. In our case, we can add a findAll method to all Array objects. To make this work, all we have to do is execute this first:

Array.prototype.findAll = function(f) {
  var result = [];
  for (var i = 0; i < this.length; i += 1) {
    if (f(this[i])) {
      result.push(this[i]);
    }
  }
  return result;
};

Give it a try. Hey, you got Ruby in my JavaScript! Okay, to be fair, we can't really give Ruby the credit. It's just an example of higher-order function usage, but it enables me to give JavaScript a feature that Ruby has spoiled me with.

Enjoy.

Douglas Crockford's JavaScript: The Good Parts

After hearing more recommendations than I could ignore, I have just finished reading Douglas Crockford's JavaScript: The Good Parts. Thanks to Jerry Cheung over at whatcodecraves.com for pushing me over the edge. Read it if you haven't already. It is full of ridiculously useful details about the ins and outs of a language that few of us can avoid, but it is also full of something I was not expecting: opinions. Crockford doesn't present a single concept without passing judgment on it. This is good. This is bad. This is awful. They got this right. They got this wrong.

I love this approach. The magic of it is that he not only passes judgment on each aspect of the language, but he ultimately tells us how to use the good parts and avoid the bad parts. This effectively makes the language better. It's not about bashing someone else's work; it's about helping us to make the most of it.

The Cost of Continuous Improvement

Rails 2.3.9 was released this week. Rails 3.0 is already out, and the main purpose of this release is to smooth out the migration path a bit. This means we're watching for deprecation warnings, right? Okay. I installed it and ran my test suite. I got a whole bunch of this one deprecation warning:

DEPRECATION WARNING: Object#returning has been deprecated in favor of Object#tap.

I have been a fan of Object#returning, but Object#tap was a new one on me. I looked them both up. Here are their sources:





They clearly do exactly the same thing, one with an argument, the other with itself. It's the classic smell of duplication. Now they're fixing it. Their code is getting cleaner, and I have to change my code to stay in line and keep it from breaking in the future.

I have been developing software on the Microsoft stack for twenty years now. That is more than enough time for me to have based a few opinions about "how things are done" on their example. I have been developing in Ruby and in Rails for about three or four years now, and I see some very different ideas played out about "how things are done."

Among other things, I see two polar opposite approaches to breaking changes in tool sets, be they language or framework. Microsoft has always done everything they could to avoid introducing any breaking changes into their tools. This is a good thing, right? Who would not want to know that the code they wrote today will still work after they install the next update? In twenty years as a 'softie, the only major breaking changes I can remember being introduced came with the move from VB6 to .NET in early 2002, enough VB developers made enough noise that Microsoft went back and retroactively added backward compatibility with many legacy VB language constructs that had been removed in the 1.0 release.

On the other hand, new versions of Ruby and Rails often have some breaking changes. Not only do changes often break things, but they come much more frequently than they do in the Microsoft world. The standard update routine here is to read the release notes to see what to look for, install the update, run the test suite, see what broke, and get to making changes to fix things. This is a bad thing, right? Or is it?

Take a step back and look at the cumulative effect of these two approaches. In the Microsoft world, we have more of a sense of stability going forward. In the Ruby world, the tools have more freedom to change. If Microsoft allows any mistakes, bad design decisions, dangerous features, etc., out into the field and into the hands of developers, it is most likely going to be years before they can fix it, if they ever can. The problem might be there for the life of the platform. In the Ruby world, the same types of mistakes get made, but fixing them will usually involve a deprecation in one release and then a fix in the next.

So why can world afford to change things and the other not? Is it because they just don't care? Is it because there is no corporate entity afraid of making everyone mad enough to abandon their platform? Ruby and Rails are clearly thriving in this world of breaking changes. How? What is the difference? The difference is in the tests.

They have created an ecosystem that is dependent on test coverage. If I have a good test suite, I know where my breaks are as soon as they occur, whether they have come from a library update or from changes I've made myself. Change is no longer so dangerous. We can also have a sense of stability here, but it comes from testing rather than from the lack of movement. If I am not in the habit of keeping good test coverage, it is going to be difficult for me to survive in this culture. So Darwin keeps us test-covered and change-tolerant.

When change is no longer something to be avoided, we gain a new freedom to improve things. The Boy Scout rule of leaving code in better shape that you found it has long-term effects. Things get better. This is what refactoring is all about, right? Don't we spend more time maintaining a system than building it? I think most systems get built way before they get good. And if they can't be refactored, molded, tweaked, rearranged, nurtured, changed; they never will get good.

I think it is the cumulative effect of the freedom to improve things that has brought Ruby and Rails to place they are today. I find them thoroughly enjoyable tools to use. They're not perfect, but they're better than they were last year, and they're not as good as they will be next year. If that means I have to take a little time with each release to roll with the changes, that is a small price to pay.

pik: RVM for Windows

Of course RVM is pretty much ubiquitous for managing multiple versions of Ruby on Linux and OS X, but what about all you Ruby folks on Windows? I just want to make sure you know about pik. Installing new versions is not quite as smooth an experience as RVM, but it's not bad, and the switching between versions experience is actually better than RVM, because it fuzzy-matches the version with what you type.

So if you've been itching to play around with Ruby 1.9.2 but you're still working on an app in 1.8.7, pik is your answer. And if you're still clinging to your Visual Studio and have not yet taken the plunge to see what all this Ruby buzz is about, by all means head over to rubyinstaller.org right now and get started. You won't regret it. The more Windows users on Ruby, the better.

Free Stuff

I really like free stuff. I recently discovered the Music City Circuit, a free bus service that runs two routes through downtown Nashville. Yes, the routes are limited, but hey, it's free. It opens up all kinds of options when you're trying to spend less on your parking than on your dinner.