How did SQL get so popular?

Many developers, especially of the younger generation, dislike relational databases and their business-partner, SQL. It is regarded by some as the new assembly language. With all this distaste going around, how did it gain such a strong foothold in industry?

I offer you two answers: ACID and surface area.


Atomicity, consistency, isolation and durability. It’s not something most folks want to think about. To a rookie developer, it’s overwhelming. They’re not yet familiar with the semantics of the systems their programs run upon. Is fread thread-safe? “How should I know, I just learned C last semester and about fread’s parameters last week!”

The promises of a modern relational database include a compelling bullet point: your data is safe with us. Use our APIs, don’t break the rules, and we will make sure you never blow away some data and get a call at 3 AM. Rather, the DBA will, but what do you care about that guy?

So I submit to you that most programmers don’t use databases because they’re great. Rather, they have come to rely upon them because the canonical tome on transactions is heavy enough to maim small mammals and rife with formalisms. So they skip the nine-hundred page textbook and pick up the six-hundred page O’Reilly book.

Surface Area

Most programs that people will pay you to write involve side-effects. Further, many of those side-effects have to do with saving data off so you can perform further side-effects on it in the future.

The rookie developer typically leans first to files. Files are familiar and pervasive. But files leave a lot to said rookie. How should I structure my data? How do I load and save the data? How do I manipulate the data once it’s in memory? Even in scripting languages, with their simplified APIs, this means the rookie is faced with APIs like this:

  • fopen
  • fread
  • fwrite
  • seek
  • fclose
  • encode
  • decode
  • hash_set
  • hash_get

When I was bit a wee lad o’ programming, I found this Gordian knot difficult to cut. But then, one day, I was told by a programmer of greater wisdom to use a database. That API looked like this:

  • connect
  • execute
  • fetch
  • next
  • select
  • insert
  • update
  • delete

It was a lot easier to understand, even though the last four are a completely different language.

So, I submit to you, that SQL also won because it was easier to understand how one might structure their programs, make them work and, if they’re lucky, get them to run quickly.

Inflection point

I’d wager that five years from now, the generation of developers who are now upcoming won’t take the database tier for granted. Key-value stores, distributed file systems and document databases will all play into the question of “what do we do with the important data?” Sometimes, relational databases will prove useful. But increasingly, other things will too.

In the end, there’s two ways to look at this: we will soon throw down the shackles of our relational overlords, or, prepare yourself for the database renaissance in programming fashion that will occur in a decade or so.

Everyone wins!

This is no former-Parrot

Hey look! Parrot went 1.0. Parrot is an open source virtual machine aimed at making it easy for dynamic languages like Perl, Python, PHP and Ruby to target the same VM.

I’m glad to see this is finally out. About six years ago, I thought it had the potential to be a Big Deal™. It’s been a long time in the tooth, but I’m interested to see how this plays out with the resurgent JVM and the general renaissance of language design.

Awesome yak shaves

I was sharing some nefarious plans with Dave Thomas yesterday at the DFW PragProg lunch. He later tipped me off to “tinyrb”:, which is awesome. It’s a minimal implementation of Ruby that uses “Ragel”:, “Lemon”: and is inspired by “Potion”: I’ve long had a thing for messing with languages and their implementations, so I quickly ended up at this “great Ragel tutorial”:, and then reading about “register machines”:, “context-free grammars”: and “LLVM”:

I accomplished nothing, but diving into a topic is it’s own reward. Here’s what I’ve concluded:

* I’m super green at this stuff. But I want to go to there.
* There’s too much awesome stuff to do out there: tinker with languages, build apps, visualize data, network things, etc.
* “Marc-André Cournoyer”: is my hero; not only did he implement tinyrb, but he’s also the guy behind “Thin”: and “Refactor My Code”:

Long story short: I need more time.