KISSの原則はプログラミング言語の設計に適用されますか？

KISS（「シンプルに保つ、バカにする」または「シンプルにバカにする」、例えばこちらを参照）は、明らかに工学に由来するものですが、ソフトウェア開発の重要な原則です。ウィキペディアの記事から引用：

原則は、ジョンソンが設計エンジニアのチームにいくつかのツールを渡したという物語によって最もよく例証されています。したがって、「愚かな」とは、物事が壊れる方法と、それらを修正するために利用できる洗練度との関係を指します。

これをソフトウェア開発の分野に適用したい場合、「ジェット機」を「ソフトウェアの一部」に、「平均メカニック」を「平均開発者」に、「戦闘条件下」を「予想されるソフトウェア開発/保守中」に置き換えます条件」（期限、時間の制約、会議/中断、利用可能なツールなど）。

したがって、後で作業しやすくするために、ソフトウェアの一部をシンプルに（またはコンマを省略した場合は単純な愚かさ）維持することを試みることが一般に受け入れられている考えです。

しかし、KISSの原則はプログラミング言語の設計にも適用できますか？この原則を念頭に置いて特別に設計されたプログラミング言語、つまり「平均的な労働条件の下で平均的なプログラマーができるだけ少ない労力でできるだけ多くのコードを記述および維持できるようにする」ことを知っていますか？

特定の言語を引用する場合、この意図が言語設計者によって明確に表現されているドキュメントへのリンクを追加できると便利です。いずれにせよ、特定のプログラミング言語に関する個人的な意見ではなく、デザイナーの（文書化された）意図について学ぶことに興味があります。

ミニマリズムについて考えるとき、私はLispとGoについて考えます。Lispを使用すると、関数とリストだけが得られます。これは、できるだけ簡単です（まあ、もう少しありますが、何でも）。ただし、Goのケースの方が興味深いと思います。

Goはシンプルになるように設計されています（それはまともな読みです）。彼らが使用する用語は「機能の直交性」です。つまり、機能は本当にユニークなものを提供する場合にのみ追加する必要があります。これは、著者の（Russ CoxとRob Pikeが思い浮かぶ）Plan9の関与に起因するようです。Plan9は、単純さを念頭に置いたUNIXの再考でした。（最小限の設計に興味がある場合は、単純なウィンドウシステムに関するRob Pikeの論文が参考になります。）

構文の簡単な例を次に示します。

1つのループ構造のみ

ループは次のいずれかになります。

無限ループ

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, ...

• スローする必要がなくなります（エラーを最後の戻り値として渡します）
• 出力パラメータの必要がなくなります
• タプルの必要性を取り除きます

インターフェース

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:
}

結論

構文のすべての部分を説明するつもりはありませんが、できればミニマリズムが何をすることができるかを見てください。この言語が興味深いのは、大量の新しい機能が追加されたためではなく、他の言語の最高の機能を何も追加せずに使用しているためです。

通常、問題を解決する「最良の」方法が1つあります。たとえば、メーリングリストでは、多くのユーザーがジェネリックがないと苦情を言っています。話し合った後、彼らはやりたいことはすべてインターフェイスでできることに気付きます。慣用的な構文の例については、効果的な説明を参照してください。

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での標準出力への印刷は素晴らしいですが、それはかなりヌル点です）。

最後に、言語に拡張標準ライブラリを含める「Batteries Included」方法論は素晴らしいです。パッケージ用の外部リポジトリを探す代わりに、必要なもののほとんどはすでに言語に含まれています。外部リポジトリがあることもいいですが、基本的な操作を行うためにそれを掘り下げる必要がないのは本当に便利です。

「シンプルさ」を維持するための重要な鍵は、複雑さがいつ必要になるかを認識し、それに対処できるシステムの部分を持つことです。不変値、可変値、およびエンティティを区別しない単一の種類のオブジェクト参照があると、Javaが「単純」になり、値とエンティティを区別する必要がなくなります。単にプログラマーからツールを奪い、支援するだけです。

より一般的には、プログラミング言語またはフレームワーク機能で複数の使用事例をサポートしようとしている場合、異なる使用事例で異なる動作が適切になるような状況が発生しないことを確認する必要がありますが、コンパイラーはそれを認識できませんそれらを離れて。言語やフレームワークにさらに型を追加すると複雑に見えるかもしれませんが、多くの場合、実際に物事が簡単になるかもしれません。

たとえば、Cの符号付きおよび符号なしの型を取り巻く規則の混乱を考えてみましょう。これらの規則の複雑さは、コードによって符号なし整数型を使用して数値を表現し、他のコードでそれらを使用してラッピング代数リングのメンバーを表現することから生じます（具体的には、整数合同mod2ⁿ）。型変換ルールは、一方の使用に適した方法で動作する場合と、他方の使用に適切な方法で動作する場合があります。ラッピング型と非ラッピング型を別々にすると、整数型の数は2倍になりますが、それらに関連付けられたルールは単純化できます。

• 任意のサイズの任意の非リング整数型を任意のサイズのリングに割り当てることができます。リングは、同じサイズまたはそれより小さいサイズのリングにのみ割り当てることができます。

• 非リング整数とリングを含む関係演算子以外の操作は、整数を暗黙的にリング型に変換します。

• リングは、数字またはより大きなリングに明示的にキャストできます。符号なしのリングの値は、リングのゼロに追加されたときにリング値を生成する最小の非負整数です。符号付きリングの値は、リングのゼロに追加されたときにリング値を生成する最小の大きさの整数であり、ネクタイの場合は負の値が優先されます。

• 前述の場合を除き、リングは同じサイズ以下のリングでの操作に限定されます。

• 異なるタイプの非リング整数に対する操作は、いずれかのオペランドのすべての値を収容できるタイプに数値をアップキャストするか、適切なタイプが存在しない場合はコンパイラーによって拒否される必要があります

リング型を定義すると、整数型の数が2倍になるように見えますが、移植可能なコードの記述は大幅に簡素化されます。数字とリングに同じ符号なしの型を使用すると、型の数は減りますが、効率的な移植可能なコードを書くことがほぼ不可能になる複雑なルールにつながります。

おそらく、Tclはこれらのラインに沿って開発されました。言語全体は、1つのmanページの12のルールでのみ説明できます。それは非常にシンプルで一貫しています。

Tclの作成者は、当初の目標として以下を主張しました。

• 言語は拡張可能である必要があります：各アプリケーションが独自の機能を言語の基本機能に追加することは非常に簡単である必要があり、アプリケーション固有の機能は最初から言語に設計されているかのように自然に見える必要があります。
• 言語は、多くの異なるアプリケーションで簡単に機能し、アプリケーションが提供できる機能を制限しないように、非常にシンプルで汎用的でなければなりません。
• 興味深い機能のほとんどはアプリケーションから提供されるため、この言語の主な目的は、拡張機能を統合または「接着」することです。したがって、言語には統合のための優れた機能が必要です。

「からのTclの歴史」 - http://www.tcl.tk/about/history.html

KISSのために言語が設計で修正されている場合、言語は成長できません。成長できない言語は死ぬでしょう。

次のビデオでは、 Guy Steeleが、プログラミング言語の成長を許可する必要があることとその理由を巧みに説明しています。KISSを適用すると、言語セットがリリースされるとツールセットが修正され、変更できなくなるため、言語をどのように拡張できますか。

1998年の「言語の成長」に関するACM OOPSLAカンファレンスでのGuy Steeleの基調講演では、ユーザーが成長できるプログラミング言語の設計の重要性と問題について説明しています。

1時間のビデオですが、見る価値はあります。ガイ・スティールが誰なのかわからない場合は、言語設計について話すときに本当にすべきです。

私がこのビデオを答えとして選んだのは、KISSを一般的な言語設計に適用することは間違っていると信じているからです。

あなたがここに来て言語設計について学び、KISSを使用しない理由を説明したので、言語設計に役立つと思うものを指摘するのは公平です。表記の認知的次元

編集

上記の答えを書いたとき、それは次の理由に基づいていました：エンジンが固定されたツールセットでのみ維持できる場合、言語設計に関するその意味の私の再定式化は、一度リリースされた言語は変更できないということです。コメントは、それが意図したものではなかったことを示しています。したがって、修正された理解に沿った、より修正されたこの修正された答えを出しましょう。

表記法の認知的側面を見ると、単純ではなく、言語設計に関連する多くの競合する側面があることがわかります。1つに集中しすぎると、他の側面で苦しむことになります。シンプルさ（KISS）の良さに重点を置き、著名な言語デザインの人々に支えられているという質問で、Guy Steeleのスピーチを提出し、デザインをシンプルに保つことは他の側面に影響を与えることを示しました。さらに重要なことは、単純さだけでなく、多くの側面を見て、それらの長所と短所を比較検討する必要があることを伝えようとしていることです。

Bruce McKinneyのHardcore Visual Basicからの引用は、BASIC、Kemeny、Kurtzのデザイナーの口に言葉を入れています。私を強調します。

すべてのコンピューター言語には、独自の雰囲気、独自の雰囲気、独自の精神があります。あなたは本当にこの精神を定義することはできませんが、それを見たときにそれが何であるかを知っています。Basicは、Albert Einsteinに起因する声明のアンチテーゼと考えています。

物事を可能な限りシンプルにしますが、シンプルにすることはありません。

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 + bCで記述した場合、最大で単一のアセンブラー命令にコンパイルされるという保証があります。

  Javaのような比較的単純な言語でも、のような単純なステートメントにa + bは数マイクロ秒かかる場合があります（変数が文字列の場合）。他の言語は、a + bピンク色の象を出現させるためにオーバーロードされる可能性のあるC ++の極端な例で、これにさらに多くを追加します。Cではそうではありません。関数呼び出しでない場合、数ナノ秒以上かかりません。このパフォーマンスの予測可能性は、Cの重要な機能の1つであり、確かに単純な形式です。

• データ型は、メモリ内に構築する可能性のある興味深いデータ構造をすべて記述しながら、できる限り単純です：CPUが処理できる基本的な型+集約（struct）+繰り返し（配列）+参照（ポインター）のみ）。

  この点で、さまざまなLispベースの言語がCよりもはるかに単純であることは事実です。ただし、Cのようにプログラマがメモリを自由に操作できるようにしようとはしていません。

• 機能の直交性：機能を自由に組み合わせることができ、期待どおりに機能します。多くの言語は、特定の構成要素を定義されたコンテキストでのみ表示できるようにすることで、これに失敗します。

  CおよびC ++の可変長配列を例にとります：Cはどこでも実行時の長さを許可しますが、C ++標準を拡張するための最も自由な要求は、自動配列のような特定のコンテキストでのみ許可し、最初の次元でのみ許可します。これにより、Cは実行時にのみ既知のサイズを持つ真の多次元配列を処理できますが、C ++プログラマはdata[k + (j + i*lineLength)*lineCount]何度も何度も書く必要がありません。

  これのもう1つの例はポインターです。Cのデータポインターは、実際には、他の変数のメモリアドレスを保持する変数にすぎません。ポインター自体が変数であるため、ダブルポインターは明確に定義されています。つまりint、何int*が与えられているのか、それがどうあるべきかは明らかint**です。これをC ++リファレンスと比較してください。C++リファレンスでint&&は、intand の意味が何に与えられているのかまったくわかりませんint&。

Cが非常に嫌悪感を抱いているのはまさにこの単純さであるということは事実です。言語の単純さは、プログラマーに彼らよりも良い自由を与え、未定義の振る舞いや誤ったポインターの問題を引き起こします。特に、プログラマーが変数をいくつかの単純な機能の自由な組み合わせによって非常に簡潔な形式で表現できるため、プログラマーがint (*array[m])(struct foo* (*arg)[n])読者に頭痛を与える傾向があるタイプの変数を定義できる直交性の単純さ。これは、Cが優れている単純なタイプであり、Cを使用するのが難しい言語であるという評判を与えます。

また、この言語の単純さにより、プログラマーは機能豊富な言語よりも多くのコードを書くことを余儀なくされ、バグが繁栄するためのより豊かな基盤が提供されます。それでも、主な目的が仮想マシンではなく実際のコンピューターをプログラムすることである場合は、可能な限り単純な高水準言語のままです。

Java Wikipedia - Wikipediaには明示的に記載されていませんが、簡素化は何度も言及され、当初の設計目標でした。当時唯一の深刻なOO対応（用語は緩やかに使用）言語はC ++でした。しかし、不注意のためにいくつかのトラップがあります。

JVMはクロスプラットフォーム開発を簡素化する方法として意図されており、「Write Once Runどこでも」が数年間Javaのマントラになりました-繰り返しになりますが、その意図はフレームワークの展開が簡単だったことです。

私は、C＃が言語の単純化というカテゴリーに分類されると考えています。

うーん...これは実際に「肯定的に」答えるのは難しい質問です。なぜなら、プログラミング言語の設計の単純さ（および「作業しやすい」こと）を考えると、私はすぐに考えるからです：

1. コードの「可読性」-言語がオブジェクト、メソッドなどをカプセル化する程度。
2. 言語APIとインターフェースの一貫性。

これらのことをうまくやる言語はたくさんありますが、私の頭に浮かぶのは、 「プログラミング言語」として物事をうまくやらない言語です：PHP。

[免責事項-私はPHPを作成しましたが、PHPはまだ単純なWebプロジェクトの「言語への移行」です。これは愛に対する批判です...]

まず、PHPは通常Webサーバーで実行される環境に適しています。設定や保守などが簡単です。

私がPHPで苦労しているところ：「異常な」ことをしたいとき-通常は定期的にやらないこと（私が考えている場合、SOAP Webサービスを消費しているのではなく、 PHPで多くのことを行います）、次の2つのオプションに直面します。

1）PHPのさまざまなオープンソース拡張。PHPオブジェクトモデルは、インターフェイス設計がライブラリ間、開発者間でひどく一貫していない場合、十分に緩いです。誰も聞いたことのないライブラリを使用するコードのセットに直面したとき、この言語は緩やかなAPI /ライブラリの作成を許可するため、「これが一体何をするのか」を理解するのに多くの時間を費やします。

2）「組み込み」機能-の多くがあります。私は別のライブラリを見つけるか、後で何らかの方法でつまずくためにいくつかの機能を実装するかのいくつかのウサギの穴を通過しましたimpossiblyfound_basefunction()

私の意見では、シンプルさは一貫性です。

現在、プログラミング言語に対するKISSのアプローチは、少なくともプログラミング言語をCPUの命令セットなどに対する抽象化層とみなす場合、おもしろい概念です。「KISS」をより厳密に定義しない場合。私はここで、牛車が最大限に車に適用されるKISSであると言っています。

現在、KISSのもう1つの解釈は、「不要な装飾なしでスマートに行われ、過度に複雑ではない」などです。特に、似たようなことに対して特定のケースが多すぎてはいけない、などと主張することができます。通常、数学は本質を煮詰めるのに非常に優れています。 。

プログラミングには、2つの非常に有名な抽象モデルが存在します。

• 1つは、コンピューターとコンピューターが実行できるすべてを計算できる単純な教育モデルを定義するチューリングマシンです。
• もう1つは、Church et。によるLambda-Calculusです。al。それは力において同等です

おもしろいのは、チューリングマシンのレイアウトは非常にシンプルですが、扱いやすいシステムではなく、 "スマートキス"に適しているとは思わないことです。しかし、Lambda Calculusは、私たちが知っているプログラミング言語と関係があります。また、ラムダ計算のLispおよびSchemeの先駆的な機能により、多くの言語に取り入れられました。

LispとSchemeは本当にシンプルで、少なくとも構文上は賢明です。プログラミング言語では構文が大きな問題です（これがおそらく、常に再発明されている理由です）。C ++の場合、一部のソース行がコンパイラによってどのように解釈されるかを人間の脳が予測することはほとんど不可能です。）

Lispは、コマンドに1つの一般的な形式を導入することにより、構文上の複雑さを完全に減らしています。

(command param1 param2 ...)

これは、次のようなメソッド呼び出しです。

(max 1 2 3 4)

ifブランチ、ループなど。

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

（ここのすべてのコードは擬似Lisp / Dialectに依存しません）

フォーム

(command param1 param2 ...)

リストとして解釈することもできます

(item1 item2 item3)

そして、それがLispのシンプルさと美しさの基礎です。（ifステートメントの例のように）ネストされたリストはツリーを構成し、マシンとマシンの前にいる人間の両方が簡単に理解できるためです。

Lispのもう1つの機能はマクロです。ここでは詳細を詳しく説明しませんが、通常の関数呼び出しと「構文（eg forループ、変数宣言など）、パーサーが他で処理するすべてプログラミング言語）独自の構文を作成することができます。マクロは本質的に、プログラムを構成するツリーの操作です。

Lispにはプログラミングに対するKISSがあると思います。マクロを使用して構文を操作できるということは、Lispが非常に動的に進化した現象につながります。次のような新しい言語機能が必要です-オブジェクト指向と言えます-マクロでOOPシステムを書くだけです！

CはOOP機能（C ++、Obj。C）で約2倍拡張されましたが、Lispは複数回拡張されましたが、最終的には勝者がいました。

それはLispについてのもう一つの癖であり、進化しています（lispの興味深い新しい突然変異についてはClojureとClojurescriptを参照してください）。

KISSの特性により、Lispは言語を教える人として好まれています。フォーガスのように、教育言語の青写真で概説しています（http://blog.fogus.me/2013/01/21/enfield-a-programming-language-designed-for-pedagogy/）

始めに、私は新しい、そして時々複雑なトピックを学ぶとき、軽薄な構文規則で学生をオーバーロードすることは全く有害であると強く信じています。したがって、Enfieldは最小限の構文規則と、Lispのような構文よりも最小限のもので設計されています。