Behind the scenes with the author of Seven Languages in Seven Weeks.
In Seven Languages in Seven Weeks, Bruce Tate took on an audacious goal: to take readers on a meaningful exploration of seven languages within the pages of a single book. His plan was to dive down to what’s essential and unique about each language, and in the process maybe even uncover some insights about how to learn any new language.
Bruce wasn’t interested in just giving readers a flavor of each language, I knew. He was going to ask a lot of his readers, and intended to reward their efforts with a deep understanding of each of the languages through useful hands-on experience in coding. The project seemed so outrageous that I decided I had to talk with him about the writing of the book. I wanted to know why he took on this challenge, surely one of the hardest writing challenges this award-winning writer has ever attempted. And I wanted to ask him why he chose the languages he did, how he approached each language differently to get at its unique strengths and style, and what he himself learned from taking on this challenge.
I found what he had to say fascinating, and I hope you do, too.
ms: Chef Tate, what was your inspiration for today’s battle? (Sorry; I was channeling the Chairman from “Iron Chef” for a minute there.) Make that: what inspired you to write this book?
ms: Chad Fowler once said, “The best reason to learn a new programming language is to learn to think differently.” Did you also have something like that in mind?
bt: I firmly believe that we expand our minds by exposing them to different ideas. The ultimate exercise for someone learning about the world is learning new spoken languages. Learning a new programming language does very much the same thing. The whole exercise shapes the way you think, and in the very best ways. Learning Haskell will make me rely less on mutable variables, learning Erlang will increase my interest in better messaging and monitoring, and learning Prolog will open my eyes to rules-based logic constraint problem solving, a very important set of programming strategies that I never knew existed.
It’s just a great exercise. The only question to me was whether I had enough knowledge to pull it off.
ms: It is as though you chose to write seven books.
bt: I decided early on to lean hard on the community around me, and I am liking the result so far.
ms: It does seem like an ideal book for the Prags Beta book program, letting you draw on the full range of programming knowledge among the readers. How did you select the languages to cover? Didn’t you also involve the community in that part of the project?
bt: I started with a good idea about three or four languages in the book. I picked Ruby because I wanted an object-oriented language that’s easy to learn so I’d have a common basis to compare the other languages to. I then threw out a vote to my audience with the help of the Prags. (Ruby was the one on top.) I picked the top ones, with a few exceptions.
So I wound up with four different programming paradigms. Ruby is object-oriented, Prolog is logic-based, Io is a prototype language, and the last four are functional languages. I had a mix of very dynamic typing (Io, Ruby, etc.) and static typing (Scala and Haskell). I had languages spanning five decades, sort of. Clojure is a Lisp dialect, with roots in the 1950s, Prolog was created in the 1970s, Erlang’s first version was, I think, in 1986. Haskell’s 1.0 version was in the 1990s, as was Ruby. Io and Scala were both invented in this decade.
And buried in that pile are seven distinct languages with vastly different idioms and philosophies. I’m pleased with the mix, but I have to give the credit to the Prags readers who answered the polls.
ms: So you had your seven languages, and all you had to do was discover and communicate the essence of each one. What was your thought process in deciding how to approach this monumental job of introducing readers to seven very different languages? In fact, what was the process?
bt: It wasn’t easy. Languages have personalities, and I found that I needed to quickly change the mindset of a reader from one language to another. I compared each language to a pop culture movie character. Erlang is Agent Smith from The Matrix, Ruby is Mary Poppins (a spoonful of sugar). I know that sort of thing is not for every reader, but an author has to have a voice and have fun in the process of writing. And there were also two major concerns.
The biggest decisions were whether to have seven days of focused instruction or less, and how much work to do on installation and support. For the first problem, I had intended to do five days of instruction. That was wholly impractical. I found that I needed unfocused play time to let concepts jell, and I bet my readers will too.
ms: And what about support?
bt: I decided that I was not capable of supporting installation across all of the languages, and the most recent versions, on all of the platforms supported by my readers. I feel slightly guilty about that, but it was the only practical solution.
ms: OK, then what?
bt: The next decision was how deep I should dive. That’s a dance. For most chapters, I initially bit off too much. With Prolog, I tried to build a scheduler, and Joe Armstrong, creator of Erlang, talked me off of that ledge. In Clojure, I wanted to create a queuing system, but Stuart Halloway guided me in a different direction, after he finished laughing, I’m sure. And in Io, I didn’t dive deep enough for the concurrency problems. Steve DeKorte, inventor of the language, shared some examples with me.
ms: You also went to the developers of many of the languages for interviews. Personally, I find that the interviews add to my understanding of the languages, but what was your thinking in including interviews?
bt: I wanted to lend some credibility to the book that I couldn’t provide, and some insight from the designers of the various languages. I’m humbled to have people responsible for creating six of the seven languages discuss the features they like the best and the least, and give us the true inside scoop.
Of course, my biggest fear is that my novice code in these languages will stand out for the wrong reasons. I can only hope that my great support network of reviewers, editors, and sounding boards will keep some of those mistakes to a minimum.
ms: Let’s talk about the languages. What did you want the reader to take away from the Ruby chapter?
bt: The Ruby chapter was interesting for two reasons. First, there are a ton of people who know the language, and know it well. Second, few people can push Ruby through all of its paces. I tried to use Ruby as a basis for comparison for the other languages in the book. And of course, it was great to interview Matz. I was at a conference in Japan where he was the chair, and we got to talk at one of the events that the conference had planned for the speakers. I asked him to do an interview for the book then, and he agreed. We finally completed the interview over email. He’s a wise man, and he’s achieved an amazing balance as a steward of the language. I’m working on Haskell right now, but you can code a monad in Ruby. And the syntax of the language is just beautiful to me. Ruby is still my chosen language, and long after I've eventually moved on, I’ll always remember Ruby fondly.
ms: A lot of programmers today know Ruby, so I can see why you started with it. How was the experience of writing about a lesser-known language like Io?
bt: Lesser-known is right. Io is probably the least-known language in the book. I approached Jeremy Tregunna about getting rolling with Io, because it wasn’t compiling on Snow Leopard at the time. He quickly shuttled me to Steve Dekorte, Io’s inventor. We spent, I think, a Friday evening messaging back and forth until he was able to help me limp through a Snow Leopard installation. He also reviewed the Io chapter, and had some great ideas for improving it.
But the main thing I want to say about Io is that it is fun. Steve is a wise man, for such a young language designer. I’d call Io the Lisp of the prototype languages. There’s barely any syntax; the messaging model is perfect, with evaluation at the right time; the syntax and semantics are all wide open. You can do anything with it that you want. And the concurrency is right. Sometimes great languages make it and sometimes they don’t. I’m not sure that Io will make it, but it’s a special language, and learning it made me smarter.
ms: What language gave you the most trouble?
bt: That would have to be Scala, but not because it’s poorly designed. Scala probably embraces Java better than any other language in the book. I had a hard time with the strong, static typing. It didn’t feel quite right to me. But boy, could I see the power. Scala makes it easy for Java programmers to do the right thing. The actor model is a much stronger model than Java’s basic concurrency model. Also, the focus on immutability is a much-needed step in the right direction.
ms: Did Prolog give you trouble too?
bt: It did at first, for sure. I have to admit, I can’t really take the credit for including the Prolog chapter, or how well the chapter turned out. In the first writing, I missed many of the most critical concepts in Prolog. Joe Armstrong is a huge fan of Prolog, and used it to implement some of the earliest Erlang prototypes. He really took me under his wing and helped me understand the beauty of the language. I finally had what Joe calls a Prolog moment. I described the rules of a Sudoku, and out pops the solution. I had to ask myself, where’s the program?
ms: The Prolog moment. I know what you mean. The moment when you realize that coding in Prolog is all about formulating the question, and if you do that right, the answer just falls out.
bt: It was a cool moment. Since then, I’ve recalled dozens of problems that took me weeks that I could have done in Prolog in a day or less. It’s an amazing language.
ms: I have to say I share your respect for Joe Armstrong. Why did you pick him to write the foreword?
bt: He is such a rational thinker. I mean, everyone else was saying that objects would help your programs be more readable. Joe was thinking about the side effects and mutable state. Everyone else was saying that great reliability has to start with strong, static typing. Joe made Erlang dynamically typed. In an Erlang program, when bad problems happen, you just let it crash and start a new one, letting the excellent monitoring and isolation due to functional programming principles kick in. His ideas were just ahead of their time. Now, we’re realizing a lot of the ideas he’s been promoting for a very long time. When you need scalable, distributed, fault-tolerant systems, Erlang has something to teach you.
ms: You picked Clojure from all the other Lisp variants. What makes Clojure special?
bt: Three main things. First, it’s taken some of the classical Lisp lessons to heart. There are too many parentheses in Lisp, so Clojure replaces some of them syntactically with brackets and makes some others optional. Little things like that help.
Second, Clojure is on the JVM, and embraces Java classes. That’s a huge benefit. You have access to the many libraries that the Java platform provides.
Third, Clojure gets concurrency right. The STM is brilliant, really brilliant. Software Transactional Memory takes the same approach that many of the best databases use, and applies it to each memory access. You get concurrency without blocking, and that can lead to huge performance boosts, and much more reliable software systems, with very little cost.
ms: Which brings us to Haskell. Here’s the question you’ve dreaded. Can you explain monads?
bt: No, of course not. But I’m going to try.
Seriously, Haskell is so powerful and rich that it is hard to do it justice. I think the Haskell chapter is the second longest in the book, and I could easily have made it longer. Monads are the tool Haskell uses to capture some important concepts, like how to manage input/output in a language that does not support side effects. The concepts are extremely abstract. I’m still struggling with how to get that right. So the language makes some easy things hard.
But Haskell also makes some hard things very, very easy. The type system is amazing. Everything is inferred. If I had a type system like this on many of the statically typed languages that bugged me, I think I would enjoy them more.
ms: OK, that’s seven. So you took on this challenge of writing about these seven languages and now you’re nearly finished. What would you say you’ve learned in the process of writing this book?
bt: Mostly, I’ve learned that I don’t know very much at all. But the best experience of writing this book has been meeting all of the cool people. Talking to both the readers of the book and the language inventors has been an absolute blast.
ms: Well, it’s been a pleasure talking with you, Bruce. Thanks for your time.
bt: My pleasure!
Bruce Tate is a kayaker, mountain biker, and father of two from Austin, Texas. An international speaker and prolific author, Bruce’s primary focus through the years has remained steady: rapid development of web applications with small, effective teams. He is the chief architect behind several commercial websites including changingthepresent.org, classwish.org, and most recently, digthedirt.com. His books through the years have included the Jolt-winning Better, Faster, Lighter Java and the controversial Beyond Java. He is also the author of From Java to Ruby.