上海外贸网站优化,中国数控机床网,网站建设 招标书,宁夏做网站找谁摘要#xff1a;随着软件功能不断增加#xff0c;代码数量也日益膨胀#xff0c;我们要如何停止不断堆砌#xff0c;甚至缩小软件体积#xff1f;本文作者提出了一种可能性#xff1a;“小语言”。链接#xff1a;https://chreke.com/little-languages.html声明#xf…摘要随着软件功能不断增加代码数量也日益膨胀我们要如何停止不断堆砌甚至缩小软件体积本文作者提出了一种可能性“小语言”。链接https://chreke.com/little-languages.html声明本文为 CSDN 翻译未经允许禁止转载。作者 | Christoffer Ekeroth 译者 | 弯月 责编 | 郑丽媛出品 | CSDNIDCSDNnews我认为“小语言”——旨在解决非常具体问题的小语言——是编程的未来尤其是在阅读了 Gabriella Gonzalez 的文章《编程历史的终结》The end of history for programming并观看了 Alan Kay 的演讲《编程与扩展》之后我更加确定了这个看法。什么是“小语言”“小语言”这个词源自 Jon Bentley 的一篇文章《Little Languages》小语言他给出的定义如下……小语言指的是专门针对某个特定问题领域的编程语言不包含传统语言的许多功能。举个例子SQL 就是一种描述数据库操作的小语言正则表达式是一种用于文本匹配的小语言Dhall 是一种用于配置管理的小语言等等。这些语言还有一些其他名称比如领域特定语言Domain-specific languages简称 DSL、面向问题的语言等等。但是我最喜欢“小语言”这种叫法有一部分原因是“DSL”一词包含的含义太多了包括从具有流式接口的库到成熟的查询语言如 SQL。此外“小语言”这种叫法还强调了这类语言的一个本质小。为什么我们需要小语言从工程的发展史来看如今的软件也属于某种工程但从事这种工程的人并不懂得“拱门”为何物。现在大多数软件与埃及金字塔非常相像由数百万块砖相互堆叠而成没有结构完整性只是靠蛮力和成千上万的奴隶建造的。—— 艾伦·凯摘自《与艾伦·凯的对话》软件工程社区真正遇到的问题是随着应用程序的复杂性增加其源代码的规模也会随之增加。然而我们知道大型代码库的能力在很大程度上仍然是固定的。根据 Sourcegraph 于 2020 年发起的一项调查 The Emergence of Big Code 表明大多人都表示他们的代码库出现了以下一个或多个问题很难添加新员工缺乏对依赖关系的理解导致代码出问题代码变更的管理难度越来越大。更糟糕的是应用程序正以惊人的速度增长据 Sourcegraph 调查大多人认为他们的代码库在过去十年中增长了 100500 倍。举一个具体的例子1992 年 Linux 内核刚问世时只有大约 1 万行代码但在 20 年后的今天已经达到了 3000 万行。这些代码从何而来我认为“更多功能”不足以解释这些代码量的增加相反我认为这与我们构建软件的方式有关。在程序中添加新功能的常见方法是在现有功能之上不断堆叠——这不恰恰就是金字塔的搭建方式吗不同的是每一层所需要的砖会越来越多。逆势而上问题是我们真的需要数百万行代码来构建现代操作系统吗2006 年Alan Kay 与 STEPS 项目的合作者开始挑战这个假设科学的进步需要结合实证研究与理论模型所以作为科学家我们的首要问题是如果我们以个人计算现象为基础建立一个模型是否可以将其提炼为极度简化的东西就像适用于所有电磁波谱的麦克斯韦方程组或者是可以浓缩至衬衫口袋大小的美国宪法还是说这个模型非常混乱或者极端复杂就像美国的法律体系或当前的软件实践一样“堆积起来有 3 立方英里”那么高的判例法答案几乎是肯定的介于两者之间。果真如此的话能证明这个模型更接近于简化而不是极端复杂那一定非常有趣。所以我们的问题是个人计算体验将操作系统、应用以及其他支持软件的经验都算在内本质上指的是多少行代码20 亿行、2 亿行、2 千万行、2 百万行、20 万行、2 万行还是 2 千行—— 《STEPS 2007 年进度报告》第 45 页这里Kay 提到的麦克斯韦方程组是一组描述电磁学、光学和电路基础的方程式。这些方程式的使用范围非常广但方程式本身很紧凑甚至可以印到 T 恤衫上这些方程式如此简洁的原因之一是使用了 Del 符号∇来描述向量微积分运算。需要注意的一点是Del 并不是真正的运算符它更像是一种简写形式可以方便我们使用向量微积分中的某些方程。那么我们可以创建编程界的 Del 符号吗就像 Del 可以让向量演算更易于管理一样我们是否可以找到某种符号以相同的方式帮助我们理解程序这个问题正是 STEPS 项目背后的核心思路之一此外我们认为创建面向问题的语言可以降低解决问题的难度可以使解决方案更易于理解且更小并且也符合我们“主动数学”方法的精神。这些“面向问题的语言”将被创建并用于大大小小的问题以及不同层次的抽象和细节。—— 《STEPS 2007 年进度报告》第 6 页这里的基本思路是在寻找应用程序中的模式时你可以用一种小语言将它们编码这种语言将允许你以比其他抽象方法更紧凑的方式来表达这些模式。这样不仅可以逆转应用程序不断增长的趋势而且还可以让代码库在开发的过程中缩小我发现Nilehttps://github.com/damelang/nile是 STEPS 计划的一大成果这是一种用于描述图形渲染和合成的小语言目标是使用 Nile 实现与 Cairo 相同水平的功能。Cairo 是各种免费软件项目都在使用的一种开源渲染器总代码量约为 44,000 行——而 Nile 只有大约 300 行。为什么不是高级语言尽管如此事实证明 Ada 并不是干掉软件生产力怪物的灵丹妙药。毕竟它也只是一种高级语言这类语言带来的最大收益来自第一次转变从机器意外的复杂性上升到更抽象的逐步解决方案。在剔除这些意外后剩下的意外就会变少而剔除它们的回报自然也会减少。—— Frederick P. Brooks《No Silver Bullet》说到这里你可能想问“为什么我们不能发明一种更高级的通用语言呢”我认为通用语言的表达能力带给我们的收益已在递减。那么更高级的语言将是什么样子呢以 Python 为例这门语言如此高级看起来已经很像伪代码了。通用语言的问题在于你仍然需要将问题转化为算法然后再用语言表达算法。如今的高级语言非常擅长描述算法但除非你的目标是实现算法否则它也会意外的复杂。在写这篇文章的时候我想起了一个关于 Donald Knuth 的故事有人让 Knuth 在 Jon Bentley 的 Programming Pearls 专栏中展示他的编程风格而 Doug McIlroy 应邀对 Knuth 的程序发表评论。Knuth 的任务是计算某一段文本中的词频其解决方案是用 WEB 语言精心编写的这门语言是 Pascal 的变体也是他自己编写的。Knuth 添加了一个专门用于跟踪字数的数据结构所有代码不到 10 页。虽然 McIlroy 很快就称赞了 Knuth 的解决方案但他对程序本身并不是很满意。作为评论的一部分他用 shell 脚本、Unix 命令和小语言编写了自己的解决方案tr -cs A-Za-z \n |
tr A-Z a-z |
sort |
uniq -c |
sort -rn |
sed ${1}q对于不熟悉 Unix 的人来说这段代码不太容易理解——McIlroy 本人也承认这一点他甚至添加了一个带注释的版本。但很显然相比十页的程序这段代码更容易理解。Unix 命令是为操作文本而设计的这就是为什么 McIlroy 可以编写出一个如此紧凑的字数统计程序。或许我们可以将 shell 脚本视为文本操作的“Del 符号”少即是多上述 Unix 命令示例说明了小语言的另一个特征语言本身不是特别强大但运行时非常强大。Gonzalez 在文章《编程历史的终结》中提到了如下趋势在研究上述趋势时我们发现了一个共同的模式将用户关心的某个问题转变成运行时的问题可以……让使程序更像纯数学表达式并且……运行时的复杂性明显增加。正则表达式和 SQL 只能用于表达文本搜索和数据库操作。与之相对的是C 等没有运行时的语言你可以表达任何在冯-诺伊曼架构上可能出现的东西。而 Python 和 Haskell 等高级语言介于两者之间你无需在意内存管理但仍然可以使用图灵完备语言的全部功能这意味着你可以表达任何计算。小语言和 C 语言处于两个极端。对于小语言来说不仅计算机的体系结构被抽象掉了其中一些语言可以表达的程序种类也有限制——它们在设计上是不具备图灵完备性的。虽然听上去这些语言非常受限但实际上它们为优化和静态分析开辟了全新的可能性。而且就像抽象出内存管理可以消除一大类错误一样尽可能地抽象出算法也有助于消灭更多的错误。静态分析功能不是十分强大的语言更容易推理而且可以提供比通用语言更强的保证。例如Dhall 是一种用于生成配置文件的全功能编程语言如果你不想冒险让部署脚本崩溃或将它们置于无限循环中则可以考虑 Dhall因为它可以保证1.不崩溃2.在有限的时间内结束。第一点的实现方式是不抛出异常任何可能失败的操作例如获取空列表中的第一个元素都会返回一个可选的结果其中可能包含值也可能不包含。第二为了保证结束Dhall 不允许程序使用递归定义。在其他函数式编程语言中递归是表达循环的主要方式但在 Dhall 中你必须依赖内置的 fold 函数。缺少通用的循环结构意味着 Dhall 不是图灵完备的语言但由于它不是一种通用的编程语言所以也没有这个必要。如果语言很小理解起来就更容易。例如你很难确认 Python 程序是否有副作用但对于 SQL 来说却很简单你只需检查查询是否以 SELECT 开头。对于 NileSTEPS 团队看到了对图形调试器的需求。Bret Victor 想出了一个工具可以告诉你在屏幕上绘制特定像素的代码。你可以通过 YouTube 观看 Alan Kay 的演示也可以自己动手尝试一下。这样的工具是完全可行的因为 Nile 是一种易于推理的小型语言——想象一下如果用 C 编写同样的一款工具会是什么样子对速度的要求强大的编程语言不仅会增加出现 bug 的可能性还会对性能产生不利影响。例如一个程序没有用算法来表达运行时可以自由选择我们可以用更快的表达式来替换当然前提是我们能证明它们能产生相同的结果。例如SQL 查询并没有规定应该如何执行查询数据库引擎可以自由使用它认为最合适的任何查询计划例如应该使用一个索引、多个索引的组合还是直接扫描整个数据库表。现代数据库引擎还会收集有关列的值分布的统计信息这样它们就可以即时选择最优的查询计划。如果查询是通过算法的方式描述的那就不可能了。Nile 语言如此紧凑的“秘密武器”之一是 Jitblt这是一种用于图形渲染的即时编译器。从 STEPS 和 Cairo 团队之间的讨论可以清楚地看出Cairo 的许多代码都是手动优化像素的合成操作理论上这部分工作可以交给编译器。因此 Cairo 团队的 Dan Amelang 实现了这样的一个编译器它就是 Jitblt。这意味着图形流水线的优化工作可以与渲染内容的纯数学描述分离这也是 Nile 的运行速度与手动优化过的 Cairo 一样快的原因。小语言大潜力那么STEPS 项目最后怎么样了他们最终得到了“堆积起来有 3 立方英里的判例法”还是设法创建了一个“可以印到 T 恤衫上的操作系统”他们的最终结果是 KSWorld这是一个完整的操作系统包括文档编辑器和电子表格编辑器大约有 17000 行代码。虽然无法印到 T 恤衫上但我仍然认为这个项目是成功的。KSWorld 的创建表明小语言有很大的潜力。然而我们还有许多问题没有解决例如这些小语言之间应该如何互通它们应该编译成一个通用的中间表示吗或者使用不同的运行时然后通过通用协议例如 UNIX 管道或 TCP/IP相互通信或者也许每种语言足够小可以用各种不同的宿主语言重新实现如正则表达式亦或者我们可以结合使用这些方式无论怎样我认为我们需要一种不同的方式来构建软件。小语言能否成为这条发展道路上的一部分也许我们还没有答案但重要的是我们必须停止不断堆砌砖头同时还需要想出一种更好的办法。
