Parallel

Dave Thomas Interview: The Corruption of Agile; Ruby and Elixir; Katas and More

The pragmatic programmer who popularized Ruby and katas and was an original signatory of the Agile Manifesto discusses what's wrong with Agile, why he thinks Elixir is the next killer language, and how to design your own programming challenges.

DT: There are two questions there: What's wrong with the current way of programming? And then, why Elixir?

AB: OK.

DT: What's wrong with current programming is something that almost everyone recognizes and most people hope will go away: Moore's Law still applies and for that to have happened, we find that the architectures of our machines have changed dramatically. So, we're looking at multicore, hyperthreading, off-loading processing on to GPUs, and so on. My laptop has a billion transistors in it, which is incredible. And no one can keep a billion transistors busy if they're doing sequential coding. You have to partition the work and do multiple pieces at the same time. And our tools for doing that at the moment are remarkably primitive. They're based on evolving old models. It's like we're saying we got here with object orientation and now we have to make it work concurrently  just slap a few more primitives in and hope. The reality is that doesn't work that well. Clearly, it works, but it takes a lot of effort and it's error-prone.

AB: Quite true.

DT: There have been some solutions. In the '70s, Tony Hoare came to my college and gave a talk about communicating sequential processes. That was so clearly the way to write concurrent code and yet it was ignored until the mid '80s, when the phone companies who knew about that and about Prolog thought they could marry the two and they created possibly the world's ugliest language, Erlang.

AB: [Laughter]

DT: But…one of the things about Erlang is that its syntax is an incredibly bitter pill, but once you swallow it, you get these incredible health benefits. The ways of writing code in Erlang are revolutionary; the problem is that they're all wrapped up in some pretty ugly clothing. But I think there's no longer any debate, the future has to be functional, immutable data, and it has to be concurrent. It's the only way to grow. And very few of our current languages let us do that.

AB: Yes.

DT: So, I've been looking for a long time for a language that can do all that. I liked Erlang, but I was afraid that the Erlang folks had positioned it as a niche language. Then, the Elixir language came along. It took the Erlang virtual machine, BEAM, and put a sensible face on it. It gives you all the power of Erlang plus a powerful macro system. It gives you these things called protocols, which allow you to have shared behavior. And the syntax is a lot more powerful. And so for all those reasons, I thought Elixir is important. In addition, José Valim, who wrote the language, is very smart and has clear ideas of where he wants the language to go.

AB: So, a strong leader of the language.

DT: Strong, but he's not a jerk. He's solid in himself.

AB: It seems like many successful languages have someone like that: a dictator who's not an autocrat.

DT: I think so.

AB: Perl, Python, Ruby all have one.

DT: Yes. And I like showing people how to do this kind of programming, but I didn't have the tool to do that with. But now with Elixir, I have that.

AB: The book is frequently updated. Is that because of your writing or because the language is changing?

DT: The language is changing dramatically. It's intentional. Partly, José is experimenting. Partly, he was advocating for a new data type in the Erlang virtual machine: maps. The book I'm writing on Elixir is content-complete, but I try to release updates shortly after José updates the language.

Today, a lot of people focus on knowledge: conferences, books, etc. But what you really have to gain is experience, and katas help you do that.

Katas

AB: You are the person who invented code katas, small self-contained programming exercises that refine a pattern of behaviors.

DT: Yes. The initial idea behind the kata was to discuss something I do all the time. I like coding and I like to experiment with code, so typically I'll take some algorithm and try coding it in different ways: different languages, different techniques, or anything that will give me different insights. And as programmers, we rely on tacit knowledge. Alfred North Whitehead said, "Civilization advances by extending the number of important operations which we can perform without thinking of them." And katas are ways of forcing your brain to internalize patterns of experience, to associate stimuli and response.

AB: Somewhat like muscle memory.

DT: I don't like the term "muscle memory" because it implies it's not taking place inside your head.

AB: Good point.

DT: The reality is that every programmer has tacit knowledge, but he has it by coincidence: He's learned it on the job. What I want to do is to help people have exercises in which they can, by themselves, build their tacit knowledge.

AB: Yes.

DT: In martial arts, the idea behind a kata is a set of movement that simulate an artificial fight, but it's never a fight that you will have in reality. In theory, once you get past the movements stage of a kata, you're building tacit knowledge. All martial artists say that in a fight, they're not thinking about the moves, they're not thinking about blocking or attacking. They're thinking about the pattern. And what's doing the actual fighting is the muscle memory, if you like, from the kata.

AB: I see.

DT: Again, I'm slightly saddened to see that people have taken the word and turned it into a competitive thing.

AB: That seems like the antithesis of your original goal.

DT: Indeed it is. Today, a lot of people focus on knowledge: conferences, books, etc. But what you really have to gain is experience, and katas help you do that.

AB: So, what makes a good kata?

DT: It really depends on who you are. The katas on my site are self-contained and good for beginners. Once you have experience, you need something meatier. My current choice is to write a markdown translator. And I do that because markdown is an abomination of a syntax. It's very difficult to formalize it, so you're constantly making heuristic decisions, and the problem is big enough to exercise many different areas of programming. I've now done markdown in JavaScript, Ruby, and many, many times in Elixir. Ultimately, a good kata depends on what you want to get out of it. If you're an experienced developer, then you need something that permits you to push yourself.

AB: Would it make sense to do katas, say, on a design pattern? Learn to implement the flyweight pattern, for example, in numerous different situations?

DT: If the intent was not to implement the pattern, but instead to investigate what the pattern meant, then that's a very good kata.

AB: What appeals to me about katas is their small self-contained size. Today, most any program involves multiple languages and platforms, and has a lot of code dedicated to the UI. It's hard anymore to write short, simple programs.

Dr. Dobb's encourages readers to engage in spirited, healthy debate, including taking us to task.
However, Dr. Dobb's moderates all comments posted to our site, and reserves the right to modify or remove any content that it determines to be derogatory, offensive, inflammatory, vulgar, irrelevant/off-topic, racist or obvious marketing or spam. Dr. Dobb's further reserves the right to disable the profile of any commenter participating in said activities.

Video

This month's Dr. Dobb's Journal

This month,
Dr. Dobb's Journal is devoted to mobile programming. We introduce you to Apple's new Swift programming language, discuss the perils of being the third-most-popular mobile platform, revisit SQLite on Android
, and much more!