プログラマーに制限が必要な理由

私たちは「境界線なし」または「境界線を押してください 」というモットーを持つ文化に生まれましたが、実際には境界線が必要です。 私たちはそれらで良くなっていますが、これらは正しい境界でなければなりません。

高品質の音楽の検閲

歌、本、映画で語ることのできる外部の限界に直面するとき、著者は希望する意味を伝えるために比phorを使わなければなりません。



例として、1928年の古典的なコールポーターの曲、 Let's Do It（Let's Fall in Love）を取り上げます。 私たちは皆、「それ」の意味を理解していますが、「恋に落ちよう」ではありません 。 著者は検閲を避けるために括弧内に一部を追加しなければならなかったと思われます。



2011年に早送りして、私のノブにある スリー6マフィアのスロブを見てください。 最初の比phor的な詩を除いて、他のすべてはうんざりするほど明白です。



パフォーマンスの芸術性（またはその不在）からしばらく気を散らすと、Cole Porterの歌は、Three 6 Mafiaが想像力を働かせるような耐え難い詳細を私たちに投げかけていることを示唆していると言えます。



問題は、Three 6 Mafiaのテキストで説明されている性に関する見解を共有しない場合、せいぜい下品で、完全にトピックを明かさない歌を見つけることです。 そして、コールポーターの歌を含めることで、リスナーは自分の想像力を思い起こさせることができます。



つまり、制限はアイテムをより魅力的にすることができます。

サメが壊れた

当初、スティーブン・スピルバーグは、サメのいるシーンを通して「ジョー」のプロットを伝えることを計画していました。 しかし、彼女は常に壊れていました。 ほとんどの場合、映画のクルーはこの映画のスターであるサメを見ることができませんでした。



メカニックの難しさがスピルバーグの能力に制限を課さなかったなら、大ヒットになったテープは現在の形では存在しなかったでしょう。



この映画がサメを映す映画よりもはるかに優れているのはなぜですか？ 各視聴者は、彼の想像力の助けを借りてギャップを独立して埋めるためです。 彼は自分の恐怖症を思い出し、それをスクリーンに投影します。 したがって、恐怖は視聴者ごとに個人的なものです。



アニメーターはこの原理を長い間知っています。 画面の後ろに落ちる音をオンにして、その効果を示します。 これには2つの利点があります。 第一に、落下をアニメートする必要はありません。第二に、落下は視聴者の心の中で起こります。



ほとんどすべての人々は、バンビの母親を撃った方法を見たと信じています。 しかし、私たちは彼らが彼女をどのように撃ったかを見ていないだけではありません-撃った後も彼女を見たことがありません。 しかし、人々は両方のシーンを見たことを誓うことができます。 しかし、これは決して示されませんでした。



そのため、制限により状況は改善されます。 はるかに良い。

選択肢はどこにでもあります

あなたが芸術家だと想像してください。絵を描くようにお願いします。 私が尋ねる唯一のこと：「私に何か美しいものを描いてください。 私が好きになること。」



スタジオに来て、そこに座って、空白のキャンバスを見ます。 あなたは彼を際限なく見ます、そして、あなたはいかなる方法でも書き始めることができません。 なんで？



オプションが多すぎるため。 文字通り何でも描くことができます。 制限を設定していません。 この現象は選択のパラドックスと呼ばれています。



ただし、自分の好きな風景を描くように依頼した場合、少なくとも無限の選択肢の半分を排除します。 選択肢は無限にありますが、 ポートレートに関する考えはすぐに消えていきます。



さらに進んで、黄金の夕日の間に海岸に打ち寄せる海の風景と波が好きだと言ったら、まだ無限の数の絵画がありますが、これらの制限は実際に何を描くかを考えるのに役立ちます。



そして無意識のうちに、海の絵を描き始めることができます。



したがって、制限により創造性が容易になります。

ハードウェアはソフトウェアよりも簡単です

ハードウェアでは、コンピューターの複数のコンポーネントでトランジスターまたはコンデンサーが使用されることはありません。 キーボード回路の抵抗は、グラフィックカードでは使用できません。



グラフィックカードには独自の抵抗があり、それだけが制御します。 ハードウェアエンジニアは、より多くの抵抗器を販売するため、これを行いません。 彼らは選択肢がないのでそれをします。



宇宙の法則によれば、そのようなシステムはカオスを引き起こさずに作成することはできません。 ユニバースは、ハードウェアの開発者向けのルールを設定します。つまり、可能な範囲を制限します。



このような制限により、ハードウェアでの作業がソフトウェアでの作業よりも簡単になります。

プログラムでは不可能なことは何もありません

それでは、ほとんどすべてが可能なソフトウェアに移りましょう。 ソフトウェア開発者がプロ​​グラムのどの部分でも変数を使用することを妨げるものは何もありません。 このような変数はグローバルと呼ばれます。



アセンブリ言語では、コードの任意のポイントに移動して実行を開始できます。 そして、いつでも実行できます。 データに書き込むことさえでき、プログラムに予期しないコードを実行させます。 この方法は、 「バッファオーバーフロー」などの脆弱性を悪用するハッカーによって使用されます。



通常、オペレーティングシステムは、プログラムが外部で実行できるアクションを制限します。 しかし、彼女が彼女のコードとデータでできることには制限はありません。



ソフトウェアの作成と保守を非常に難しいものにしているのは、制限の欠如です。

ソフトウェア開発に制限を加える方法

ソフトウェア開発には制限が必要であることを知っており、経験から、他のクリエイティブな職業の制限が私たちに良いことをもたらすことがわかっています。



また、社会がコードをランダムに検閲したり、パラダイムを制限する機械的な障壁を設定したりすることはできません。 また、ユーザーがソフトウェア設計に適切な制限を課すほどの資格を期待することはできません。



私たちは自分自身を制限しなければなりません。 ただし、これらの制限がすべての人に利益をもたらすようにする必要があります。 それでは、どのような境界を選択する必要があり、どのようにそのような決定を下すのでしょうか？



この質問に答えるために、私たちの経験と長年の実践に頼ることができます。 しかし、最も便利なツールは過去の間違いです。



たとえば、ストーブに触れたときの以前の行動の苦痛は、将来そのような苦しみを取り除くために自分に課すべき制限を教えてくれます。

私の人々を行かせて

むかしむかし、人々はある場所から別の場所にコードが飛び移るプログラムを書きました。 これはスパゲッティコードと呼ばれていました。そのようなコードを追跡することは、パンの中の1つのパスタを観察するようなものだったからです。



業界は、この手法が非生産的であることに気付き、最初にGOTO構文コードで許可されている言語の使用を禁止しました。



時間が経つにつれて、新しいプログラミング言語はGOTOサポートを完全に放棄しました。 それらは構造プログラミング言語と呼ばれ始めました。 そして今日、人気のあるすべての高レベル言語にはGOTOが含まれていません。



これが起こると、一部の人は、新しい言語が厳しすぎ、GOTOを使用するとコードを書く方が簡単だと不平を言うようになりました。



しかし、より進歩的な心が勝ちました、そして、我々は彼らにそのような破壊的なツールを捨てたことに感謝しなければなりません。



進歩的志向の人々は、コードが記述または修正されるよりもはるかに読みやすいことを認識しました。 つまり、保守派にとっては不便かもしれませんが、長期的には、この制限のある生活はずっと良くなるでしょう。



コンピューターは引き続きGOTOを実行できます。 実際、彼らもそれを必要としています。 私たちは、業界全体として、プログラマーへの直接使用を制限することを決定しただけです。 すべてのコンピューター言語は、GOTOを使用してコードにコンパイルされます。 しかし、言語設計者は、たとえばforループを終了するbreakコンストラクトを使用するなど、より順序付けられた分岐を使用するコンストラクトを作成しました。



ソフトウェア業界は、言語開発者によって課された制限から大きな恩恵を受けています。

束縛する

では、今日のGOTOとは何ですか？また、言語開発者は私たちに無警戒なプログラマーのために何を準備しますか？



この質問に答えるには、私たちが毎日直面している問題を考慮する必要があります。

1. 難易度
2. 再利用可能
3. グローバルな可変状態
4. 動的型付け
5. テスト中
6. ムーアの法則クラッシュ

これらの問題を解決するプログラマーの能力をどのように制限できますか？

難易度

時間とともに複雑さが増します。 もともと単純なシステムであったものが、時間の経過とともに複雑なシステムに進化します。 複雑なシステムとしての始まりは、時間とともにカオスに進化します。



では、プログラマーを制限して複雑さを軽減する方法を教えてください。



まず、プログラマーに完全に小さな部分に分割されたコードを書かせることができます。 これは困難であり、完全ではないかもしれませんが、そのような行動を奨励し、それに報いる言語を作成できます。



多くの関数型プログラミング言語、特に最もクリーンな言語は、これらの両方の効果を実装しています。



計算である関数を書くと、非常にひどく壊れたコードを書くことを余儀なくされます。 また、タスクのメンタルモデルを通して考えることもできます。



また、すべての関数をクリーンにするなど、プログラマーが関数で実行できることに制限を課すこともできます。 純粋な関数とは、副作用のない関数です。たとえば、関数はその外部のデータにアクセスできません。



純粋な関数は、転送されたデータでのみ機能し、結果を計算して渡します。 同じ入力で純粋な関数を呼び出すたびに、常に同じ出力が生成されます。



これにより、実行されるすべてのタスクが完全に関数自体の内部にあるため、純粋な関数の操作がより論理的になります。 また、自給自足型のユニットであるため、ユニットテストの実施も容易です。 そのような関数の計算が高価な場合、その結果をキャッシュできます。 同じ入力がある場合、出力が常に同じであることを確認できます-キャッシュを使用するための理想的なシナリオ。



プログラマーを非常に純粋な関数に制限することにより、関数は局所的な影響しか持たないため、複雑さが大幅に制限されます。 さらに、開発者がプロ​​グラムの一部に自然に分解するのに役立ちます。

再利用可能

プログラミングの出現以来、ソフトウェア業界はこの問題に苦労しています。 まず、ライブラリ、構造プログラミング、オブジェクト指向の継承がありました。



これらのアプローチはすべて、限られた魅力と成功しかありません。 しかし、常に機能し、ほぼすべてのプログラマーによって使用されている1つの方法があります-コピー/貼り付け、またはコピーと貼り付け。

コードをコピーして貼り付けると、何か間違ったことをしていることになります。

プログラマーがテキスト形式でプログラムを作成するため、コピーペーストを禁止することはできませんが、より良いものを提供することはできます。



関数型プログラミングでは、コピーアンドペーストよりもはるかに優れた標準的な手法、つまり高階関数 、 カリー化 、 合成があります。



高階関数を使用すると、プログラマーはデータおよび関数であるパラメーターを渡すことができます。 この機能をサポートしない言語での唯一の解決策は、関数をコピーして貼り付けてから、 ロジックを編集することです。 高階関数のおかげで、ロジックをパラメーターとして関数として渡すことができます。



カリー化により、一度に1つのパラメーターを関数に適用できます。 これにより、プログラマは汎用バージョンの関数を記述し、 一部のパラメーターを「ベイク処理」して 、より特化したバージョンを作成できます。



コンポジションを使用すると、プログラマーはLegoキューブなどの関数を組み立てて、パイプラインに組み込まれた機能を再利用できます。この機能では、ある関数から別の関数にデータが渡されます。 これを簡略化したものがUnixパイプラインです。



そのため、コピーと貼り付けをなくすことはできませんが、言語のサポートと、コードベースでの存在を禁止するコードの分析により、コピーと貼り付けをオプションにすることができます。

グローバルな可変状態

これはおそらく最大のプログラミング問題ですが、多くの人はそれを問題として認識していません。



コンピューターの再起動や問題のあるアプリケーションの再起動によってソフトウェアのバグが最も頻繁に修正される理由を疑問に思ったことはありませんか？ これは条件によるものです。 プログラムはその状態を損傷します。



プログラムのどこかで、状態は容認できないほど変化しています。 このような「バグ」は通常、修正が最も難しいものの1つです。 なんで？ 再現が非常に難しいためです。



そのような「バグ」を一貫して再現できない場合、それを解消する方法を見つけることができません。 修正を確認しても何も起こりません。 しかし、それは問題が修正されたために起こったのですか、それともまだ発生していないためですか？



適切な状態管理は、プログラムの信頼性を確保するために実装する必要がある最も重要な原則です。



関数型プログラミングは、言語レベルでプログラマーに制限を設定することにより、この問題を解決します。 プログラマは可変変数を作成できません。



最初は、開発者が行き過ぎているように思えるので、今度は開発者を分岐点に上げます。 しかし、このようなシステムを実際に使用すると、状態を管理できると同時に、すべてのデータ構造を不変にすることができます。つまり、変数が値を受け取った後、値を変更することはできません 。



これは、状態を変更できないという意味ではありません。 そのためには、新しい状態を作成する関数に現在の状態を渡す必要があることを意味します。 あなたがハッキング愛好家があなたの熊手を再び研ぎ始めるまで、 Structure Sharingを使用して、舞台裏でそのような操作を最適化するメカニズムがあることを保証できます。



このような変更は「内部で」発生することに注意してください。 GOTOの破壊の昔のように、コンパイラと実行可能プログラムは引き続きGOTOを使用します。 プログラマーには簡単にアクセスできません。



副作用が発生する場合、関数型プログラミングには、プログラムの潜在的に危険な部分を制限する方法があります。 適切な実装では、コードのこれらの部分は危険であると明示的にマークされ、クリーンなコードから分離されています。



また、コードの98％に副作用がない場合、状態を損なうバグは残りの2％にしか残ることができません。 これにより、危険な部分が囲いの中に追い込まれるため、プログラマーはこのタイプのエラーを見つける良い機会を与えます。



つまり、プログラマーを純粋に（または少なくとも）純粋な機能に制限し、より安全で信頼性の高いプログラムを作成します。

動的型付け

静的型付けと動的型付けについてはもう1つの長くて古い議論があります 。 静的型付けは、コンパイル時に変数の型がチェックされる場合です。 タイプを設定すると、コンパイラはそれを正しく使用しているかどうかを判断するのに役立ちます。



静的型付けに対する反対は、プログラマーに不必要な負担をかけ、詳細な型付け情報でコードを汚染することです。 そして、この型付け情報は、関数の定義の隣にあるため、構文的に「うるさい」です。



動的型付けでは、変数の型がコンパイル段階で設定またはチェックされることはありません。 実際、動的型付けを行うほとんどの言語はコンパイルされていません。



動的型付けに対する異議は、コードの大幅なクリーンアップにもかかわらず、プログラマーが変数の誤用のすべてのケースを追跡できないことです。 これらは、プログラムが起動されるまで検出できません。 これは、すべての努力にもかかわらず、タイプエラーが生産段階に到達することを意味します。



それでは、何が良いですか？ ここでプログラマの制限を検討しているので、あなたはおそらくその欠点にもかかわらず静的型付けを支持することを期待しています。 一般的にはそうですが、なぜ両方の長所を利用しないのですか？



静的型付けを使用するすべてのシステムが同じように作成されるわけではありません。 多くの関数型プログラミング言語は型推論をサポートしており、コンパイラは使用方法に基づいて作成する関数の型を決定できます。



これは、不必要に型を指定せずに静的型付けを使用できることを意味します。 推奨事項は、コンパイラによって定義されるのではなく、タイピングを指定する必要があることを示していますが、HaskellやElmなどの言語では、タイピング構文は実際に構造を破壊せず、非常に便利です。



機能しない、つまり 静的型付けを伴う命令型言語は、型を指定することでプログラマに負担をかけ、ほとんど見返りを与えません。



それらと比較して、HaskellおよびElm型システムは、実際にはプログラマーがコードを改善し、プログラムが正しく動作しない場合にコンパイル時に通知するのに役立ちます。



したがって、プログラマーを適切な静的型付けに制限することにより、コンパイラーはエラーの認識、型の検出、コーディングを支援し、開発者に冗長で侵入的な型情報を負担させません。

テスト中

テストコードの記述は、現代のプログラマの生活を害します。 多くの場合、開発者はテストコード自体よりもテストコードの作成に多くの時間を費やします。



データベースまたはWebサーバーと対話する関数のテストコードを記述することは、不可能ではないにしても自動化するのが困難です。 通常、2つのオプションがあります。

1. テストを書かない
2. データベースまたはサーバーをシミュレートする

オプション1は間違いなく最適ではありませんが、複雑なシステムのシミュレーションはテストが必要なモジュールを書くよりも時間がかかるため、多くの人が選択します。



しかし、コードを純粋に純粋な関数に制限すると、副作用や突然変異を引き起こす可能性があるため、データベースと直接やり取りすることはできません。 データベースにアクセスする必要がありますが、今では危険なコードのレイヤーは非常に薄いインターフェイスレイヤーになりますが、モジュールのほとんどはクリーンなままです。



純粋な関数のテストははるかに簡単です。 しかし、私たちはまだ私たちの生活を害するテストコードを書く必要があります。 それともまだないのですか？



機能プログラムを自動的にテストするためのプログラムがあることがわかりました。 プログラマが提供する必要があるのは、逆関数など、関数が従うべきプロパティのみです。 Haskellの自動テスターはQuickCheckと呼ばれます 。



そのため、ほとんどの機能をクリーンに制限することで、テストをはるかに簡単にし、場合によっては些細なこともできます。

ムーアの法則クラッシュ

ムーアの法則 -これは実際には法則ではありませんが、実際の観察では、コンピューターの計算能力は2年ごとに倍になります。



この法律は50年以上有効です。 しかし、残念ながら、私たちは現代の技術の限界に達しました。 また、非シリコンコンピューターを作成するための技術を開発するには数十年かかる場合があります。



これまで、コンピューターの速度を2倍にする最善の方法は、コアの数を2倍にすることです。 中央処理装置の計算「エンジン」の数。 しかし、問題は「鉄」の製造業者が私たちにもっとコアを与えることができないということではありません。 問題はバッテリーとソフトウェアです。



計算能力を2倍にするということは、プロセッサーが消費する電力を2倍にすることを意味します。 これにより、今日よりもさらにバッテリーが消費されます。 バッテリー技術は、ユーザーの飽くなき欲求に大きく遅れをとっています。



したがって、バッテリーを放電する新しいカーネルを追加する代わりに、既存のカーネルの使用を最適化する必要があります。 これがソフトウェアの出番です。 現代の命令型プログラミング言語では、プログラムを並行して実行することは非常に困難です。



今日、並行性はプログラマーの負担です。 プログラムは、縦方向に平行な部品を横断して切断する必要があります。 これは簡単な作業ではありません。 そして実際には、JavaScriptのような言語では、コードを並列に実行できないため、プログラマはこれを制御できません;シングルスレッドです。



ただし、純粋な関数を使用する場合、それらが実行される順序は関係ありません。 それらについて最も重要なことは、入力データの可用性です。 つまり、コンパイラまたはランタイムシステムは、いつどのような機能を実行するかを決定できます。



純粋な関数に限定することにより、プログラマーは並行性への懸念を取り除きます。



機能的プログラムは、開発者の複雑さを増すことなく、 マルチコアマシンを活用できます。

少ない労力でより多くのことを。

ご覧のとおり、適切な制限を設定することで、アートワーク、デザイン、生活そのものを大幅に改善できます。



ハードウェア開発者は、ツールの自然な制限から大きな恩恵を受けており、これにより作業が簡素化され、過去数十年にわたって飛躍的な進歩を遂げました。



ソフトウェア開発者である私たちにとって、より多くを達成するために自分自身を制限する時が来たように思えます。