非商业转载请注明作译者、出处，并保留本文的原始链接：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.
**粗体** _斜体_ [链接](http://example.com) `代码` - 列表 > 引用。你还可以使用@来通知其他用户。