Phrases like "rewind, stop, replay" and images of VHS tapes have whispered and hovered in my mind since I started working on Dialogue I've always known Dialogue to be a machine that could process forwards and backwards, but could never explain why I thought that way.

I recently stumbled into this Stack Overflow answer which helped me "press play" on those thoughts. The top answer defines data-driven programming as a "model where the data itself controls the flow of the program and not the program logic."

I remember running into this a year ago and not making any sense of it. I found it hard to think of a program that didn't define any direction or flow. Constantly skirting the Ah-ha! boundary, I asked questions like "How does a program just chug along without program logic?"

Here are some Socratic answers to that question: "How does the cook know what to make when the cashier takes the order?", "How does a compiler know what to interpret when it reads source code?", "How does a VCR rewind and replay a tape?"

Here's a recreation of how I came to understand data-driven programming.

A Common Language

Events are one of the largest data-driven methods of programming and they're absolutely everywhere online. Take the average website for example -- buried on one its pages is some javascript like button.click(displayMenu) . The code tells the event listener to call displayMenu when button is clicked.

That code isn't data-driven, but it works and it's easy. However, over time the displayMenu inevitably becomes displaySignup . Then the button changes ids to #sign-up-button . What happens when the boss rolls in and says, "We need to test out this other button for our sign-up menu, can you do that?"

Many will find something like jQuery's bind . It handles all of the stuff we need -- the element itself, the event, and the data which is displaySignup .

$('#other-sign-up-button').bind('click', displaySignup)

bind seems good because it handles all the things we were juggling before. Maybe we could abstract further and find some commonality between those things, but it doesn't really matter -- we did what the boss told us. Plus, anytime the boss wants to use otherButton instead, it's just a one line change!

But we're not worried about maintainability. Let's shift paradigms by putting ourselves in a hypothetical situation: the boss wants to display button to some customers and otherButton to others customers for A/B testing.

How can we use both button and otherButton for a displaySignup click event but never both at the same time?

If we imagine that we can tell the website what to code instead of coding it ourselves, we can tell it to display blue buttons to people that came from Google. Or disable pop-up menus if they came from a website that generally doesn't like them.

How is this possible? Well, how can a VCR play any tape given to it but never more than one at a time? The tape serves as a common language the VCR knows and any tape, as long as it uses the right language, can make the VCR display anything.

What is our language? By using events, we lucked out by having one already created for us -- the element, event, and callback. It might be easier to think of the callback as the only piece of data, but an event isn't complete without all three. The following are two separate events and JSON data.

{"element": "#red-button", "name": "click", "call": "displaySignup"} {"element": "#blue-button", "name": "click", "call": "displaySignup"}

This is the common language and our tape. Since we have the tape, we can now make the VCR itself which probably looks something like:

$(json.element).bind(json.name, functionFromString(json.call))

Data-driven programming is about finding the language a program is using, rewriting the program to understand that language, and then feeding the program instructions in that language. One doesn't manually wind the tape for the VCR, so why manually handle the event assignment for this website?

I want to stress that data-driven code is a language and, like any language, it can be misunderstood or, worse, misinterpreted. Part two, coming soon, will talk about the design and issues of making an entirely data-driven application.