KISS原理适用于编程语言设计吗？

KISS（“保持简单，愚蠢”或“保持简单，愚蠢”，请参见此处）是软件开发中的重要原则，尽管它显然起源于工程学。引用维基百科文章：

约翰逊（Johnson）为一组设计工程师提供了少量工具的故事就很好地说明了这一原理，而挑战是他们所设计的喷气飞机必须由普通机械师在战场上只能使用这些工具在战场上修理。因此，“愚蠢”是指事物的破坏方式与可用于解决问题的复杂程度之间的关系。

如果我想将此应用到软件开发领域，我将用“软件”替换“喷气飞机”，用“普通开发者”替换“普通技工”，用“在预期的软件开发/维护下”将“处于战斗状态”替换为“普通飞机”条件”（截止日期，时间限制，会议/中断，可用工具等）。

因此，一个普遍的想法是，应尝试使一个软件保持简单（如果省略逗号，则应保持简单愚蠢），以便以后可以轻松地对其进行操作。

但是，KISS原则也可以应用于编程语言设计吗？您是否知道专门为此原则设计的任何编程语言，即“允许普通程序员在正常工作条件下以最少的认知工作编写和维护尽可能多的代码”？

如果您引用任何特定的语言，那么可以添加指向某个文档的链接，该链接可以由语言设计者清楚地表达出来，那将是很好的选择。无论如何，我将有兴趣了解设计师的（记录的）意图，而不是您对特定编程语言的个人见解。

当我想到极简主义时，我想到了Lisp and Go。使用Lisp，您所拥有的只是函数和列表，这些函数和列表几乎就可以得到（很简单，还有更多，但是随便什么）。但是，我认为Go案例更有趣。

Go的设计很简单（读起来不错）。他们使用的术语是“功能正交性”，这意味着只有在提供真正独特的功能时，才应添加任何功能。这似乎是由于作者（想到Russ Cox和Rob Pike）参与Plan9引起的，这是对UNIX的重新构想，其思路简单。（如果您对最小化设计感兴趣，那么Rob Pike的有关简单窗口系统的论文将是不错的阅读。）

以下是一些简单的语法示例：

只有一个循环结构

循环可能类似于以下之一：

无限循环

for {
}

While循环

for <conditional> {
}

传统for循环

for i := 0; i < 10; i++ {
}

Foreach循环

// works for maps or arrays
for k, v := range arr {
}

多功能开关

switch {
    // cases must be evaluate to a boolean
}

switch <value> {
}

switch t := <value>; t {
    // can use t inside
}

多次回报

return val1, val2, ...

• 消除了抛出的需要（将错误作为最后的返回值传递）
• 消除了对out参数的需求
• 消除了对元组的需求

介面

type X interface {
    DoSomething()
    String() string
}

• 解决与泛型类似的问题
• 允许抽象

嵌入

type A struct {
    Thing string
}

type B struct {
    A // embeds A in B, so B.Thing refers to A.Thing
}

• 解决与继承相同的问题
• 无需上课

频道

可用于实现信号量

var c = make(chan bool, 1)
c<-true // semaphore lock
<-c // semaphore free

用于线程之间的消息传递

func produce(c chan<- bool) {
    for {
        c <- true
    }
}
func consume(c <-chan bool) {
    for {
        <-c
    }
}

var c = make(chan bool)
go produce(c)
go consume(c)

可用于处理异步事件

func async() chan bool {
    var c = make(chan bool)
    go doSomethingAsync(c)
    return c
}

// wait for long async process to finish
c := async()
select {
    case _ = <-c:
}

结论

我将不涉及语法的每个部分，但希望您能看到极简主义可以做什么。该语言之所以吸引人，不是因为它添加了大量的新功能，而是因为它使用了其他语言中最好的功能而没有任何额外的内容。

通常有一种解决问题的“最佳”方法。例如，在邮件列表中，许多用户抱怨没有泛型。经过讨论，他们意识到自己想做的所有事情都可以通过接口来完成。阅读有效的Go语言以获取惯用语法的示例。

KISS语言的好处是可以编写惯用的代码，因为代码样式受该语言的限制。例如，在Go中，您不能编写以下内容：

if <condition>
    statement;

您必须使用花括号：

if <condition> {
    statement;
}

语法中还有许多其他示例，这使阅读其他人的代码更加容易。

KISS语言相对于特色语言的优势：

• 更容易理解他人的代码
• 易于理解整个语言（C ++以难以理解而臭名昭著）
• 专注于算法，而不是语法

我认为Python的Zen会说明为什么Python是比我更好的简单语言：

Beautiful is better than ugly.
Explicit is better than implicit.
Simple is better than complex.
Complex is better than complicated.
Flat is better than nested.
Sparse is better than dense.
Readability counts.
Special cases aren't special enough to break the rules.
Although practicality beats purity.
Errors should never pass silently.
Unless explicitly silenced.
In the face of ambiguity, refuse the temptation to guess.
There should be one-- and preferably only one --obvious way to do it.
Although that way may not be obvious at first unless you're Dutch.
Now is better than never.
Although never is often better than *right* now.
If the implementation is hard to explain, it's a bad idea.
If the implementation is easy to explain, it may be a good idea.
Namespaces are one honking great idea -- let's do more of those!

编辑以回复@Giorgio

如您的问题所述，

“您是否知道专门为此原则设计的任何编程语言，即'允许普通程序员在正常工作条件下以最少的认知努力编写和维护尽可能多的代码'”

对我来说，Python是立即想到的。Python的设计直接响应了Perl的方法论，即著名的“做方法不止一种”。尽管这很棒，但允许程序员非常轻松地编写代码，但对维护没有帮助。在管理过一个用Perl编写的程序（我会承认，编写得很差）之前，我很欣赏Python强迫良好的编码实践和简洁的语言。

Python也不强迫您在编写程序时遵循一种特定的方法。我可以选择遵循严格的面向对象的编程风格，也可以编写一个简单的脚本以按顺序执行。不必初始化类，然后main()像强制在Java中那样调用该方法非常好。（此外，在Python中打印到stdout很棒，但这是一个相当空白的地方）。

最后，将包含扩展标准库的语言包括在内的“包含电池”方法非常好。我需要的大多数内容都已经包含在该语言中，而不是在某个外部存储库中寻找软件包。拥有该外部存储库也很好，但是不必为了进行基本操作而深入研究它确实很方便。

保持“简单性”的一个主要关键是认识到何时需要复杂性，并让系统中的各个部分可以最好地应对。只有一种对象引用，它不会在不可变值，可变值和实体之间进行区分，从而使Java变得“简单”，并不能消除区分值和实体的需要。它只是剥夺了程序员用来帮助他们的工具。

更一般而言，如果尝试使一种编程语言或框架功能支持多种使用情况，则应确保在任何情况下都不会出现不同的行为，但是编译器将无法分辨他们分开。在语言或框架中添加更多类型可能看起来很复杂，但是在许多情况下，实际上可能会使事情变得更容易。

例如，考虑一下C中围绕有符号和无符号类型的规则的混乱情况。这些规则的复杂性源于以下事实：某些代码使用无符号整数类型表示数字，而其他代码则使用它们表示包装代数环的成员。 （具体来说，整数集等于mod2ⁿ）。类型转换规则的行为有时适合于一种用法，有时适合于另一种用法。具有单独的包装和非包装类型会使整数类型的数量加倍，但可以简化与它们关联的规则：

• 任何大小的任何非环整数类型都可以分配给任何大小的环。一个环只能分配给相同或较小尺寸的环。

• 除涉及非环整数和环的关系运算符外，其他操作将隐式将整数转换为环类型。

• 环可以显式转换为数字或更大的环；无符号环的值是最小的非负整数，当将其加到环的零时，将产生环的值。有符号环的值是最小幅度的整数，当将其加到环的零时，将产生环的值，如果是平局，则首选负值。

• 除上述内容外，环仅限于使用相同尺寸或​​更小的环的操作。

• 对不同类型的非环形整数进行的操作应将数字转换为可以容纳任何一个操作数的所有值的类型，如果没有合适的类型，则应由编译器拒绝

定义环类型似乎会使整数类型的数量增加一倍，但会大大简化可移植代码的编写。对数字和环使用相同的无符号类型会减少类型的数量，但是会导致复杂的规则，从而几乎不可能编写高效的可移植代码。

可以说，Tcl是按照这些思路开发的。单个手册页上只能用12条规则描述整个语言。它非常简单且一致。

Tcl的创建者声称以下是最初的目标：

• 该语言必须是可扩展的：每个应用程序都必须非常容易地将其自身的功能添加到该语言的基本功能中，并且特定于应用程序的功能应该看起来很自然，就好像它们是从一开始就被设计成该语言一样。
• 该语言必须非常简单且通用，以便它可以轻松地与许多不同的应用程序一起使用，并且不限制应用程序可以提供的功能。
• 由于大多数有趣的功能将来自应用程序，因此该语言的主要目的是将扩展集成或“粘合在一起”。因此，该语言必须具有良好的集成功能。

来自“ Tcl的历史”-http : //www.tcl.tk/about/history.html

如果由于KISS而将某种语言固定在其设计中，那么它就不会增长。一种无法发展的语言将会消亡。

在下面的视频中， 盖伊·斯蒂尔（Guy Steele）巧妙地解释了必须允许编程语言的发展以及原因。如果您使用KISS，那么语言会如何增长，因为一旦发布，它的工具集就是固定的，永远不能更改。

盖伊·斯蒂尔（Guy Steele）在1998年ACM OOPSLA会议上关于“增长语言”的主题演讲讨论了设计一种可由其用户增长的编程语言的重要性和相关问题。

这是一个小时的视频，但值得一看。如果您不知道盖伊·斯蒂尔是谁，那么在谈论语言设计时就应该这么做。

我选择此视频作为答案，是因为我认为将KISS应用于语言设计通常是错误的，并且希望看到著名的语言设计人员的演讲将有助于您对语言设计的未来有更深入的了解。

既然您是来这里学习语言设计的，而我给了您一个不使用KISS的理由，那么我指出对语言设计有帮助的内容是很公平的。符号的认知范围

编辑

当我写上面的答案时，它是基于以下原因：如果只能用一组固定的工具维护引擎，那么我对语言设计的意义的重新表述是，语言一旦发布就不会改变。评论表明这不是什么意思。因此，让我提出这个修改后的答案，使其与修改后的理解更加一致。

如果人们研究符号的认知维度，那么就会发现与语言设计相关的竞争因素不仅是简单性，而且如果您过于专注于某一方面，您将遭受其他方面的困扰。关于高度关注简单性（KISS）的问题，并得到著名的语言设计人员的支持，我提交了Guy Steele的演讲，以表明试图使设计保持简单性会影响其他方面。更重要的是，我试图传达的是，您需要研究多个维度并权衡它们的利弊，而不仅仅是简单。

这是布鲁斯·麦金尼（Bruce McKinney）的《 Hardcore Visual Basic》的一句名言，它反过来使BASIC，Kemeny和Kurtz的设计师口口相传。强调我的。

每种计算机语言都有自己的感觉，自己的氛围，自己的精神。您无法真正定义这种精神，但是当您看到它时便知道它是什么。我认为“基本”是归因于爱因斯坦的声明的对立面：

使事情尽可能简单，但不要简单。

如果该报价是由Basic的原始设计师John Kemeny和Thomas Kurtz编写的，它将被进一步简化：

使事情变得简单。

这就是Visual Basic程序员所面对的矛盾。我们希望事情变得简单，优雅和直观，但事实并非如此。我们希望我们的程序为现实建模，但事实并非如此。我们希望我们的语言以我们的思维方式运作，而不是计算机或操作系统希望我们的思维方式运作，但是我们不愿意为此付出代价。

但是，KISS原则也可以应用于编程语言设计吗？您是否知道专门为此原则设计的任何编程语言，即“允许普通程序员在正常工作条件下以最少的认知工作编写和维护尽可能多的代码”？

弄清楚“简单”的含义是一件好事，因为在我看来，一种简单的编程语言是一种语法最少且功能很少的语言（Scheme，Forth，ML），它不能直接转换为您的定义。我认为您确实是在考虑使用RAD（快速应用程序开发）进行语言设计，并且其中有很多。例如，请参见以下StackOverflow线程：https : //stackoverflow.com/questions/66227/what-is-the-best-multi-platform-rad-language

我很惊讶没有人提到C，尽管它以几种重要的方式将简单性放在首位，但常常以一种激进的方式使程序员无法欣赏这种简单性：

• 没有隐藏的魔法。如果a + b使用C 编写，则可以保证它最多可以编译为一条汇编程序指令。

  即使在相对简单的语言（例如Java）中，一个简单的语句（例如a + b，变量为字符串）也可能需要几微秒的时间。其他语言在C ++的极端示例中为此添加了很多东西，在这些例子中，a + b可能会重载而使粉红色的大象出现。在C语言中不是这样：如果不是函数调用，则不会超过几纳秒。性能的这种可预测性是C的关键特征之一，并且肯定是一种简单形式。

• 数据类型非常简单，同时仍描述了您可能希望在内存中构建的所有有趣数据结构：只有CPU可以处理的基本类型+聚合（struct）+重复（数组）+引用（指针） ）。

  在这方面，各种基于Lisp的语言的确比C语言简单得多。但是，它们并不试图允许程序员像C那样自由地操纵内存。

• 功能的正交性：您可以自由组合功能，它们将按预期方式协同工作。许多语言通过允许某些构造仅出现在已定义的上下文中而使此失败。

  以C和C ++中的可变长度数组为例：C允许运行时长度无处不在，而扩展C ++标准的最宽松的请求仅允许它们在某些情况下使用，例如自动数组，甚至只在第一维中。这使C可以处理只有在运行时才知道的真正的多维数组，而C ++程序员则可以data[k + (j + i*lineLength)*lineCount]一遍又一遍地写。

  指针的另一个例子是：C语言中的数据指针实际上仅是一个包含其他变量的内存地址的变量。由于指针本身是变量，因此双指针是定义明确的东西。即给什么int和int*是，它是清楚int**的必须。将此与C ++参考进行比较，在这些参考中您完全不知道and ！int&&的含义。intint&

的确，正是这种简单性使C赢得了如此多的仇恨：这种语言的简单性给程序员带来了比对他们有益的更多的自由，从而导致了许多行为不确定和指针处理不当的问题。尤其是正交性的简单性，使程序员可以像定义这样的变量那样定义变量，int (*array[m])(struct foo* (*arg)[n])这往往使读者感到头疼，因为真正复杂的东西可以通过一些简单特征的自由组合以非常简洁的形式表示。这是C擅长的简单类型，并使其具有成为一种难于使用的语言的声誉。

而且，这种语言的简单性迫使程序员比功能更丰富的语言编写更多的代码，从而为错误的产生提供了更多沃土。但是，如果您的主要目标是对一台真正的计算机而不是某些虚拟机进行编程，那么它仍然是最简单的高级语言。

Java Wikipedia-尽管在Wikipedia中没有明确说明，但简单化被多次提及，并且是最初的设计目标，因为在当时，唯一的一种真正的OO能力（宽松地使用术语）是C ++，众所周知，C ++功能强大但是对于那些粗心的人有很多陷阱。

JVM旨在作为简化跨平台开发的一种方式，并且“写一次就可以在任何地方运行”成为Java的几年来的口号-同样，其目的是使框架易于部署。

我相信C＃属于该语言的简化类别。

嗯...这实际上是一个很难回答“积极”的问题，因为当我想到编程语言设计的简单性（以及使用什么“更容易”的方法）时，我立即想到：

1. 代码的“可读性”-语言对对象，方法等的封装程度。
2. 语言API和接口的一致性。

有许多的这些事以及语言-但什么浮现在我的头上是一门语言不 把事情做好“作为一种编程语言”：PHP。

[免责声明-我已经写了PHP，对于简单的Web项目，PHP仍然是我的“语言”。这是对爱的批评...]

首先，PHP在通常运行于Web服务器的环境中表现良好。它易于设置，易于维护等。

我在PHP上苦苦挣扎的地方：当您想做“不寻常的”事情时-您通常不经常做的事情（在我想到它正在消耗SOAP Web服务的情况下-不是我要做的事情） PHP做了大量工作），您面临两个选择：

1）对PHP的各种开源扩展。PHP对象模型足够宽松，在各个库之间（从开发人员到开发人员）接口设计也不一致。当遇到有人使用您从未听说过的库的一组代码时，您会花费大量时间弄清楚“这到底有什么用”，因为该语言允许松散地创建API /库。

2）“内置”功能-其中很多。我经历了一些麻烦，要么找到另一个库，要么实现了一些功能，后来以某种方式偶然发现impossiblyfound_basefunction()

我认为，简单就是一致性。

现在，至少在您认为编程语言是CPU指令集的抽象层等情况下，KISS编程语言的方法才是一个有趣的概念。如果您没有更紧密地定义“ KISS”，那么。我只是在这里说，牛车是最完整地应用于汽车的KISS。

现在，对KISS的另一种解释可能是“精巧地完成工作，没有多余的装饰，也不过分复杂”。特别是有人可能会争辩说，对于类似的事物，应该没有太多的特定情况。等等。通常，数学非常擅长将事物归结为本质，而且-奇怪的是-数学家也花了一些时间思考编程和计算机。

对于编程，存在2个非常著名的抽象模型：

• 一种是图灵机，它定义了一台机器和一个简单的教学模型，该模型可以计算计算机可以做的所有事情。
• 另一个是Church等人的Lambda微积分。等 功率相等

有趣的是：尽管图灵机的布局非常简单，但它不是一个易于操作的系统，我认为它不符合“智能KISS”的条件。但是Lambda演算与我们所知道的编程语言有更多关系-以及Lambda演算的Lisp和Scheme开拓性功能，它已经进入了许多语言。

Lisp和Scheme确实非常简单，至少在语法方面如此。语法是编程语言的一个主要问题（这可能就是为什么它们一直被重新发明的原因）。对于C ++而言，人脑几乎无法预测编译器如何解释某些源代码行。）

Lisps通过为命令引入一种常见形式来完全降低语法复杂性：

(command param1 param2 ...)

这可以是方法调用，例如

(max 1 2 3 4)

以及if分支，循环等

(if (< 1 2) 
    (write 4)
    (write 5))

（这里的所有代码都是伪Lisp / Dialect不可知的）

表格

(command param1 param2 ...)

也可以解释为列表

(item1 item2 item3)

这就是Lisps简单和美观的基础。由于嵌套列表（如if语句示例中的内容）构成树，因此机器和机器前的人员都可以轻松理解它们。

Lisps的另一个功能是宏，这里不再赘述，但是由于普通函数调用和“语法（例如循环，变量声明等）之间没有语法上的区别，因此解析器必须处理的其他所有内容编程语言），则可以创建自己的语法。宏本质上是对构成程序的树的操作。

我认为Lisp可以进行编程。您可以通过使用宏来操纵语法，这导致Lisp动态发展的现象。需要一个新的语言功能，例如-可以说面向对象-只需编写带有宏的OOP系统！

虽然C具有OOP功能（C ++，Obj。C）被扩展了大约2倍，但是Lisp被扩展了多次，最终还是有赢家。

这是关于Lisp的另一个怪癖，它在发展（有关Lisp有趣的新突变，请参见Clojure和Clojurescript）。

Lisps因其具有KISS的特性而受到某些人的青睐。就像Fogus在他的教育语言蓝图中概述的一样（http://blog.fogus.me/2013/01/21/enfield-a-programming-language-designed-for-pedagogy/）

首先，我坚信，在学习新的知识以及有时会遇到复杂的主题时，完全不利于学生使用琐碎的语法规则。因此，Enfield的设计采用了最少的语法规则，并且比像Lisp这样的语法要少得多。