[英文]Paul Butcher: 這是一個激動人心的程式設計時代，也是一個帶有很大不確定性的時代（圖靈訪談）

Paul Butcher
一位資深程式設計師，涉獵廣泛，從微控制器編碼到高階宣告式程式設計無所不精，現在他開辦了獨立諮詢公司Ten Tenths。他曾任SwiftKey的首席軟體架構師，並先後擔任Texperts和Smartner的CTO。

Paul Butcher的著作《七週七併發模型》延續了《七週七語言》的寫作風格，通過七個精選的模型幫助讀者瞭解併發領域的輪廓。除《七週七併發模型》外，Paul還著有在亞馬遜獲得全五星好評的《軟體除錯修煉之道》。

訪談中文版

iTuring: It's our great honor to have the interview with you again! It is said that parallel and distributed computing hasn't been mainstream yet in 1989 when you started PhD. Why don't you choose the mainstream at that time as your study area?

Honestly, I made a mistake. I thought that parallel and distributed computing was about to become mainstream. In fact, what happened is that CPUs continued to get faster, so there was no pressure for people to move away from sequential programming to achieve significant performance improvement.

What’s changed recently, is that CPUs have stopped getting faster. This is why, better late than never, I’ve finally been proved right (only 25 years late).

iTuring: Concurrency and parallelism are very similar to each other, and are often confused with each other. So what's the difference between them?

This is a common confusion, for English speakers as well as Chinese. In many ways, the difference doesn’t really matter—the important move is from sequential to non-sequential programming (both concurrent and parallel programming are non-sequential). The challenges are very similar. Concurrent code has multiple logical threads of control. But those threads may or may not actually be running on more than one core. Parallel code genuinely runs on more than one core. Typically, parallelism is about performance (we want our code to run faster by using more than one core) whereas concurrency is about addressing a problem domain that is itself concurrent.

The reason why I talk about the difference in the book is because there is a common misconception that parallelism implies non-determinism, which it does not. If we are parallelizing some numerical computation because we want it to perform faster, we should still get the same answer as our sequential code gives us!

iTuring: It has been over one year since the book is published. Does the eighth concurrency model appear?

There were already many more than seven models when the book was published! There is a list of some of the ones that we considered for inclusion in the book in the last chapter (Fork/Join and Work-Stealing, Dataflow, Reactive programming, Functional Reactive Programming, Grid Computing and Tuple Spaces). Of these, the most interesting for the future is, I think, Functional Reactive Programming.

iTuring: In the book, each Chapter chooses one proper programming language to introduce one concurrency model. Are there any other study clues, besides programming language?

The reason why we chose a different programming language for each chapter is because we wanted to make the examples as simple and easy to understand as possible. We could have chosen a single language for the whole book (e.g. Java) but if we had done that, the code would have been much more verbose and harder to understand. This is particularly true for the functional programming chapter; although it is possible to write functional code in Java, it is not the natural Java way, and I think it would have been hard to “see the wood for the trees”.

It’s important to understand that you don’t need to use the languages that I’ve used in the book to use the lessons though. If you’re currently a Java programmer, for example, you could easily write Actors code by using the Akka library. Your code will certainly be more verbose than if you used Elixir or Scala, but you can still make use of the Actor programming model.

iTuring: When choosing programming language for specific projects, apart from concurrency models, what other features will you take in consideration?

There are many features that need to be considered, many of them practical and pragmatic, for example:

• What existing code do you have that you will need to interoperate with?
• How good are the supporting tools?
• How active is the community around the language?
• …

The other thing that makes it complicated at the moment is that there are lots of different programming languages competing for popularity, and it’s difficult to be sure which will be popular in the future.

We are at a very exciting time in programming, but also one that comes with a lot of uncertainty.

iTuring: What impacts does programming language revolution have on developers?

As I said in my answer to the previous question, it is very difficult to predict which of the many different programming languages currently competing with each other will be popular in the future. This makes it very challenging for today’s developers.

Having said that, there are some clear trends, I think; Functional programming will be increasingly important, as will concurrency, distributed programming and fault tolerance.

The only solution to this is to keep learning. Pick a new language to learn. Then pick another :-). And make sure that at least one of those languages has a strong functional flavor.

iTuring: In our last interview, you said, “Polyglot programs are challenging at the best of times, and introducing different concurrency models only makes them more so.” Is there any possibility to combine the best parts of all programming languages to create a kind of universal language with omnipotent concurrency model?

The one “true” language is the programmer’s equivalent of the Holy Grail. There have been many attempts to create a single language that will address everyone’s needs, and they’ve never been successful.

Scala is a multi-paradigm language that allows many different programming styles (imperative, object oriented, functional, actors, …) and, while it works, many people find it too complicated to learn and use.

Personally, I’m a fan of simpler, more tightly-focused languages which do one thing well.

iTuring: From my point of view, programmers' coding is, to some extent, similar to book authors' writing. Since you have experienced both of them, could you tell us the similarities and differences?

That’s a really interesting question! Yes, there are definitely some similarities, for me at least. My approach to both writing and coding is that I start by just writing something. It will be too long, and messy, and probably won’t convey what I intend very well. But then I read it and review it and gradually, over time, work it into a form that I’m happy with.

Of course, one big difference between writing and coding is that when I’m coding I can write tests. If my tests pass, I can be reasonably sure that my code is correct. Unfortunately, there’s no equivalent of automated tests for writing. The only option is to give what I’ve written to someone and see if they understand it.

iTuring: Both Debug it! and SCMSW have received a great amount of popularity in Chinese readers. Have you planned to write another book?

I have some very early stage plans for a couple of books, but they are just ideas at the moment. Probably, I'd love to write books on consultancy for startups and investors, by help them build a development team, put an appropriate development process in place and define an appropriate architecture.

iTuring: Recently, you've been keen on motor racing. I've even heard that you got a 3rd place finish in the first race of the season last week. So, why do you love motor racing pretty much? Does it inspire a kind of mental model into you or train your ability?

I would love to say that there is a connection between motor racing and software engineering, but honestly, the only connection is that being a software engineer allows me to earn enough money to pay for motor racing.

---

更多精彩，加入圖靈訪談微信！