原文:[url=http://www.thinkingparallel.com/2007/03/20/ten-questions-with-joe-armstrong-about-parallel-programming-and-erlang/]Ten Questions with Joe Armstrong about Parallel Programming and Erlang[/url]
第一部分:关于并行编程的通用问题
1)
Michael:我们进入了多核时代,你认为并行计算最终会成为主流吗?或者这仅仅是一个阶段并且很快对并行编程感兴趣的人将(又一次)变成高性能社区的一员?
Joe:是的,绝对主流——我们讨论的是双核时性能提高两倍而4核时性能提高4倍。我曾经有一个在32核的机器上跑的程序,性能提高了18倍。注意这是18倍——我们习惯于通过重写部分程序代码来提高5%~10%的性能,却想不到400%或1800%——这是所有软件的通病。
2)
Michael:在网络上,一时间对共享内存编程还是消息传递编程是并行编程更好的方式展开了激烈的讨论。对此你的意见是什么?
Joe:共享内存系统很难理解并保证正确,特别是当错误出现的时候。不出错就不错了,当出错时则根本无法继续搞。当一个程序拿了一个锁,并且把共享内存搞的乱七八糟,然后崩溃了,其他进程怎么知道它到底在搞什么东东,更别说帮忙搞定那些错误了。
事务内存和纯净的消息传递系统不用考虑上述的任何问题。
3)
Michael:对你而言,并行编程在目前或者过去的几年里最令人兴奋的发展和革新是什么?
Joe:P2P架构,分布式哈希表,planet lab等全球伸缩的系统集成。
类似于bit torrent的东西正在摧毁传统工业,就像1770年多轴纺织机摧毁了家庭纺织机工业一样,bit torrent正在历史记录上做同样的事情。这不是是否发生的问题,而是何时发生的问题。
4)
Michael:并行编程的未来在哪里?“银弹”即将到来吗?
Joe:是的——纯净的消息传递基础架构将解决很多问题(例如amazon简单查询服务)。这回到了Paul Morisson的基于流的编程模型。
5)
Michael:目前最紧迫的一个问题是并行编程仍然很难,并且没有它的顺序编程对手们高产。对你而言有什么方式改变这一点吗?
Joe:这并不太难——这很难是因为目前占据统治地位的编程模型是锁、线程和共享内存——现在它们是很难的。纯净的消息传递系统对编程实现和推理很容易。
世界是并行的——我们是并行的。
第二部分:关于Erlang
6)
Michael:与其他并行编程系统相比较,Erlang有什么独特的优势和弱点?你希望在哪些方向改进它?
Joe:优势是Erlang是为容错系统而设计的,所以在软件和硬件出错时它能很好的降级。它认真对待出错。进程和错误处理是语言定义的一部分而不是操作系统所提供的。
弱点是分布式Erlang的安全性是要么全有要么全无的。拥有不同级别的安全性和能力或者基于信任的安全模型会更好。
7)
Michael:如果你可以再次从零开始设计Erlang,你会做哪些不同的事情?
Joe:
1,让模块和代码处理更高级一些,添加自省功能
2,为协议的断言属性添加一层契约
3,在编程语言里让协议成为头等公民
4,为分布式计算加一个信任/能力层
5,为弱连接的分布式系统分层。分布式Erlang只是为了拥有强大安全性的类集群计算。
8)
Michael:有没有什么特殊的工具推荐给大家来方便Erlang编程?IDE?编辑器?调试器?调优器?改错工具?或其他什么的?
Joe:没有。编译器独自拥有95%的fun。这样人们对他们的IDE十分笃信。我使用emacs和xterm。有些人热衷于一些东西,但我本人不怎么感兴趣。
9)
Michael:请给Erlang新手们分享一些小建议!你该怎么入门?有什么书?教程?网络资源?提问最好的地方在哪里?
Joe:
书籍——(无耻的插入):读我的新书Programming Erlang。
教程:www.trapexit.org
发布:www.erlang.org
提问:erlang邮件列表(登录www.erlang.org)
10)
Michael:你在Erlang程序里遇到的最糟糕的错误是什么?
Joe:没有文档的程序——我讨厌人们说“读代码”——代码是问题的解决方案——通过读代码我不得不猜测问题是什么,并且这很可能出错。我喜欢别人告诉我问题是什么,而不是靠猜。
所以最糟糕的错误是当我写在程序里一个长达多页的注释来解释一些特殊的技巧点时,结果发现在稍后的版本中别人删除了整个注释。
第一部分:关于并行编程的通用问题
1)
Michael:我们进入了多核时代,你认为并行计算最终会成为主流吗?或者这仅仅是一个阶段并且很快对并行编程感兴趣的人将(又一次)变成高性能社区的一员?
Joe:是的,绝对主流——我们讨论的是双核时性能提高两倍而4核时性能提高4倍。我曾经有一个在32核的机器上跑的程序,性能提高了18倍。注意这是18倍——我们习惯于通过重写部分程序代码来提高5%~10%的性能,却想不到400%或1800%——这是所有软件的通病。
2)
Michael:在网络上,一时间对共享内存编程还是消息传递编程是并行编程更好的方式展开了激烈的讨论。对此你的意见是什么?
Joe:共享内存系统很难理解并保证正确,特别是当错误出现的时候。不出错就不错了,当出错时则根本无法继续搞。当一个程序拿了一个锁,并且把共享内存搞的乱七八糟,然后崩溃了,其他进程怎么知道它到底在搞什么东东,更别说帮忙搞定那些错误了。
事务内存和纯净的消息传递系统不用考虑上述的任何问题。
3)
Michael:对你而言,并行编程在目前或者过去的几年里最令人兴奋的发展和革新是什么?
Joe:P2P架构,分布式哈希表,planet lab等全球伸缩的系统集成。
类似于bit torrent的东西正在摧毁传统工业,就像1770年多轴纺织机摧毁了家庭纺织机工业一样,bit torrent正在历史记录上做同样的事情。这不是是否发生的问题,而是何时发生的问题。
4)
Michael:并行编程的未来在哪里?“银弹”即将到来吗?
Joe:是的——纯净的消息传递基础架构将解决很多问题(例如amazon简单查询服务)。这回到了Paul Morisson的基于流的编程模型。
5)
Michael:目前最紧迫的一个问题是并行编程仍然很难,并且没有它的顺序编程对手们高产。对你而言有什么方式改变这一点吗?
Joe:这并不太难——这很难是因为目前占据统治地位的编程模型是锁、线程和共享内存——现在它们是很难的。纯净的消息传递系统对编程实现和推理很容易。
世界是并行的——我们是并行的。
第二部分:关于Erlang
6)
Michael:与其他并行编程系统相比较,Erlang有什么独特的优势和弱点?你希望在哪些方向改进它?
Joe:优势是Erlang是为容错系统而设计的,所以在软件和硬件出错时它能很好的降级。它认真对待出错。进程和错误处理是语言定义的一部分而不是操作系统所提供的。
弱点是分布式Erlang的安全性是要么全有要么全无的。拥有不同级别的安全性和能力或者基于信任的安全模型会更好。
7)
Michael:如果你可以再次从零开始设计Erlang,你会做哪些不同的事情?
Joe:
1,让模块和代码处理更高级一些,添加自省功能
2,为协议的断言属性添加一层契约
3,在编程语言里让协议成为头等公民
4,为分布式计算加一个信任/能力层
5,为弱连接的分布式系统分层。分布式Erlang只是为了拥有强大安全性的类集群计算。
8)
Michael:有没有什么特殊的工具推荐给大家来方便Erlang编程?IDE?编辑器?调试器?调优器?改错工具?或其他什么的?
Joe:没有。编译器独自拥有95%的fun。这样人们对他们的IDE十分笃信。我使用emacs和xterm。有些人热衷于一些东西,但我本人不怎么感兴趣。
9)
Michael:请给Erlang新手们分享一些小建议!你该怎么入门?有什么书?教程?网络资源?提问最好的地方在哪里?
Joe:
书籍——(无耻的插入):读我的新书Programming Erlang。
教程:www.trapexit.org
发布:www.erlang.org
提问:erlang邮件列表(登录www.erlang.org)
10)
Michael:你在Erlang程序里遇到的最糟糕的错误是什么?
Joe:没有文档的程序——我讨厌人们说“读代码”——代码是问题的解决方案——通过读代码我不得不猜测问题是什么,并且这很可能出错。我喜欢别人告诉我问题是什么,而不是靠猜。
所以最糟糕的错误是当我写在程序里一个长达多页的注释来解释一些特殊的技巧点时,结果发现在稍后的版本中别人删除了整个注释。