如果我去发明一门面向21世纪的编程语言

原文地址：If I were to invent a programming language for the 21st century

渣翻译，有英文阅读能力的可以去原网址阅读，正文部分的括号内是译者的尝试补充说明

自豪地采用谷歌翻译

在21世纪已经发明了相当多的编程语言，Swift, Kotlin Go可能是最受欢迎的了。然而，21世纪的编程语言设计并无任何明显的特征。这些语言带给我们最好的事情是（轻松完成工作后）可以度过一个周末，并声称学习到一个很酷的新事物，然而实际上并没有学到（相对于编程语言特效而言）新的东西。他们都是由其他语言的一些特性组合而成的，比如Object-C, Java or C.

虽然“不是新的”本身确实是一种有价值的特征，问题是，他们确实是面向21世纪的编程语言吗，或者说他们仅仅反映了20世纪糟糕的编程习惯？

如果我去发明一门语言，我不会试图修复过去(编程语言的特性)，我将尝试发明一门语言不仅在真实的现代社会工作良好而且适当进化经得起时间考验。如果这需要激进的设计决策，亦是如此。

1. 通顺的语法!(Down with the syntax!)

现代语言语法反映了粉笔和黑板的自由陷入了ASCII的束缚。虽然像算术符号和括号这样的符号的某些元素或多或少都是惯用的，除了省去按下电传打印按钮的努力之外，有些是完全没有任何理由的。

类型不再是问题，我们没有必要取猜测我们使用的语法，比如这样：*(($:@(<#[), (=#[), $:@(>#[)) ({~ ?@#)) ^: (1<#)*确实简洁而富有表现力。写作也很有趣。 顺便说一句，这一行是实际语言中的实际代码。

但是这并没有可读性，更重要的是，对于google和stackoverflow而言非常不友好。

隐藏的函数名称也是如此，返回代码约定，以及具有模糊含义的属性，他们过去很好地为我们服务，节省我们的打卡空间（纸带打孔编程时代使用的的打孔纸），现在他们已经可以退休了。

例如这样：

FILE * test_file = fopen("/tmp/test.txt", "w+")

应该写成这样的形式：

create file /tmp/test.txt for input and output as test_file

我们不需要括号，引号，星号和分号（除非它们真的帮助我们更好地表达事物），语法高亮应该可以正常工作而不是使用语法标识。

21世纪廉价的事物：解析时间，计算机内存，在线搜索。相反变得不廉价的事物：开发时间，程序员的记忆，在线学习语言细节的努力。这种类型的写作应该有助于使用更便宜的东西而不是更昂贵的东西。

2. 通顺的原生类型!(Down with the native types!)

你可能知道对于Javascript而言有这样的表现：

> 10.8 / 100
0.10800000000000001

当然，它不是特定于JavaScript的。事实上，它的表现并没有问题，它是完全遵循IEEE754标准的实现。IEEE754标准几乎是在任何架构中实现浮点数的方式。考虑到我们试图将无限量的实数压缩成32位，64位甚至256位，实际上并没有那么糟糕。

数学家认为不可能的是，工程师通过权衡可能性来实现理智。IEEE浮点数不是，事实上，对于全部的数字，数学要求实数相加具有相关性。浮点数和双精度的数值并不总是拥有这个属性。数学要求实数才能包含所有整数， 即使对于相同大小的float和uint32_t，情况也是如此。数学要求实数具有元素零，那么，至少在这方面IEEE标准超出了预期，因为浮点数有两个零元素而不是一个（可能说的是+0和-0，没理解）。

而且它不仅仅是浮点数。原生整数并没有好多少。你知道当你进行16-bit（两个字节）数的相加时发生了什么吗？

0xFFFF + 0x0001

好吧，实际上大多数人都不知道，直觉说，溢出的数字应该是0x0000。但是，任何标准都没有规定这个细节点;它通常是用C语言和x86家族的处理器操作的。可能的结果是0xFFFF， 或触发中断，或者在特殊位置存储一些特殊位，表示发生了溢出。

这些在标准中并没有指明，虽然浮点数只是标准的，但他们是完全无法预测的。我建议用于数值计算的是定点任意大小的数据类型，在下溢，溢出和精度损失方面具有标准定义的行为。期望如下例子：

1.000 / 3.000 = 0.333
0001 + 9999 = overflowed 9999
0.001 / 2 = underflowed 0

当然，您不必实际编写所有尾随零，它们应该由数据类型定义隐时的添加。但您应该能够自己选择该类型的最大和最小边界，而不仅仅依赖于当前处理器的体系结构（架构）。

这样做会不会损耗性能？是的，但是现实是：你需要经常编写高性能计算程序吗？我想，除非你在一个狭窄的研究和工程领域工作，而这种领域并不常见。如果你这样做，你必须使用专门的硬件和编译器。我只是假设，一个典型的21世纪程序员不必经常解决微分方程。

话虽这么说，过去的快速，复杂和不可预测的原生类型不应该是一种选择或者说不是默认的？

3. 通顺的元编程!(Down with the metalanguaging!)

有很多精彩的语言设计不是为了完成任务，而是创建完成任务的语言。Racket， Rebol，Forth等等名字有很多。我喜欢它们，使用它们是一种纯粹的喜悦。但正如你可能猜到的那样，有趣并不是使语言普遍流行的原因。

语言杠杆作用，为任务创建新的子语言的能力是一种强大的力量，当您自己研究所有这些时，它可以获得巨大的收益。不幸的是，如果你用这样的语言编写了代码而想要让其他人理解的话，你就必须教会其他人这种语言，那就是它变得丑陋的时候。

人们通常对完成任务感兴趣，而不是在事情完成后学习他们不得不忘记的语言。对于其他人来说，学习你的语言只是一种难以获得然而，学习一些共同和标准化的东西是对生活的投资回报的努力。因此，人们更倾向用他们的理解去重新理解你的语言而不是去学习它。你去了：单一领域的无数方言;人们争论美学，意识形态，建筑和所有无关紧要的事物;百万行代码只是为了在几个月内被遗忘

Lisp语言的开发者们在80年代完成了所有这些工作。他们发现语言的实际部分越多越标准化 - 越好。他们提出了Common Lisp。

结果是：出现了有1153页文档组成的INCITS226-1994标准。但它被17年后的1337页文档组成的C++ISO/IEC 14882:2011标准所打败。**C ++**不得不携带一大堆历史包袱和遗产，但并不总是那么大。 Common Lisp是从头开始创建的。

编程语言不应该那么大。一点也不。只是它应该有一个合适的标准库充满了所有的好东西，所以人们不必重新发明它们。

很难平衡编程语言的庞大特性和适用特性。我们必须用C ++来学习这一点。我认为，为了正确地平衡事物，21世纪的语言应该更具有领域特色。由于业务应用程序目前是最大的混乱，也许它应该解决这个问题，而不是一些游戏开发或网页设计。

因此……

21世纪的语言应该是面向商业的，类似于英语，而不是依赖于本土类型。

最令人兴奋的是，我们已经拥有了这样的语言！你觉得它是什么？

Kotlin, Haskell, Go, Rust, Swift, Julia, Fortran, COBOL, Assembly

上面是一个投票项，想要投票的可以去原网址试试。