本文转载自 开源中国,译文链接:Click me,原文链接:Click me
本文作者 Chris Grainger 是开源 IDE Light Table 的开发者,之前在微软 Visual Studio 开发团队效力。本文是 Chris 根据他自己的演讲《Finding a way out》改写而成。
当开始设计 Light Table 的原型时,我并没有任何宏伟目标,只是一直在思考如何能更好地编程,还想看看做到这点有多难。直到最近,我才幡然醒悟:过去的十年努力:从Web框架,到Visual Studio,到 Light Table 的这段经历让我意识到:从一开始我就错了。事实上,我犯了一个典型的新手错误:想回答一个自己都不明白的问题。
如何更好地编程?
我只是不停地问自己:“我们怎样才能更好地编程?”但从来没有退一步,具体去想编程有什么地方不对。一直以来,通过对自己和他人的工作的观察,我得到了最完整的答案。以“Light Table”为例,如果缩短反馈循环会提升性能,虽然它的确可以,但却掩盖了一个事实:只是相同的老版本迭代。人们在痛苦的深渊中挣扎,我也是。“缩短反馈循环”并没有将我们从编写和调试代码的“深渊”中解救出来。所以,如果问题不只是反馈循环,那又是什么呢?编程的问题到底在哪?
要回答这个问题,我需要更多的数据,不仅仅从我的“后视镜”或自己的经验,而是从“现实世界”。于是我开始问大家两个问题:“什么是编程?它的问题到底在哪?”我问过从未编程的普通人,正在上班的白领,同行业中最好的工程师,等等。他们的答案让我吃惊不已。
什么是编程?
这个问题的答案真是令人沮丧。问了这么多人,居然没有一个人说“编程是用来解决问题的。”相反,大家更多的觉得它只是用半干的胶水把东西粘起来盛水,并祈祷在被新东西取代之前还可以继续盛水。我听别人说过无数遍,说我们只是水管工和胶水工厂。还有人说”编程主要解决自身不足“,这让我特别难过,因为它是众多答案中唯一接近正解的答案:我们把东西放到一起来解决某个问题,而“这个问题”是让程序员沮丧的源头之一。
编程本来是用来解决问题的,却变成了解决问题的问题(一个工程师朋友喜欢称之为“自舔冰淇淋”)。“胶水工厂”肯定不是我想要的答案,所以我一直在想一些可以行得通、说得过去的答案。到目前为止,我最喜欢的一个是:programming is our way of encoding thought such that the computer can help us with it. 编程是把我们思想转成代码,并让计算机可以帮助我们实现它的方式。当一天结束的时候,我们试图做的是构建一个新东西,并能够实现它——编程恰好是实现它的最好方式而已。
编程的问题在哪呢?
这个问题的答案也是我不想再问人(约400人)的原因。他们往往分为两类:他们要么随大流,并没有提供任何有用的信息,要么非常有个性的回答(当得到这些“死锁”时,我相当无语)。但总体而言,对于“编程的问题在哪?”这个问题的数百条答案,我提炼出了三类答案:不可察,非直达 和不简单。(unobservable, indirect, and incidentally complex)
编程是不可察
最近由于Bret和“Light Table”的开发工作,这点似乎是我们最为关注的。我们不能看到我们的程序是如何执行的。我们不能看到对程序的改变是如何影响项目。我们不能看到我们的程序是如何连接在一起。这基本上意味着我们观察不到任何东西。可观测性可以看做是一个一步一步查看状态的调试器,它强迫时间停止,并观察在某个时间瞬间的状态。但事实是,程序在某个时间瞬间基本上不会出错;大多数错误都是在一段时间内发生。就因为这一点,我们最好写一个print语句。但这十分荒谬。我们需要的是观察整个计划执行的过程,后进,后退,甚至未来——而不仅仅只是当我们的断点命中时。比这更可悲的是,我们似乎已经接受了不可观察性为一个既定的事实。例如下面这行代码:
它有什么作用?面向对象的封装的定义就是不可观察性。我不知道person.walk()有什么用。它可能做一些事情,像设置isWalking为true,但它也可以设置ateCarrots为true,它也可以决定我是否因疲惫而昏厥——我不知道,也没有办法知道。就好像,我们在一片漆黑中无所顾忌地扔飞镖并祈祷我们至少能射中靶心。不管你是刚刚起步或已经写了数以百万计的漂亮的代码行的程序员,根本无法看到我们的程序怎么运行,这是一个严重的问题。
编程是非直达的
写一个程序是一个容易出错的翻译工作。即使是数学——编程语言因其而生,都被翻译成这样了:
09 | template < typename Iterator> |
10 | double standard_dev( Iterator begin , Iterator end ) { |
11 | double mean = std::accumulate( begin , end , 0 ) / std::distance( begin , end ) ; |
12 | std::vector< double > squares ; |
13 | for ( Iterator vdi = begin ; vdi != end ; vdi++ ) |
14 | squares.push_back( std:: pow ( *vdi - mean , 2 ) ) ; |
15 | return std:: sqrt ( std::accumulate( squares.begin( ) , squares.end( ) , 0 ) / squares.size( ) ) ; |
19 | double demoset[] = { 2 , 4 , 4 , 4 , 5 , 5 , 7 , 9 } ; |
20 | int demosize = sizeof demoset / sizeof *demoset ; |
21 | std::cout << "The standard deviation of\n" ; |
22 | std::copy( demoset , demoset + demosize , std::ostream_iterator< double >( std::cout, " " ) ) ; |
23 | std::cout << "\nis " << standard_dev( demoset , demoset + demosize ) << " !\n" ; |
而我们为什么不能直接看到:
![aa](http://static.oschina.net/uploads/img/201405/05073148_9Erf.png)
这个例子,还算是翻译的比较清晰了。那要是代码不是这么清晰,又会发生什么呢?我们能得到就只有符号了。我们从来没有看到或与真实的东西交互,他们只是象征性的表示交互。而在某些情况下,符号固然重要和强大,它们不必是不透明:
是啊,打牌的时候,当我拿到卡[0] [12],我会很开心。我们正在编写一个纸牌游戏,纸牌有自己的名称(黑桃A),为什么我们不能直接存储这个呢?
![A](http://static.oschina.net/uploads/img/201405/05073148_Ky53.png)
翻译很难,而且使用的符号又容易出错,尤其是当与其他元件的上层操作耦合时。这种间接性,导致其不能代表有意义的东西,如果直接使用它们,又会让我们抓狂。大量编程的错误仅仅是翻译问题。虽然我们的脑子里有解决方案,但在试图把它翻译成代码的时候,我们要不是忘了什么东西就是犯些小错误。所以,我们必须摆脱翻译。当我们设计UI,我们应该做一个可视化编辑器。当我们研究数学,我们手边应该有类似的Mathematica的工具。我们应该用最自然的方式展示他们,而不是混淆不清的方式。
编程是复杂的
在编程中通常带有许多的复杂性事件,你得是要做一堆并不与你要解决的问题直接相关的工作。试着计算即使得到最简单的运行结果所需的时间,至少要花一个星期的时间来搭建一个开发环境。这些例子都是一个系统中不必要的复杂性,但事实是这种偶然的担心普遍存在的整个编写软件的全过程。最糟糕的是,我们现在是在逻辑层用代码做时间管理。大多数人可能会反驳,我们只要立即跳转到并发和并行就行了啊,但实际问题不是这么简单的。每当我们添加一个事件处理程序或创建一个回调,我们就是在做时间管理。
考虑到交互模式越来越复杂,我们程序面临多内核增加的变化(随之而来的并发问题),很快我们得知回调是解决该问题的糟糕方案。每次我们想要自己手动管理事物的时候,我们都可以想出一个实现自动管理的方案。我们曾经手动处理二进制,后来我们创建了Fortran语言。我们曾经手动管理内存,后来我们创建了垃圾收集器。我们曾经管理数据的限制,后来我们有了类型系统。我认为,下一步优化代码的复杂性的重大举措将来自于实现自动时间管理,这将对我们清晰地表达意图的能力有重大的影响。
试图列举编程中所有复杂性的例子将会令人感到无望,但现在是时候要解决这些问题了。我们应该专注于解决问题——而不是解决问题的问题。这样我们就可以在一天之内从一无所有到生成解决方案,而不是需要几周或几个月的时间。
追求局部最优(Chasing local maxima)
如果你回顾在过去50年主流技术上的进步,他们虽然很大程度上提高了我们的效率,却没有真正改变程序的行为。之所以我在文章的开始暗示:一切都是被动的,因为我们往往只在战术层面上的修正。事实上,几乎每一个我们取得的进步已经完美的解决了以上三类问题。我们让事情变得更好,我们不断接近局部最优,因为我们认为这些东西能以某种独立的方式解决。我听过最好的比喻是茶杯堆叠效应,每次我们修复某件事情,就是在茶杯堆上继续放茶杯,但最终我们只是在抽象多层次的工作,而该塔也开始倾斜并快要倒塌。我们必须停止单独思考这些问题,而是要想怎样才能同时解决他们。
有一天,我突然开窍了:编程其实是一切的对立的统一。晦涩的语言,神秘的错误,缺乏(或大多是零散的)文档——就像坐在某个真人秀的现场(幕后还会传来阵阵笑声)故意为难你。在一定程度上,这是自虐,但我们这样做,因为它给了我们提供了一个难得的机会塑造世界。通过认真思考编程的定义和它的问题所在,我们可以找到消除多余内容的框架的机会。但为了做到这一点,我们不能只考虑我们现在拥有的。另一个抽象层是不够的。相反,我们必须从根本的层面解决问题。不要更多的茶杯,不要更多的妥协。
编程之人
跟非程序员的聊天,他们会提供非常不同的看法。事实是,在我看来,他们大多也是程序员。他们只是不写“代码”而已。如果您使用Excel,你就是在编程——你要电脑根据你写的一个模块为你工作。 Excel是一个特别有趣的例子,这让它取得为人们能够解决问题的巨大成功。这也恰好满足我们的三个基本条件,并一些证据表明,它具有强大的解决问题的能力和“平易近人”的开发环境。
Excel是可观察的,因为它没有任何隐藏的状态,所有的值你的看到并操作。它也是直接的。你可以在表格中直接更改数值,拖放东西,选择性地计算等等。它设法回避了很多复杂性问题;电子表格是永久有效的,它没有安装程序,甚至没有的正在运行的概念。Excel通过权衡权限实现了这些。有很多事情是无法表达,因为放置在编程模型的约束条件非常好(或全部)。一个有趣的问题是,是否以类似的方式就可以解决我们的问题,但缓解了一些限制和保留更多的权力。
我们越多探讨过这个问题,就越会意识到,通过修复了这些问题我们在编程更加普遍的路上已经走了很远了。因此,如果这个有趣的问题的答案是肯定的,那大约有十亿人可以拥有现代超能力。试想一下,如果每个人都用电脑做到80%如今的程序员的工作。这样对什么的影响会最大?我不知道,但我认为它这将是我们人类作为一个集体的根本性转变,而且肯定是一件非常棒的事情。从长远来看,我相信操纵电脑将成为一项基本技能,但不像大多数的“编程是识字”(programming is literacy!)运动,我认为这将与能否写出'if'语句无关。未来编程将会是大多数人都可以做到的事。任何以我们现在这样做事的方式,是注定要失败的。事实上“受虐狂”一点也不受欢迎。
文化差异
我的问题还没有解决的另外一个原因是:编程带来的社会问题,最近也得到了越来越多的关注。有许多方面对这个问题从编程已有的固有印象,到我们社区互动的方式,已经上升到了偏见和成见。我觉得编程最有趣的地方之一是它有可能引起的文化的重新定位。如果编程本身并不对立,那会变成什么样呢?如果只需要粗略地计划就能编程,又会是什么样?如果编程从一开始就是思路清晰的?这样的编程,与我们如今的编程没有一点共同之处。因为解决编程带来的文化问题才是真正地改变世界。
好,现在该怎么办?
我们找到一个解决问题的基础!没问题吧?在“Strange Loop”的演讲中,我展示了我们一直都在做的Aurora非常早期的原型。这里,我带来了新的进展。虽然我们的策略已经有了显著改变,其背后的概念仍然是相同——我们想要找更好的东西,不只是针对程序员或非程序员,而是完全消除这种区别。我们最近在这个方向做了些实实在在的进展,当稳定之后,我们将分享更多。但有一点我想说的是,大家一定要眼见为实。