为什么很难从根本上改进编程(2017)

2020-12-07 15:27:03

关于人类的好奇之处之一是能够同时持有两种矛盾的观点。当我处于分析模式时,我试图了解是什么市场,技术和社会力量导致了现状。为了有效地做到这一点,或者至少诱导出有用的原则供以后使用,您必须相信事情是有充分理由的。但是,当我戴上创新帽时,我全神贯注,并认为“拧紧!如果Y”,X会好得多。我在去年了解到,平衡这两种观点对于发明家至关重要。

本周,我观看了Bret Victor从2013年7月开始的“编程的未来”演讲,这迫使我将这些想法记录在纸上。在演讲中,布雷特(Bret)使用一台投影仪,并假装是1973年。他自豪地介绍了当时最新的编程研究,并解释了为什么如果我们40年不使用它们,那真是愚蠢。值得赞扬的是,维克托始终讽刺地描绘着我们即将进入的理想世界,这始终是他的角色-观众知道那真的不存在。

未来的Bret展示了包括直接操纵输出(结果)而不是代码,通过约束/目标进行编程,空间(可视)编程范例以及大规模并行编程方法。声明式编程,函数式编程,微服务体系结构和所见即所得的编辑器选中了其中的某些复选框,但程度不高。话虽这么说,过去40年没有取得真正进展的论据,只是没有许多人预期的进展。

因此,现在我要戴上分析帽,研究为什么编程艺术如此难以超越当前水平。

许多人指责开发人员缺乏进步。我们构建了灵巧的东西X,但是开发人员过于自大,固执,忙碌,不屑一顾,或者以上所有这些都不适合采用。我什至听说人们指责开发人员试图抑制新编程介质的采用,从而自私地保护自己的未来工作前景。哎呀,我之前已经说过了……

^这是错误的。以我的经验,开发人员是非常理性的人。他们的工作是寻找每天解决问题的最有效方法,并且如果您创建一种工具来解决问题,那将是无所不在。他们甚至会自愿花时间帮助您免费构建它。如果您继续接受开发人员主要是理性的行为者并且有充分的理由采用某些东西/不采用某些东西,那么您可以学到很多东西来为将来的设计提供信息。

所以我做到了。在过去的三个月中,我实际上与人们坐下来,问他们为什么不采用各种工具。我绝大多数都得到了理性的解释,来解释为什么改用新东西是不合理的。

想象一下,您正在用一个坏的但可用的锤子手动建造一个小木屋。当您完成90%的工作时,神奇的精灵就会出现,并为您提供更好的锤子。大!但是需要权衡:如果您使用新的光亮的锤子,就必须从头开始建造房子……哦,他将人类带回了石器时代。您可以买到新的锤子,但必须没有带锯,皮卡车和钉子。

这个寓言来自于对我进行的所有采访的总结,并突显了开发人员对他们尝试使用的许多新“解决所有问题”工具的挫败感。就上下文而言,这些工具分为两类:新的编程语言,包括一些流程和应用程序。基于图的范例和无代码的可视化构建器。

选择编程范例时,需要考虑两个价值领域:[语言,工具,GUI]的开发人员经验和生态系统的实力(已经解决了哪些常见问题)。许多新范例虽然经常建立在合理的原则上,却错过了X语言的大量存在。在选择范例时,您如何权衡这两个领域? 30–70? 90-10? 1–99?与我交谈过的大多数人都认为,生态系统比DX重要2到3倍。

工具构建者通常只关注DX,并[假定,希望,祈祷]社区出现并建立生态系统。仍然可能发生这种情况,但是在90年代,这种情况比今天更为普遍。在编程中会产生网络效应,并且在最常用的工具中很快就会出现一个美好的良性循环。当用户公开共享功能时,它将使范式更加强大,从而吸引了不断改进该范式的新用户。繁荣!一切的节点模块。

当您查看最近真正流行的语言时,它们往往有一个共同点:它们利用现有的工作体。请看TypeScript,它是2000年后发布的最流行的语言,可与Javascript互操作。然后是Swift,它是2000年之后发布的第二流行语言。请想象一下,如果Swift无法与Objective-C和Cocoa遗留系统互操作,或者TypeScript的生态系统从一开始就是一片蓝海,它将成为当今的今天。

对于工具制造商来说,建立一个全新的基础抽象(包括视觉,基于文本或其他方式)会产生后果。如果您选择不与现有的生态系统进行互操作,那么您或您的社区将需要花费数年的时间,从石器时代到现代。编程只是学习使用一堆堆叠的抽象。即使您拥有客观上更好的基础抽象(如果在1992年引入它,它显然会胜过其他一切),但如果没有生态系统,人们几乎没有动力去采用它。

大多数人用“谬误”来完成“沉没成本_____”一词。经典的经济学思想实验通常涉及一对夫妇,他们只是因为为门票支付了票面价值而讨厌他们参加的音乐会。随着故事的发展,开明的经济学家会在对演唱会不满意时离开,并重新度过几个宝贵的时间。但是,如果您必须支付$ 50k,$ 50M或$ 5B提早离开音乐会,您可能会留下来。当转换成本如此之高时,有充分的理由留下来,而世界上最大的程序员雇主则拥有巨大的转换成本。这样可以使主流程序员始终保持现状。

这是开发人员在坚持他们所知道的范例时所做的另一种完全理性的选择。雇用新员工,培训,重新编写代码的总成本,以及在提高产品质量方面选择这些措施的机会成本,几乎总是超过进行更改的收益。 Joel撰写了一篇经典的有关代码重写的文章,对此进行了进一步的扩展。

没有太多传统或没有其他选择的年轻公司可以选择新的范例,但是这些公司中很少有最终成为老牌公司。做到这一点的人就是国王。 Facebook和Twitter最初都是基于最终规模不足的技术(PHP和Ruby)构建的。 Facebook对PHP的依恋如此之深,以至于他们通过Hack和其他工具增强了语言以适应其需求。同样,Twitter转到了Scala,有人可能会说这是Scala取得成功的关键原因。

工具制造商必须在学习能力和生产率之间取得平衡。像MIT的Scratch这样的可视化编程环境是令人难以置信的学习。我已经看到4-5岁的孩子在几个小时后就可以用它来制作游戏。拖放界面和基于形状的约束非常易于学习,可以防止Scratch处于断裂状态。这对于尝试学习编程的孩子和个人非常有用。

使Scratch易于学习的相同因素也使它对于更认真的程序员来说是一个无用的环境。对于专业人士而言,拖放编程要比键入代码要慢得多,这是事实。

每当构建新工具时,都必须考虑这些折衷。如果您开发的东西没有学到任何东西,但会产生很多赞誉,但很少有后续行动。如果您构建的东西太难学了,但效率很高,那么您就会被很多人拒之门外。要吸引主流程序员,您需要做出既可学习又富有成效的东西。

我认为大多数停滞不前的编程创新都过度地关注可学习性。问题是,在使用任何范式的几周内,开发人员通常会建立一个习惯库,以防止他们犯错。例如,如果新的视觉逻辑构建器以防止所有语法错误为荣,那确实很酷,但是大多数开发人员已经学会了自动执行此操作。

事实是,您曾经使用过的每个工具都存在缺陷,并且每个新工具也将存在缺陷。人类下意识地想出了应对工具的方法,这样他们就可以专注于更大的概念问题。这不会很快改变。如果专业人员已经习惯了使用新工具使工作变得更容易/更易学的事情,那么这些新工具对他们就没有太大价值。这就像给一个40岁,一生一直在手动驾驶自动汽车的人-是的,这很棒,但这不是必需的,而且她当然不会为此付出任何代价。

情况已经越来越好。增长只是在生态系统中,而不是范式本身。从编程的早期开始,我们就一直在构建这座令人惊叹的抽象塔,为诸如以下内容提供真正有用的抽象:

配置大型服务器集群是通过短文本文件完成的,而不是一群人在数据中心中徘徊

现在回到前面我提到的在理解事物为何如此运行与相信它们可以改变之间的冲突。在过去的几十年中,编程没有发生根本变化,这有很合理的理由。任何想改变这一现状的有抱负的创新者都需要首先了解事物之所以如此的原因,然后利用这些见解来发挥其优势。

可以提出公正的批评来支持纯粹,不受阻碍的创新。可以说,像第一天那样进行设计是明智的,不必担心所有这些现实世界的限制。这种想法不适用于编程,因为整个编程生态系统的总价值主要存储在已构建的有用抽象中,而不是工具本身中。对于纯粹的概念领域,例如哲学和数学,也是如此。您可以更改表示法或书面语言,但总而言之,创意才是真正的价值所在。遗产就是价值,它不能被抛弃。