非商业转载请注明做译者、出处,并保留本文的原始连接:http://www.ituring.com.cn/Article/215241程序员
Paul Butcher
一位资深程序员,涉猎普遍,从单片机编码到高级声明式编程无所不精,如今他开办了独立咨询公司Ten Tenths。他曾任SwiftKey的首席软件架构师,并前后担任Texperts和Smartner的CTO。编程
Paul Butcher的著做《七周七并发模型》延续了《七周七语言》的写做风格,经过七个精选的模型帮助读者了解并发领域的轮廓。除《七周七并发模型》外,Paul还著有在亚马逊得到全五星好评的《软件调试修炼之道》。 微信
图灵访谈:感谢Paul再次接受图灵的访谈!您曾经讲过,在1989年开始攻读博士学位的时候,并行计算和分布式计算并非当时的主流。为何不选择当时的主流做为学习研究领域?架构
老实说,当时个人估计略有误差。我当时认为并行计算和分布式计算不久就会成为主流。但实际上,CPU运行不断加快,人们彻底没有必要为了显著提高性能,从串行编程转向并发编程。并发
最近,CPU的运行速度达到了瓶颈,很难再次提高。正由于如此,我当时的预测最终得以实现(离当时的预测已经有25年了)。app
图灵访谈:并发和并行很是类似,二者容易相互混淆。那么二者之间的不一样点有哪些?less
不仅是中国人,对于讲英语的人也同样,并发和并行是一种常见的易混淆概念。其实,大多数状况下,二者的区别不是特别重要,重要的是,从串行编程转向非串行编程,也就是并发和并行编程。并发和并行都属于非串行编程,它们二者面临的挑战也是同样的。dom
并发代码具备多个逻辑的控制线程,但这些线程能够或者没必要运行在多个核上。并行代码则真正运行在多个核上。一般,并行是关乎性能的(经过使用多核,咱们但愿咱们的代码运行得更快),而并发则是关于解决一个自己就是并发的问题域。编程语言
我之因此在《七周七并发模型》中探讨二者的区别,是由于存在一个常见的误解:并行指的是不肯定性。事实却并不是如此。若是咱们为了运行得更快,并行处理一些数值计算,获得的结果跟串行代码的答案彻底同样!分布式
图灵访谈:距离本书的出版日期也有一年多了。是否有其余的并发模型出现?
本书出版的时候,就已经存在超过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.