我们在RubyCon 2013遇到了Dave Thomas。作为一位开发者,他充满了热情,他相信这是个属于勇敢者的时代。对于业界存在的问题,他痛心疾首,并不断寻求着解决方法。作为一位出版人,他务实、精明,时刻为自己的作者着想,也为像他一样的开发者搜罗好书。他是一位不折不扣的Pragmatic Programmer。

Dave Thomas是一位程序员,同时也是一位作者和出版人。他和Andy Hunt一起开办了出版公司The Pragmatic Bookshelf,他们整个线上业务都是他和Andy用Ruby创建的。他的个人作品包括《Web开发敏捷之道》、《Programming Ruby》。他和Andy共同写作了《程序员修炼之道》,这本书也是The Pragmatic Bookshelf品牌下的第一本书。

你用Ruby干什么?你是如何参与Ruby社区的?

Dave:在过去的8年中,我用Ruby做所有的事!我们整个的线上业务都是用Ruby写的。如果你成为我们的作者,我们用来形成一本书的软件也是用Ruby写的。所以可以说Ruby就是我们公司的全部。另外,我几乎每天都会写Ruby脚本,这是我生活的一大享受。我的记性很差,如果我生活中能找到任何可以自动化的步骤,我一定会把它自动化,这样我的生活就会更加简单。

在开始的时候Ruby社区人很少,第一次聚会的时候大概只有30人。所以参与这么小的社区其实只是和朋友打交道而已。说到开源社区的贡献,我大概写了有4、5千行代码,有一些文档,也提交了一些补丁。另外,我经常参与Ruby大会,并且乐在其中。

你对其他Rubyist有什么建议?你对对Ruby这门语言感兴趣的人有什么建议?

Dave:好问题!我最大的建议就是参与进来。这就意味着找到一个你需要做的事,每个人都可以做到,不是非要是个编程大牛才可以。只要找到一个小bug或者你使用的库没有做你希望的事情,那你就可以做一个新版本出来,或者把补丁发给作者。如果有一些功能完全不存在,那么不要只是做出来给自己用,打个包发布给大家。如果这么做的话,你就是社区的一员了。这种回馈不仅会让你感觉很好,也会帮助其他人。同样,这么做也会帮到你自己,因为你有了名誉和声望,你在社区中也有了自己的位置。

你是怎么成功地作为程序员、作者、出版者工作的?这些东西占据的比例是怎么样的?

Dave:我睡得不多(笑)。作为一个出版人,我的团队非常出色。首先,我们都要感谢自动化,我们可能是世界上自动化程度最高的出版公司。我们整个公司没有一张电子表,这些都要归功于Ruby。比如我知道很多出版商如果要发布一本书的新版本的话,需要在之前工作一两天的时间,而我们只需要……大概5秒钟。自动化是关键点之一,通过高度自动化,我就有了更多空余时间。另外有很多杰出的人才和我们一起工作,他们工作得比我好。我很幸运,他们可以帮我完成很多工作,所以我有时间空余出来。虽然有一些我必须做的事,但是大部分时间我可以做我喜欢做的。也就是去了解新的科技,和有趣的人交谈,继续探索,说实话……这种生活真的很享受!

我们没有办公室,每个人都在家工作。所以我早上起床之后,查查邮件,遛遛狗,回来再做事……所有事都是生活的一部分,所以我不用把我的时间分割成8小时工作和下班。其实我每天的工作时间多于8小时,但是事情都是分布在各种时间段里,所以感觉起来不像是在工作。当天气晴好的时候,我可以坐在外面边晒太阳,边打字,这样的感觉很好。

作为一个出版人,你怎么策划出下一个选题?

Dave:有两个问题,第一个是需要知道接下来什么才是最有趣的技术;第二个是找到合适的了解这门技术的人来写作。

要想知道什么技术会大放异彩的关键就是要和正确的人对话。我有一条原则,如果我在一个礼拜内听到某种新技术两次,那这种技术就会进入我的候选名单中。每周我们都会召集我们所有的编辑开一次会,我们在会上会讨论这些话题。这时候可能就会有某个编辑说,嘿,刚巧我认识一个这方面的人。否则,我们就得出去找人了。这可真是个问题,因为知道这些技术的人还刚巧都是些大忙人,他们都在自己的项目上忙着呢。所以,为了减轻他们写书的痛苦,让他们的工作更加简化,我们提供了一些工具。如果你是一位开发者,使用这些工具是很自然的事。但无论如何,写书都是一项艰难的工作。

现在很多书都在教人如何制作自己的编程语言,操作系统,这样的DIY项目似乎也不是大牛的专利,比过去更加容易实现了,你对想做这些的程序员有什么建议吗?

Dave:每个人到了一个时期,都会看着某个项目或者技术说:我能做得比他好。这种可能确实存在,但是90%的可能是,他们做不到。因为他们没有理解到这个项目或技术后面的细节以及微妙之处。对于那些可以做到的人,很多人都花上一年的时间,根据某些已有的项目重新实现某些功能。这个项目可能会变好……5%,但我所看到的是,他们在别人的想法上花了一年的生命,而这种提升只是边边角角的。倒不如把这一年的时间花在实现自己的想法上,这样做的话你可能会失败,但是你学到的东西会多得多!如果你没有失败,那你就创造出了一种全新的东西,这是让人兴奋的。

你想做自己的编程语言吗?如果你愿意的话,当然可以。但是现实是,这门语言很有可能不会大受欢迎。因为有很多人在这么做,而且你成功与否不仅在于技术能力,更要靠运气。如果我想贡献自己的代码的话,我不会这么做。因为从我的经验来看,我每年都会又一次坐在那里勾勒自己的语言,然后我想起来这句话:不要这么干!然后我就会放弃掉。

做自己的语言或操作系统变得更简单了吗?是也不是。可能更难了。创造这些的工具确实是更好了,我们对于技术的了解也更多了。你可以把你的语言放在JVM上。但是人们对于编程语言的期待也更高了,所以实现起来很困难。所以如果你想投入大把精力在某件事上,我不建议你去发明一种语言,这样做的风险很高。

作为一个出版者,你对于这些自建项目的书也不感兴趣吧?

Dave:我们每个礼拜大概都会收到两个这样的提案。他们会说我们做了一种全新的语言或者框架,关于这个项目我想写一本书。我们管这些书叫做“我充实的暑假”。一门受欢迎的语言至少需要你花半个月的时间把它发布出来,然后需要至少有50-100个积极参与者。一门语言至少需要这些启动力,才有可能变得被大众接受。如果只有你和你的爱犬喜欢这个项目,那你就还差得很多。为这样的项目写书,不会让它变得更好,只会浪费你又一年的时间。美国有一句谚语叫做:“good money after bad”(陪了夫人又折兵)。所以我们一般不会做个人项目的选题,这样对于出版社和作者都是一种伤害,尤其是对作者。

Ruby和移动开发结合比较热门,松本行弘本人也专注去做mruby了。请问对Ruby与移动开发的前景有什么看法,需要逾越那些障碍?

Dave:对于移动方面的开发最大的挑战就是没人知道怎么去做。但是没关系,因为我们在不断努力尝试,犯错误,然后从中学习。我认为移动不是重要的,而是唯一至关重要的开发。它并不只是手机,而是分布网络下的各种东西。人们讨论的因特网一样的连接,我认为这种实现的到来会比我们期待的更快。所以我们要找到一种编写系统的办法,这种办法可以支持成千上万处理器,它们出现在各种地方,进进出出,然后把他们整合到一起,在需要的时候还可以拆分开来。比如当我走入一个房间,然后我的手机,或者设备就开始和这个房间对话,它会告诉我需要知道的信息。我认为这将在不远的未来就可以实现。

在这样的未来中,Ruby的领域在哪里呢?松本在做mruby,这是一种模块化设计语言,所以你可以选择你需要的功能。你可以选择运行,或者把它变得更加轻量。我昨天和他通话时谈到了mruby,他说有一家公司在使用mruby做他们的渲染器,他们把它设置成有45kb的内存印迹,这真是难以置信。这就是Ruby应该发展的领域吗?我不确定。Ruby最开始应用的领域是比刚才所说的退一步的地方,也就是设备之间的接口。所有设备只是骨架上的皮肉。回归这样的位置也许更好,我希望Ruby可以从一种杰出的Web开发语言的定位上移开。它并不只是一种Web开发语言,不能因为rails很红就说它只属于Web开发。Ruby并没有改变!它只是用来写Web应用很顺手而已。我觉得Web应用在未来可能会降温,所以我也希望Ruby可以回归本源,并且与时俱进。

pragprog.com前段时间出版了ruby motion的电子书,之后是否有更多类似题材的选题可以先透露一下。

Dave:还有很多。我们其实很自私,我们只出版自己感兴趣的书!对于和我们所做的其他事相关的话题一般都很感兴趣。ruby motion很有趣,我也想出一本mruby的书。我们不仅关注语言,也很关注语言的不同用法。我们这方面的书还不够多,我很期待有人能够提供Ruby,Erlang等等这些语言的成功用例。这些话题总是很有意思。

你从事开放出版很长时间了,你能介绍一下你的经验,和开放出版在当下的现状吗?

Dave:我们写书的方式和其他出版商不同。大部分出版社会对作者说,第一章应该在3个月内完成,第二、第三、第四章要在……所以作者们写完一章就继续写下一章。这样真是荒缪极了。根据我们的经验,当你写书时(尤其是第一次写书时),你其实不知道书的整体结构会是怎么样的。所以你经常会写下一些东西,然后发现它不应该出现在现在的位置上。所以我们不会一章一章的写作,而是让作者把主要内容写出来,然后我们的编辑会和作者一起来为书梳理架构。所以我们不会说“这是本书的前五章”,我们会说“这是本书50%或60%的内容,也许真实出版后的顺序会大不一样,但这些都是书中的内容”。所以当一本书达到50-60%的时候,编辑同意的话我们就会把这本书发布出来作为一本beta书。从我的观点来看,这是很容易做到的,只要按下发布按钮就可以了。之所以我们需要编辑同意,是因为通常我们会期待这本书每两三个月就有一次更新,在书出版之前,作者还有更多内容要放进来。

这样做的好处就是,首先从读者来说,先拿到一本技术书是很重要的,如果这本书足够有趣,就可以先睹为快。从作者来说,突然之间,收到上千条的反馈是很有意义的。大部分反馈可能都是一些小问题,但是曾经有几次,有人明确指出了书中的一些错误,那么作者就需要重新写这个部分。这其实就是我们想要的。这样做也让这本书吸引到了更多的人。当新版本形成时,编辑们会更新改动日志,然后告知大家新版本已经发布。现在甚至更近了一步,我们有几本书,它们永远处于持续更新状态。作者同意,这本书会持续两年不断更新,我们也会在网站上跟进。我们不会用传统印刷方法(传统方法意味着每次更新都要印3000册书),我们会采取“按需印刷”的方式。读者可以说我要这本书现在这个状态的纸质版,然后我们就会印出来发给他。这种方式真的很受欢迎,唯一的问题就是很难找到能和我们这样合作的作者。这样做对于作者来说是有很大回报的,书的销量会有很大上涨。这样书的内容既新鲜,寿命也更长久。人们总会为这样的书蜂拥而至。如果一本书一出来就已经过时了的话,人们就不会再买了。

图灵社区:听起来很不错,这更像是一种产品,而不是一本书。

Dave:你说得很对,这更像是一个软件产品。

图灵社区:在美国还有别家出版社也在这么做吗?

Dave:有的。Manning有“先睹为快计划”,O'Reilly好像也有类似的项目。要知道,好主意总是被模仿嘛!

翻译版的技术书籍上市时间一般要晚于原版一年甚至更久。在出版流程的合作方面,可以在beta阶段就由翻译方介入,加快中文图书的上市速度吗?是否考虑与中文翻译方(图灵)是否有这方面的讨论和进展?

Dave:这个问题我们每个礼拜都要被问到。就像上面所说的,我们的根本问题在于我们的书不是按章写成的。如果我们给你们一本书,其中有50%的内容尚未完成,那么一个月后,我再给你们一个新的版本,现在有60%未完成。但是第一章的一半被挪到了第七章,第三章被删除了,第四章和第二章合并了,而且我们打算给这种技术换个名字……如果你们拿到这样的书,译者可能会出门右转,了却此生。如果你们愿意尝试的话,我们可以一起试验,看这样的方式会怎么样。对于我们来说这样做很简单,但是我们不想为别人制造痛苦。另外还有一个原因就是,我们从未卖过一本还没有完成的书,我个人不喜欢销售还没有完成的作品,但是这样做并非完全没有可能。这也就是从我们系统上只能买到已经正式出版的书籍的版权的原因。我的担忧是,这么做有可能会得不偿失。但是如果有人想接受这样的风险,我们也可以共同来尝试。

现代计算机领域的发展真的像某些“专家”说的那样不可能是个人创造历史的时代了吗?大家只能依附于大公司的团队吗?

Dave:我觉得这些专家真是错得一塌糊涂。我认为个人才是创造历史的源泉。而大公司只是跟风而至,创造金钱而已。听起来有点愤世嫉俗,但是事实就是,只有个人才有那种勇气和自由来不断实验和犯错。你必须是一个有勇气的人。

如果你从事的是硬件领域的工作,制药、制造这些,当然,你需要一个大公司,你需要价值百万的设备来从事你的工作。但是如果你身处软件行业,你需要什么?一台电脑,足矣!你站在很多巨人的肩膀上,比如Linux, Microsoft,你有用来编译各种语言的免费编译器,你有免费的数据库,你有成功所需要的一切!也许最终确实需要一个团队来把事情做得更好,但是在开始的一两年中,你自己就可以完成伟大的事。事实上我认为,作为个人,成功的几率要比大公司高得多。

你需要亲身体会风险的感觉,你处在前沿,同时你也处在失败的边缘。如果你是事务缠身的商务人士,我很难想象你会进入这样的状态。

很多公司在招募新人的时候倾向于找具有技术广度的人,但是作为程序员可能在某一阶段对深入的研究某些技术感兴趣,对于深度和广度,你认为在什么时间点做这样的抉择比较合适呢?

Dave:我的经验恰恰相反,我认为大多数公司在招人的时候并不看重知识面宽广与否。他们有很多坑,他们只想找到能够填充到那个坑里的萝卜就好了。他们招人的要求非常具体,程序员面试的时候会做一些编程测验,只要他们能做这份工作就可以了。他们填完这个坑,就开始盘算填下个坑。如果你是一位程序员,你想被一般的破公司雇佣,那你只要看看他们的要求,然后把你的经验填进去就可以了。这真是惨绝人寰。

有两种程序员,一种人把编程当作工作,一种糊口的手艺。他们早上上班,然后编程,然后下班。他们在工作之余从不想关于编程的任何事,他们不看相关书籍,也不会和朋友们聊到这些事,这只是一份工作而已。对于这些人,他们在坑里也很开心。但是如果你所说的是优秀的程序员,那他们想都不该想跳到这些坑里去。他们在这样的环境下会窒息。他们需要的是找到那些不根据那些条条框框招人的公司。这样的公司需要的是“聪明人”,可以沟通的人,有激情的人。这也是我们的目标读者,这也是我想要雇佣的人。

我可能是世界上最差的雇主,我招来的人要么就是完美的,要么就是一场灾难。我看人最重要的一点始终是热情。我招的人可能只有一半接受过正式的计算机相关教育,其他的人都是自学的。但是这些自学的人基本上都是更优秀的开发者。

如果你的工作和事业是软件开发,你的热情也在于软件开发。那你就必须要不断学习。如果你不持续学习的话,你就会过时,你的技巧会没有用武之地,你也体会不到乐趣。作为程序员,你应该始终领先于潮流一点点。如果大家都在看Java,你应该学Ruby,如果大家都在学Ruby,你应该看Scala或者Elixir,或者其他什么。有的人会说,我上班的时候太忙,没有时间。我要说,这不是你的工作,这是你的事业,这是你的生活。

现代编程提倡让他人理解最重要,斯坦福大学的老师甚至说注释和代码一样重要。冗长的注释会不会让代码的简洁性大打折扣?

Dave:我不太同样这种说法。我认为注释会让代码更不容易理解。我认为注释是一个借口,为了你表意不明的代码找的借口。如果你认为你的代码很复杂,或者有些问题没写清楚,那你就会想为你的代码写一段注释。别这么做!你的代码有问题,解决代码的问题先,让它变得清晰、易懂。如果某家公司有一个编程标准,说程序员必须为代码写上大把的注释。快停下来吧!这都是些不相干的事。程序员的产出应该是商业价值,注释并没有增加任何商业价值。我用注释吗?我确实用,但是极少。基本上,我都是在自己没有能力把代码变得更好的情况下才写注释。对于我来说,注释是一个“这段代码有问题”的信号。

您觉得数学和编程的关系怎么样?最近Google大牛Steve Yegge觉得数学很重要,您觉得两者关系大吗?

Dave:我不认为数学是必学的功课。但是我承认,有一些人的思维和软件开发的思路很契合,这种思维追寻模式,寻找事物之间的联系,能把各种各样的东西结合在一起。这可能也是数学家们的思维方式。但是我知道很多音乐家也能够做到这些。如果有一屋子的程序员,你问问他们谁会演奏乐器,你的结果差不多应该是30-40%。我不知道对于一般人来说,这样的比例是多少,但是应该达不到这么高。程序员们演奏起乐器来可能比普通人更擅长。我的朋友Chad Fowler(《Ruby编程(第2版)》合著者之一)原来是一位职业萨克斯表演者,他曾经在田纳西的孟菲斯乐团演奏。我的合作伙伴Andy是一位爵士鼓表演者。我认识的很多人都会表演乐器。可能有些人的大脑和思维方式更适合做这些事。

程序员可能会擅长于数学,或擅长于音乐,但是我不认为必须要有很深的数学功底,才能成为一位开发者。

图灵社区:我在您的网站上看到了您写的音乐。

Dave:是,我是作了一些曲子,但是我的问题是我不会表演。演奏我曲子的是另一位程序员,现在他正在一个和爵士乐相关的开源项目上。我们共同创作了这首7分钟长的曲子。

听说您对中国的教育事业很感兴趣,是真的吗?

Dave:我对中国的两件事很感兴趣,不不,其实是很多事(笑)。 第一件事软件开发,我去过世界很多地方,也见过世界各地的程序员。每个地方做事情的方式都不一样,这种区别通常以国家为界。我想理解每个国家的文化是如何影响当地的软件开发过程的。这只是我的一个爱好。比如说在日本,那里的文化要求所有人的意见都能统一,甚至是无法统一的情况。所以和那里的程序员交流挺没意思的。他们只能看到需要他们来修补的东西,他们必须是团队的一员。这是不对的,这样的做的结果就是整个的开发流程也会因地制宜,受到影响。我也想了解中国的程序员是如何工作的,但是现在我还没有掌握足够的信息。

至少在美国,在大公司上班的程序员很多都有自己的项目。他们在公司上班的状态也是不固定的,他们经常上一阵班,然后再赋闲在家开发一段时间。我觉得这样的混合经历会让他们可以经常换换脑筋。我感觉中国的情况可能不是这样,但是我不确定,我还需要和更多的人交流。

另外一件事就是教育。在美国,软件开发在学生中间不是很受欢迎的专业。在大学学计算机相关专业的学生在减少。我认为这是一场危机。因为这就意味着我们讲没有足够的人才,我们有可能会落后于世界。这在美国是一个问题,所以我一直都想办法让美国的青少年对软件开发更感兴趣。我一直在尝试,但是始终没有找到好的方法。在美国,女性程序员的比例小于20%,在其他职业中的比例小于50%。我希望这个状况可以改善,至少可以增加开发者的整体人数。这件事的意义当然不止于此,我不知道造成这样结果的原因是什么。是遗传生理上的差异,还是现有软件社区很丑陋,排斥女性加入。我知道中国的情况可能还不如美国。不知道这样的情况通过让青少年增加接触编程的机会能否有所改善。对于有些人来说,软件会是一件很有趣的事,毕竟这是为数不多的凭借单枪匹马就可以改变世界的事。你可以改变现实,通过打字,就能够创造一片天地。如果我们能把这样的思想传递出去,也许就会有越来越多的人来学习编程了。这就意味着我们必须要实现承诺,让公司们明白,软件不是填坑就可以了,要让程序员们有空间发挥自己的热情,创造出更杰出的产品。

从这个意义上讲我确实对教育很感兴趣。比如说在美国有一个项目,让无业和穷苦的人们接受教育,学习新技能。软件是一个学习成本很低的技能。有的机构向贫苦的孩子们捐助电脑,帮助他们学习,这真是好事一桩。让每个人都有机会接触电脑,不只是玩游戏,而是亲手创造一些什么。

听说您正在写一本关于用Elixir编程的书,能告诉我们Elixir最吸引你的地方是什么吗?

Dave:因为我喜欢!这其实就是最根本的原因。Elixir能让我微笑,所以我愿意和别人分享这样的快乐。对于Ruby来说也是这样,我想和别人分享这份愉悦。

从另一个层次说,软件世界在发生变化。每隔两年,计算机的数量就会翻一番。为了适应时代,我们必须改变计算机工作的方式。在过去,我们做的就是让计算机变得更快。现在,计算机里的处理器更多了,我的笔记本是四核的,也许明年就是16核或32核的了。所以作为软件开发者,我们没有选择,我们需要写出在这些机器上运行良好的代码。这又回到移动设备上的问题,这些代码不仅要在不同的设备上运行,还要在同一设备上的不同处理器上运行。用传统编程语言,比如Java、C#或Ruby,要写出多核运作的正确代码是很困难的。Elixir是一门以Erlang为基础的语言,Erlang已经诞生了30年。这门语言的很大一个部分就是Erlang虚拟机,它可以支持数以百万计的处理器,它们以极高的效率相互通讯。它可以很有效地调控这些处理器,如果其中一个坏掉了,仍能在不影响其他处理器的情况下继续工作。它也可以改变处理器,而不需要影响到正在运行的应用。所以在电话中转中,很多软件都是用Erlang写的。启动转换之后,运行不会停止。这些都是很好的特性。但是,Erlang语言本身却十分丑陋。虽然确实有人喜欢这门语言,但它对程序员并不友好,至少可以说独树一帜到令人担忧的程度了。

Elixir是将与Ruby类似的句法,放在Erlang虚拟机上。这样既可以得到虚拟机的好处,又可以写出更加平易近人的代码。不仅如此,Elixir还可以利用虚拟机做到Erlang也做不到的事。在Elixir里什么都是可以改变的,程序员会觉得很有趣,还可以避免Erlang里的重复代码。所以你写出来的代码会更短,也更容易改变。在未来,我觉得Elixir可以用在大型分布式系统上面,它可以用在大容量,大量事务的环境中。它也可以为创业者们服务,为他们完成用传统方法无法完成的事。创业者们永远都在找从前无法实现的事,具体是什么呢?我不知道,如果我知道的话就去创业了。他们可以尝试从连接所有东西,和很多东西交互的角度来考虑(比如和洗碗机,或者洗衣机交流)。我对此充满了期待。


Dave Thomas在Ruby大会现场为读者签名

enter image description here

enter image description here


更多精彩,加入图灵访谈微信!