《七週七併發模型》做者Paul Butcher：這是一個激動人心的編程時代，也是一個帶有很大不肯定性的時代

非商業轉載請註明做譯者、出處，並保留本文的原始連接：http://www.ituring.com.cn/Article/215241

Paul Butcher
一位資深程序員，涉獵普遍，從單片機編碼到高級聲明式編程無所不精，如今他開辦了獨立諮詢公司Ten Tenths。他曾任SwiftKey的首席軟件架構師，並前後擔任Texperts和Smartner的CTO。

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

圖靈訪談：感謝Paul再次接受圖靈的訪談！您曾經講過，在1989年開始攻讀博士學位的時候，並行計算和分佈式計算並非當時的主流。爲何不選擇當時的主流做爲學習研究領域？

老實說，當時個人估計略有誤差。我當時認爲並行計算和分佈式計算不久就會成爲主流。但實際上，CPU運行不斷加快，人們徹底沒有必要爲了顯著提高性能，從串行編程轉向併發編程。

最近，CPU的運行速度達到了瓶頸，很難再次提高。正由於如此，我當時的預測最終得以實現（離當時的預測已經有25年了）。

圖靈訪談：併發和並行很是類似，二者容易相互混淆。那麼二者之間的不一樣點有哪些？

不僅是中國人，對於講英語的人也同樣，併發和並行是一種常見的易混淆概念。其實，大多數狀況下，二者的區別不是特別重要，重要的是，從串行編程轉向非串行編程，也就是併發和並行編程。併發和並行都屬於非串行編程，它們二者面臨的挑戰也是同樣的。

併發代碼具備多個邏輯的控制線程，但這些線程能夠或者沒必要運行在多個核上。並行代碼則真正運行在多個核上。一般，並行是關乎性能的（經過使用多核，咱們但願咱們的代碼運行得更快），而併發則是關於解決一個自己就是併發的問題域。

我之因此在《七週七併發模型》中探討二者的區別，是由於存在一個常見的誤解：並行指的是不肯定性。事實卻並不是如此。若是咱們爲了運行得更快，並行處理一些數值計算，獲得的結果跟串行代碼的答案徹底同樣！

圖靈訪談：距離本書的出版日期也有一年多了。是否有其餘的併發模型出現？

本書出版的時候，就已經存在超過7種的併發模型了！《七週七併發模型》的最後一章也列出了其餘的併發模型，如Fork/Join 和work-stealing、數據流、響應式編程、函數式響應編程、網格計算和元組空間。其中，最有趣的，我認爲是函數式響應編程。

圖靈訪談：書中的每一章都選用了恰當的編程語言來展現併發模型。除了編程語言這條線索，是否還有其餘線索來學習併發模型？

爲每一章選擇不一樣的編程語言，是爲了儘量地下降讀者對示例的理解難度。整本書也能夠只選擇一種語言，好比Java，但這樣作的後果是，代碼將變得囉嗦冗長，讀者也更難理解。這一點尤爲適用於函數編程那一章。儘管咱們能夠用Java編寫函數代碼，但這並非Java的常見編寫方式。這樣很容易一葉障目，只見樹木不見森林。

重要的是要明白，你並不須要使用本書中使用的所有語言。若是你目前是一名Java程序員，你也可使用Akka庫輕鬆地編寫Actor代碼，但你的代碼確定會比使用Elixir或者Scala 更加繁瑣。由於你能夠運用Elixir和Scala裏面的Actor 編程模型。

圖靈訪談：在選取編程語言的時候，除了考慮編程語言的併發特性，還須要關注哪些其餘的特性？

還有許多特性須要考慮，大多數還特別實用，例如：

•現有的代碼有哪些，能夠用於以後的互操做？

•支持工具怎麼樣？

•該語言社區的活躍度怎麼樣？

•…...

不一樣編程語言之間的相互競爭，讓語言選取變得更加複雜。並且，目前很難預測出哪一種語言將來會受歡迎。

咱們正處於一個很是激動人心的編程時代，但也是一個帶有很大不肯定性的時代。

圖靈訪談：編程語言變革對程序開發者的影響有哪些？

就像我在上一個問題的回答同樣，咱們很難預測究竟哪一種語言會變成主流語言。這對於程序開發人員來講，確實是一種嚴峻的挑戰。

儘管如此，我認爲仍是有一些明確的趨勢的。函數式編程語言將愈來愈重要，併發、分佈式編程和容錯性良好的語言一樣愈來愈受到青睞。

惟一的解決辦法就是繼續學習。選擇一門新語言進行學習，而後選擇另一門，至少確保一門語言有很強的函數式語言韻味。

圖靈訪談：上次接受圖靈訪談的時候，您曾經說：「採用多語言編寫的程序自己就頗有挑戰性，若是再引入多種併發模型，狀況會變得更糟。」有沒有可能建立一種廣泛適用的編程語言和一種萬能的併發模型？

建立一種「真正的」編程語言，是全部程序員努力追求的「聖盃」，但卻很難實現。有許多嘗試試圖建立一種語言，來知足每一個人的需求，但他們歷來都沒有成功。

Scala是一種多範型的語言，容許不少不一樣的編程風格，好比命令式、面向對象式、函數式、Actor......雖然能夠運做，許多人認爲學習和使用Scala太過複雜。

就我我的而言，我喜歡更簡單、更集中的語言，一次作好一件事。

圖靈訪談：從個人角度看，編寫代碼跟寫做在必定程度上很是類似。既然這兩種您都經歷過，能夠給咱們分享下二者之間的相同點和不一樣點嗎？

這是一個很是有趣的問題！是的，至少對於我來講，編寫代碼和寫書二者之間有一些相同之處。無論是寫書仍是編寫代碼，最開始我只是大膽地寫出「東西」。它們可能特別冗長、混亂，甚至不能表達出我想要表達的意思。可是，經過反覆地閱讀、檢查，慢慢地我會找到本身最滿意的結果。

固然，寫做和編碼之間最大的區別在於，我能夠用本身編寫的測試對代碼進行驗證。若是測試經過，我有充分的理由認爲代碼的正確性。不過，寫做卻沒有對應的自動化測試。我只能把本身編寫的文本拿給別人審閱，看是否能被他們所理解。

圖靈訪談：《軟件調試修煉之道》和《七週七併發模型》兩本書都受到了讀者的追捧，您是否有計劃再寫一本書？

我有計劃再寫幾本書，但計劃還處於很是早期的階段。多是關於創業者和投資者的建議諮詢類圖書，幫助他們構建開發團隊，落實開發過程和合適的體系結構。

圖靈訪談：據說您最近一段時間癡迷於賽車。在上週的一次季賽中，還得到了第3名的好成績。如此喜好賽車的緣由是什麼？這項運動有沒有激發您某種思惟模式或者鍛鍊了某些能力？

我真的但願說，賽車跟軟件編程之間存在必定的聯繫。但實際上，它們之間惟一的聯繫，就是軟件工程師的工做讓我賺到足夠的錢來支付賽車方面的花銷。

Paul在 2016年Qcon北京大會 作了精彩的演講，歡迎到視頻下載區下載欣賞。

英文版訪談
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.

---

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