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