指导理念
1. 为人服务的编程语言
编程语言是人们与计算机交谈的方式。 计算机很乐意说任何明确的语言。 我们之所以有高级语言，是因为人们无法处理机器语言。 编程语言的目的是防止我们可怜、脆弱的人类大脑被太多的细节淹没。
建筑师知道有些设计问题比其他问题更为平常。 一些最清晰和最抽象的设计问题是桥梁的设计。 在这种情况下，您的工作就是用尽可能少的材料走完所需的距离。 另一方面是椅子设计。 椅子设计师应该花时间思考人们的屁股。
软件开发也有类似的差异。 设计通过网络路由数据的算法是一个很好的抽象问题，就像设计桥梁一样。 而设计编程语言就像设计椅子：你必须应对人类的弱点。
这对于我们大多数人来说是很难意识到的。 对我们大多数人来说，设计优雅的数学系统听起来比迎合人类弱点更有吸引力。 数学优雅的作用是某种程度的优雅使程序更容易理解。 但这并不全是为了优雅。
当我说语言的设计应该适应人类的弱点时，我并不是说语言应该为糟糕的程序员设计。 事实上，你应该为最好的程序员设计软件，但即使是最好的程序员也有其局限性。 我认为没有人会喜欢用所有变量都用带有整数下标的字母“x”表示的语言进行编程。
2. 为自己和朋友设计
如果你看看编程语言的历史，大多数最好的语言都是设计给自己的作者使用的，而大多数最糟糕的语言都是设计给其他人使用的。
当语言是为其他人设计的时，它总是特定的一群人：人们并不像语言的创造者那么聪明。 这就是你如何获得对你说话居高临下的舌头的方法。 Cobol 是最突出的例子，但大多数语言都充满了这种精神。
这与语言的高级程度无关。 C 的级别相当低，但它是为作者使用而创建的，这就是黑客喜欢它的原因。
为糟糕的程序员设计语言的论点是，糟糕的程序员比优秀的程序员多。 也许确实如此。 但这一小部分优秀程序员编写的软件却多得不成比例。
我的问题是，如何创建一种能够吸引最优秀黑客的语言？ 在我看来，这个问题与“如何创建一种好的编程语言？”的问题相同，但即使不是，它至少是一个有趣的问题。
3.给程序员尽可能多的控制权
许多语言（尤其是为其他人设计的语言）就像保姆一样：它们试图警告您远离他们认为对您没有用的东西。 我持相反的观点：给程序员尽可能多的控制权。
当我第一次学习 Lisp 时，我最喜欢的是我们平等地交谈。 在我当时学过的其他语言中，有一种语言，也有我用那种语言编写的程序，它们是完全独立存在的。 但在 Lisp 中，我编写的函数和宏与语言本身编写的函数和宏相同。 如果我愿意的话，我可以重写该语言本身。 它具有与开源软件相同的吸引力。
4. 简洁是才华的姐妹
简洁性被低估，甚至被鄙视。 但如果你深入观察黑客的内心，你就会发现他们确实喜欢简洁。 您有多少次听到黑客津津有味地谈论如何在 APL 中仅用几行代码就可以做出惊人的事情？ 我想真正聪明的人实际上喜欢关注这一点。
我相信几乎任何能让程序变得更短的东西都是一件好事。 库函数应该有很多，凡是能隐式的都应该如此； 语法应该更简洁； 甚至实体名称也应该很短。
不仅仅是程序应该短。 手册也应该简短。 手册的很大一部分充满了解释、免责声明、警告和特殊情况。 如果您需要缩短手册，最好的选择是纠正需要大量解释的语言。
5. 认识什么是黑客攻击
许多人希望黑客成为数学，或者至少是类似于科学的东西。 我认为黑客更像是建筑。 建筑是关于物理学的，因为建筑师需要设计一座不会倒塌的建筑，但建筑师的真正目标是创造一座伟大的建筑，而不是在静力学领域做出发现。
黑客喜欢的是创建出色的程序。 我认为，至少在我们自己的想法中，我们应该记住，编写伟大的程序是一件很棒的事情，即使这项工作不容易转化为科学论文的通常知识货币。 从智力的角度来看，设计一种程序员喜欢的语言与设计一种糟糕的语言同样重要，因为它体现了你可以发表论文的想法。
开放式问题
1. 大型图书馆如何组织？
库正在成为编程语言的重要组成部分。 它们变得如此之大，以至于可能很危险。 如果在库中找到一个满足您需要的函数比您自己编写该函数需要更长的时间，那么所有代码都没有任何作用，只会让您的手册变得更厚。 （符号手册就是一个例子。）所以我们必须解决图书馆组织问题。 理想情况下，设计它们以便程序员可以猜测哪个库函数是合适的。
2. 人们真的害怕前缀语法吗？
这是一个悬而未决的问题，我已经思考了好几年，但仍然不知道答案。 前缀语法对我来说似乎完全自然，除了它在数学中的使用。 但 Lisp 不受欢迎的大部分原因可能只是由于不熟悉的语法……如果确实如此，我们是否应该对此采取行动则是另一回事。
3. 您需要什么服务器软件？
我认为未来 XNUMX 年内编写的大多数应用程序都将是 Web 应用程序，从某种意义上说，程序将驻留在服务器上并通过 Web 浏览器与您进行通信。 为了编写这样的应用程序，我们需要新的东西。
其中之一是支持发布服务器应用程序的新方法。 服务器软件不会像桌面软件那样每年发布一到两个大版本，而是会通过一系列小的更改来发布。 您每天可能会发布五个或十个版本。 每个人都将始终拥有最新版本。
你知道如何设计可维护的程序吗？ 服务器软件必须设计为可更改的。 您应该能够轻松地更改它，或者至少知道微小的更改意味着什么以及重要的是什么。
服务器软件中另一个有用的东西是交付的连续性。 在网络应用程序中，您可以使用类似的东西 在无状态的网络会话世界中获得例程的效果。 如果该功能不太昂贵，那么保持供应的连续性可能是值得的。
4. 还有哪些新的抽象有待发现？
我不确定这个希望有多合理，但就我个人而言，我真的很想发现一种新的抽象 - 一些可以与一流函数或递归或至少默认参数一样有意义的东西。 也许这是一个不可能实现的梦想。 这样的事情往往不被发现。 但我并没有失去希望。
鲜为人知的秘密
1.您可以使用任何您想要的语言
以前，创建应用程序意味着创建桌面软件。 在桌面软件中，人们普遍倾向于使用与操作系统相同的语言来编写应用程序。 所以十年前，编写软件一般意味着用 C 语言编写软件。最终，传统演变了：应用程序不应该用不寻常的语言编写。 这种传统已经发展了很长时间，以至于经理和风险投资家等非技术人员也学会了这一点。
服务器软件彻底破坏了这种模式。 通过服务器软件，您可以使用任何您想要的语言。 几乎没有人理解这一点（尤其是经理和风险投资家）。 但有些黑客明白这一点，这就是为什么我们听说 Perl 和 Python 等独立语言。 我们没有听说过 Perl 和 Python，因为人们使用它们来编写 Windows 应用程序。
这对我们这些对编程语言设计感兴趣的人来说意味着什么，我们的工作有潜在的受众。
2.速度来自分析器
语言开发者，或者至少是语言实现者，喜欢编写生成快速代码的编译器。 但我认为这并不是让语言对用户来说变得更快的原因。 Knuth 很久以前就指出，速度仅取决于几个瓶颈。 任何尝试过加速程序的人都知道，你无法猜测瓶颈在哪里。 探查器就是答案。
语言开发者正在解决错误的问题。 用户不需要基准测试来快速运行。 他们需要一种能够显示程序的哪些部分需要重写的语言。 此时，实践中就需要速度。 因此，如果语言实现者将优化编译器的一半时间花在编写一个好的分析器上，也许会更好。
3.您需要一款能够让您的语言不断发展的应用程序
这可能不是最终的事实，但最好的语言似乎是随着它们所使用的应用程序而演变的。 C 是由需要系统编程的人编写的。 Lisp 的设计部分是为了符号微分，麦卡锡非常渴望开始，甚至在 1960 年第一篇 Lisp 论文中开始编写微分程序。
如果您的应用程序解决了一些新问题，这尤其有用。 这促使你的语言拥有程序员想要的新功能。 就我个人而言，我有兴趣编写一种适合服务器应用程序的语言。
[在讨论中，Guy Steele 也提出了这一点，并补充说应用程序不应包含为您的语言编写编译器，除非您的语言旨在编写编译器。]4. 该语言必须适合编写一次性程序。
您知道一次性程序的含义：当您需要快速解决一些有限的问题时。 我相信，如果你环顾四周，你会发现许多严肃的项目最初都是一次性的。 如果大多数项目一开始都是一次性的，我不会感到惊讶。 因此，如果你想创建一种适合编写一般软件的语言，那么它也应该适合编写一次性程序，因为这是许多程序的初始阶段。
5. 语法与语义相关
传统上认为语法和语义是非常不同的东西。 这听起来可能令人震惊，但事实并非如此。 我认为你想在你的程序中实现什么与你如何表达它有关。
我最近与 Robert Morris 交谈，他指出运算符重载是中缀语法语言获胜的一大优势。 在具有前缀语法的语言中，您定义的任何函数实际上都是运算符。 如果你想添加一个你自己编造的新类型的数字，你可以简单地定义一个新函数来添加它。 如果您在具有中缀语法的语言中执行此操作，您会发现使用重载运算符和调用函数之间存在很大差异。
随着时间的推移，想法会回来
1.新的编程语言
回顾 1970 世纪 XNUMX 年代，开发新的编程语言非常流行。 现在情况并非如此。 但我相信服务器软件将再次带回创建新语言的时尚。 使用服务器软件，您可以使用任何您想要的语言，因此，如果有人创建了一种看起来比其他语言更好的语言，就会有人决定使用它。
2. 时间共享
理查德·凯尔西（Richard Kelsey）提出了这个想法，时机又到了，我完全支持它。 我的猜测（微软也是如此）是，大量计算将从桌面转移到远程服务器。 换句话说，时间共享又回来了。 我认为这需要语言层面的支持。 例如，Richard 和 Jonathan Reeves 为实现方案 48 中的进程调度做了很多工作。
3.效率
最近，计算机似乎已经足够快了。 我们越来越多地听到有关字节码的信息，这至少对我来说意味着我们拥有一些储备能力。 但我认为对于服务器软件，我们没有。 有人必须为运行该软件的服务器付费，而服务器每台机器可以支持的用户数量将是其资本成本的除数。
我认为效率很重要，至少在计算瓶颈方面是这样。 这对于 I/O 操作尤其重要，因为服务器应用程序执行大量此类操作。
最终，字节码可能不是答案。 目前，Sun 和微软似乎正在字节码领域展开正面交锋。 但他们这样做是因为字节码是将自身嵌入到进程中的方便位置，而不是因为字节码本身是一个好主意。 事实可能是，整个战斗将被忽视。 这会很有趣。
圈套和圈套
1. 客户
这只是一个猜测，但唯一受益的应用程序是那些完全服务器端的应用程序。 设计基于每个人都会有客户的假设运行的软件就像基于每个人都会诚实的假设来设计一个社会一样。 这肯定会很方便，但你必须假设它永远不会发生。
我认为支持网络的设备将会快速增加，我们可以假设它们将支持基本的 html 和表单。 您的手机上有浏览器吗？ 您的 PalmPilot 有电话吗？ 你的黑莓手机会有更大的屏幕吗？ 您可以通过您的游戏机访问互联网吗？ 从你的手表上？ 我不知道。 而且我不必知道是否所有内容都会在服务器上。 将所有的大脑都放在服务器上会更可靠。 。
2. 面向对象编程
我意识到这是一个有争议的说法，但我认为 OOP 并不那么重要。 我认为对于需要特定数据结构的特定应用程序（如窗口系统、模拟、CAD 系统）来说，这是一个合适的范例。 但我不明白为什么它应该适合所有程序。
我认为大公司的人们喜欢 OOP，部分原因是它让很多事情看起来很可行。 自然地可以表示为整数列表，现在可以表示为一个拥有各种脚手架、喧嚣的教室。
OOP 的另一个吸引人的特性是方法为您提供了一些一流函数的效果。 但这对于 Lisp 程序员来说并不是新闻。 当您拥有真正的一流函数时，您可以以适合手头任务的任何方式简单地使用它们，而不是将所有内容都推入类和方法的样板中。
我认为这对于语言设计来说意味着你不应该将 OOP 嵌入得太深。 也许答案是提供更通用、更基础的东西，让人们将任何对象系统设计为库。
3、组委会设计
如果你的语言是由委员会设计的，那么你就会陷入困境，而不仅仅是因为众所周知的原因。 大家都知道，委员会往往会创建出笨拙、不一致的语言设计。 但我认为最大的危险是他们不冒险。 当一个人负责时，他会承担委员会永远不会同意承担的风险。
你需要冒风险来创造一门好语言吗？ 许多人可能怀疑语言设计必须非常接近传统智慧。 我敢打赌事实并非如此。 在人们所做的其他事情中，回报与风险成正比。 那么为什么语言设计应该有所不同呢？
来源： habr.com