The Inevitable Excel-Ruby Comparison

This blog post is partially inspired by Carlos Lazo’s comparison of C++ and Ruby, which you can read here.

For the past 2.5 years, I have lived in Microsoft Excel. This is not a joke. I spent, on average, 50-55 hours a week in the office. More than 50% of that time was with a spreadsheet open, so that amounts to at least 3125 hours. Yikes!

After my first few weeks of Ruby, I can’t help but make analogies to the world of Excel and compare Excel’s functionality to the way object oriented programming languages work.

Ruby is an object oriented programming language, which means it focuses on the interaction of objects rather than a sequence of tasks like in procedural programming languages. Three main components of an object oriented programming language are Classes, Objects, and Methods.

Classes and Methods

In Excel, think of cells, in general, as a Class. The Class called ‘Cells’ has specific characteristics and behaviors that it can execute, which are defined by its Methods. What is an example of a Method that the ‘Cell’ Class would have? The ‘Cell’ Class would definitely have the ‘sum’ Method, which would take in parameters (maybe an array of other Objects) and calculate it’s sum. Below is my basic interpretation of what a ‘Cell’ Class might look like with it’s first two Methods, the initialize Method and the sum Method:

class Cell
  attr_accessor :value
  def initialize
      @value = 0
  def sum(array)
      @value = 0 #resets value to zero
      array.each do |cell|
          @value += cell #performs addition

Although Microsoft Excel is pretty much a closed source program, it does give hints from time to time on it’s underlying structure. For example, in this picture you can see that Excel’s SUM function can take multiple parameters by simply selecting a cell and dragging. To me, this is like creating an array as a parameter.

Viewing each cell as an Object

Each individual cell that you see on a spreadsheet could be thought of as an instance of the ‘Cell’ Class, more commonly referred to as an Object. Each cell instance has a separate location on the computer’s memory, has access to all of the Methods of the ‘Cell’ Class, but the instance variables within each cell can contain different values depending on what you put in. So, think of the ‘Cell’ Class as a template for each of the individual cells on your spreadsheet.

The way I imagine Excel to work is that all the cells you see in your spreadsheet are instantiated when you create a new file. In the following code, I’ve created a basic spreadsheet with one column and four rows:

a1 =
a2 =
a3 =
a4 =

Based on the previous code we wrote for the ‘Cell’ Class, each of these cells is unique, but can perform the sum Method in the same as every other cell. Now, let’s add some values and use the sum Method:

a1.value = 5 #This is like typing in a value to a cell
a2.value = 5*5 #This is like typing in a math operation into a cell
a3.value = (6*4+6)/10
a3.sum([a1.value,a2.value]) #This is like over-riding a cell's value using a sum Function by clicking and dragging multiple cells

I haven’t yet figured out how to show IRB output through markdown, but I can assure you that the answer for the last line of code was indeed 30.

There will always be a special place in my heart for Excel. Eventually, it will have to make room for Ruby and other languages as I become a more and more proficient programmer. At some point, I think it would be really interesting to read a little bit of Excel’s source code and compare my conception of it’s inner workings to reality!