我一直在思考一个问题：为什么我们要为人类创造编程语言，而不是为IDE创造编程语言，然后用人类可读的格式来显示程序呢？

用文本来表示数学表达式是非常糟糕的方式。

完全不如下述表达式清晰：

在处理编程语言中向量等非简单类型的时候情况会更糟，你只能通过引用传递结构。如果你不想耗费无谓的内存开销，那么就必须使用如下形式：

这些还只是最简单的公式。我在做图形引擎的开发时编写的着色器代码在调试时就是一个噩梦，因为它的表现形式十分晦涩难懂。

其次是变量的命名。再次举一个数学的例子：P(A | B)能够精准地表达含义且易于理解，并且简洁易于辨认。不幸的是大多数的编程语言都不允许我们以P(A | B)的形式命名变量。同样，有关camelCase和snake_case的争论也是由于不能在变量名中使用空格而造成的。

另一个问题是：我们如何在智能手机上编程？虚拟键盘不适合代码，基于图形的解决方案可能有效，但我很确定没有多少人喜欢在台式机上绘制图形。

制表符和空格的争论也是另一个由文本书写代码的假设引起的。同时，这两种方法都是严重过时的对齐工具。

对于上述每种情况，关键问题都在于格式和语义之间存在紧密耦合。只要我们以纯文本显示代码，就会产生这些问题。

连字和自定义运算符提供了一些帮助，但这些方法始终没有解决核心的问题。

那么如果我们将文件的表现从纯文本改成其他更丰富或结构化更强的形式呢？通过去除这种格式和语义之间的耦合，我们还可以在不同的系统上使用截然不同的格式（例如图形编辑器），然后修改底层相同的语义。

对此，你怎么看？

1.Hacker News 上开发者的观点

评论1：

你忽略了一点：文本文件是最简单的。虽然有时它们可能有点麻烦，但作为“构成表达的物质”，它们是无可比拟的。你可以使用现有最常见的人机界面设备来创建或修改文本，现在的孩子在上学之前就学会使用文本了。你可以阅读包含一百万种不同程序的文本，并对其进行样式化、过滤、格式化、剪切和粘贴以及其他无数的操作。书写方程式时的不足只是为这种灵活性付出的很小的代价。

如果按照你提议的方式“解耦”格式和语义，那么将无法避免语义与编辑器的耦合。这种情况下就只能使用一种编辑器，直到你开发出其他一些可以与语法树的结构化表示交互的东西。并不是说我们做不到或不应该这么做，APL就曾经做过，像Scratch这样的教育工具做得也很好，当然还有各种“无需编程经验”的流程图和建模语言，但是这种想法只能在一些非常具体的情况下才能与文本文件对抗。

评论2：

我觉得Smalltalk可以作为一个回答你的问题的例子。Smalltalk就像你描述的那样：一种为IDE构建的语言。你无法在该IDE外部使用这种语言，因为它没有按照纯文本的格式存储数据，而是采用了图像格式。该IDE为用户提供了各种不错的功能和分析，自从20世纪70年代创建以来，Smalltalk的创意已经影响了许多其他语言和IDE。那么为什么我们都不使用Smalltalk呢？我认为关键在于互操作性。Smalltalk是一个独立的世界。它无法与Smalltalk世界之外的工具很好地交互。例如，如果不解决如何以二进制的图像格式合并代码，那么就不能享受Git带来的便利性。当我需要完成一项特定的任务时（比如某种构建任务），我需要知道如何使用Smalltalk的工具在Smalltalk世界中完成所需的一切。Smalltalk违背了Unix哲学：它提供的不是一个功能，而是所有一切，因为它是一个微型的虚拟机。

我无权说这是我们不使用类似于Smalltalk的语言编程的所有理由，但是我觉得这是其中一部分理由。很多新的编程语言在尝试用新的方式、交互式的方式推动编程语言（例如Eve），但它们都没有解决关键的问题或赢得人们的认可。其中必然存在一些内在的原因为什么这样的语言无法取得成功。希望以上文字可以提供一些见解！

评论3：

Donald Knuth在1979年描述了Literate Programming的概念（https://en.wikipedia.org/wiki/Literate_programming）。

我之前公司的一位同事Raymond Chen在研究生期间是Donald Knuth的学生，他曾用过Donald Knuth的Literate Programming进行编程。

但他建议是不要采用这种编程方式。

原文：https://dev.to/drbearhands/should-programming-languages-be-made-for-ides-rather-than-humans-3dnf

作者：DrBearhands，软件工程师和数据科学家，他感兴趣的领域有人工智能、3D算法（图形、导航等）、逻辑、高性能计算/并行、功能编程和创新。

译者：弯月，责编：郭芮