下一代范式编程语言：它们会是什么样？

导读

这篇论文以“下一代编程语言会是什么样”为题，讨论编程语言设计的下一个范式可能走向何处。文章属于对未来方向的展望性讨论，而非提出一个具体可用的新语言。

HN 关注点：HN 读者借此表达对语言与编辑器深度集成、极简核心、AST/可视化表示、编译期约束以及“生产力 vs 正确性”权衡的长期期待与不满。

关键词　programming languageslanguage designfuture paradigmsdeveloper productivity

HN 评论精选

这几条评论里：质疑 1　补充 3

补充希望语言与 IDE 协同设计，把注释变成独立、可绑定的富文本层，而不只是代码里的文本。

我想要一门与编辑器/IDE 协同设计的语言。我想停止把注释塞进代码里，而是让代码在左栏、注释在右栏成为一等公民：两者通过锚点始终绑定，但又彼此独立，这样注释就不必受代码文本区域的限制。然后我还想在注释区放入图形、表格等富内容，不想写 Markdown 表格或某种再转换成图形的简写；我要的是 Word、PowerPoint 或 Inkscape 那种所见即所得，而且感觉完全自然、原生。Jupyter 已经相当接近，我也很喜欢，但做 notebook 时总觉得放弃了很多东西；我希望在更能承担重活的格式里拥有这些。

Waterluvian查看英文原文

I want a language that is designed alongside an editor/IDE. I want to stop putting comments in my code. I want it to be first-class for my code to be in the left pane and my comments to be in the right pane, always binded together with anchors but always separate so my comments don't have to adhere to the limitations of the code's text area. And then I want to put rich things into my comments section like graphics and tables and such. And I don't want to have to write table-like Markdown or a shorthand that converts into graphics. I want all the WYSIWYG of Word or PowerPoint or Inkscape just right there feeling 100% natural and native. Jupyter is pretty darn close to this. And I like it a lot. But I feel like I'm giving up a lot to make a notebook. I want this in a much more heavy lifting format.

补充下一代语言应极简并暴露 delimited continuations 等底层能力，但真正创新的经济激励不足。

我认为当今编程语言太关注特性，结果都像 Algol 的变体，再从别处借几个特性。我觉得现在的人不太尝试理解语言和计算的构件是什么。我敢打赌，真正的下一代编程语言会是极简语言，只保留 essentials，同时不牺牲可读性。比如 Lisp 仍不够极简，因为它有“特殊形式”，也就是让条件判断工作的 hack；不直观的前缀表示法也没帮助。此外，很少有语言允许人们通过 delimited continuations 探索更深层栈操作的真正威力；有了它们，用户可以创建自己的循环和线程构造，以及自定义异常、迭代器机制和 effect handlers。必须认识到，真正创新语言的经济激励很黯淡：学术界困在渐进主义，私营部门不愿付钱，收益只会被云厂商收走，再给它们的估值增加数万亿美元。何必费劲。

snidane查看英文原文

I think programming languages today focus too much on features and then they all look like another Algol variations with couple of features borrowed from elsewhere. I don't think people these days try to understand what are the building blocks of languages and computation. I'd wager the true next generation programming languages will be ultra minimalistic languages, retaining only the essentials while not losing on legibility. Lisp for example is still not minimal as it has 'special forms', ie. hacks to make conditionals work. The unintiutive prefix notation also doesn't help. Also not many languages allow people to explore true powers of deeper stack modifications by delimited continuations. Using them the users would be able to create their own looping and threading constructs as well as custom exceptions and iterator mechanisms and effect handlers. It's important to realize that the economic incentives for truly innovative languages are bleak. The academia is stuck in incrementalism. Private sector wouldn't pay for it and the benefits would only be collected by cloud vendors, adding yet another trillions to their valuations. Why bother.

补充期待以 AST 为磁盘表示、文本/图形可切换、编译期约束和代码内嵌文档等语言与工具进步。

几个可能非常好的进步：* 把磁盘上的代码表示为抽象语法树，任何人都可以用自己喜欢的语法编辑，语法几乎变得无关紧要。* 上述一点开启了把代码表示为可视化图（甚至在 VR 中编程）的可能性；图和可视化编程有用，但能在文本与图表示之间切换，才能兼得两者之长。* 更智能的编译器，例如易用的编译期约束：可以指定某个整数的最小值，让编译器对索引越界之类问题产生编译期错误，且零运行时开销；更复杂的约束可由用户定义。编程思维可以转向“如何在编译期做尽可能多的事”。* 能把文档嵌入代码旁边。对大多数代码库来说，理解代码的能力是代码价值的一部分；注释远远不够，尤其处理可视化概念时。把易于访问的文档嵌入代码会大有帮助。

kettlecorn查看英文原文

A few advancements that could be very good: * Moving towards representing code on disk as an abstract syntax tree, and anyone can edit with whatever syntax they prefer. Syntax becomes virtually irrelevant. * The above point opens the possibility to represent code as visual graphs (even to code within virtual reality). Graphs and visual programming are useful, but to be able to toggle between textual and graph representation gives you the best of both worlds. * Smarter compilers. For example: easy to use compile time constraints. Think about the ability to specifiy something like the minimum value an integer can be set to. This could allow the compiler to produce compile time errors for things like index out of bound errors, with zero runtime overhead. More complex constraints could be user defined. The mindset of programming could move to thinking about how you can do as much as possible at compile time. * The ability to embed documentation alongside code. For most codebases the ability to understand the code is part of value of the code. Comments don't go far enough, particularly when working with visual concepts. Being able to embed readily accessible documention within the code could help dramatically.

质疑过度追求生产力会牺牲质量；行业应更重视正确性和产品，而非只求写代码更快。

> 编程语言设计的梦想，是在软件开发任务中带来数量级的生产力提升。我理解为什么如此关注生产力，但当它成为我们的头号优先级时，我认为这对行业很糟糕。如果你生产的东西质量差，生产力就没有意义。这就是为什么我们用 500 个 npm 依赖做 Web 应用，而原生应用会更快、更受用户青睐；这就是为什么我们使用那些不必“和类型系统搏斗”的语言，因为我们更愿意写得更快，而不是写得更正确。再说一遍，我完全理解为什么会这样。只是有点难过：我们把自己当成喷水的花园水管，尽可能多地喷出代码，却不多想如何做出更好的产品。

dahfizz查看英文原文

> The dream of programming language design is to bring about orders-of-magnitude productivity improvements in software development tasks. I can understand why there is such a focus on productivity, but I think it's awful for the industry when it's our number 1 priority. Productivity is meaningless if the thing that you are producing is of poor quality. It's why we make web apps out of 500 npm dependencies when a native app would be faster and preferred by the user. It's why we use languages where we don't have to "fight against the type system" because we prefer writing code faster to writing correct code. Again, I understand perfectly why this is the case. It just kinda makes me sad that we treat ourselves as garden hoses spewing out as much code as possible without as much thought into making a better product.

历次讨论

2019Hacker News 讨论帖217 分 · 226 评

HN 二十年，最值得读的论文。

朋友分享的书单

专题阅读路线

本周最多人读

我的书单

必读 30 篇

论文库

这些论文是怎么挑出来的

全量扫一遍

只留论文本身

写导读、译评论

下一代范式编程语言：它们会是什么样？

导读

HN 评论精选

相关资源

历次讨论

同领域还值得读

Google 的软件工程（2017）

Peter Naur：编程作为理论构建 (1985)

SciPy 1.0：Python 科学计算的基础算法

Lisp 的历史（1979）

使用 NumPy 进行数组编程

打赏支持

关注向阳乔木