Ruby is a dynamic language. For people who know and love it, that is almost a cliché. Presumably, these people think that a dynamic language is better than a static one in some way.

But what does it mean in practical terms? Why should we want to do something at runtime instead of at "coding time"? In short, why should we care?

I was first exposed to this concept in 1990, and I didn't get it at all. My friend was waxing eloquent about Smalltalk, a language I didn't know. "You can add classes and methods at runtime," she told me. On one hand, I was suitably impressed. But on the other hand, I thought: Why would I ever want to do that? It sounds like changing a tire without pulling the car over.

Well, imagine a programming task in which the data format drives the code. To demonstrate what this is all about, I'll use the trivial example of a CSV file (comma-separated values) with a descriptive header at the top. We'll make a couple of simplifying assumptions along the way, to make the code simpler and easier to grasp.

Suppose our data file people.txt looks like this (the names are all fictitious):

    file: people.txt
    ----------------
    name,age,weight,height
    "Smith, John", 35, 175, "5'10"
    "Ford, Anne", 49, 142, "5'4"
    "Taylor, Burt", 55, 173, "5'10"
    "Zubrin, Candace", 23, 133, "5'6"

In static languages, external data shapes the code at development time or not at all; for example, how would we tackle something like this in C or C++? We would probably define a struct (in the first case) or a class (in the latter case) with members called name, age, and so on. But this solution is overly specific; the names are effectively hard-coded into the program. Given a text file similar in structure but with different names, we would have to start over. It is also fragile, in the sense that if the file format changes (by adding a field), our code has to change also.

We might prefer a solution that was more independent of the exact nature of the data. For example, we might store the name-value pairs in some kind of hash or associative array. This is not a bad solution; but it makes the individual data members "second-class citizens;" we need an extra level of indirection to get at the data. Items such as "name" and "age" remain merely strings, and can't be treated directly as attribute names.

So we have a solution that feels "natural" but is very inflexible; and we have a solution that is powerful and general, but feels clunky in use. Is there some way to get some of the benefits of both solutions?