UNIXの哲学でのプログラミングは、関数型プログラミングと同じですか？
UNIXプログラミング環境（古典的なテキスト）は、プログラミングへのUNIXのアプローチは、より複雑な問題を解決するために組み合わせることができる小さくて明確なツールを構築することであると述べています。 CとBashシェルを学ぶ上で、これは強力な概念であり、幅広いプログラミング問題に対処するために使用できることがわかりました。
Linuxプラットフォームを使用するだけで、その概念はかなり明確であり、常に使用されています。 I/Oをリダイレクトするコマンドラインで形成される式、ls、grepなどのリンクシステムツールなどは、この概念がいかに強力であるかを示しています。
私を混乱させるのは、これらのプログラムの多くが命令型/手続き型プログラミングスタイルを使用してCで記述されているにもかかわらず、コマンドラインでそれらを使用して結合する方法は、各プログラムが結合されている他のプログラムの状態に依存しない分離された関数。
これは正確ですか、UNIXプログラミングの哲学を理解することは、基本的に命令型プログラミングスタイルを使用して構築された可能性のあるツールを使用した関数型プログラミングですか？
あなたはそこにポイントを持っていると思いますが、cp、rm、cdおよび他の多くは状態を変更するため、実際には機能しません。 UNIXの哲学は、1つのことだけを行うことですが、それをうまく行うことです。多くの場合、適切に機能することは機能的な使用を許可することを意味しますが、常に許可するわけではありません。
答えはOleg Kiselyovによる "Monadic i/o and UNIX Shell programming" にあります。
これは、フィリップワドラーの論文「命令を宣言する方法」[ Wadler97 ]に触発されたエッセイです。 HaskellのモナディックI/Oと、パイプとリダイレクトに基づくUNIXフィルター構成との不思議な類似点を示します。 UNIXパイプ（意味的には一時ファイルへの書き込みとして扱われる）は、モナドとよく似ています。さらに、UNIXプログラミングのレベルでは、すべてのI/Oをモナディックと見なすことができます...
まあ、副作用の問題全体を無視すれば、そのように見ることができると思います。 Unixコマンドは、常に同じデータセットを同じ入力で返すという点で機能しないことがあります。ただし、先に述べたように、パイピングの側面は関数型プログラミングを実行する方法に似ています。
ある程度言うことができます。しかし、それは必ずしも本当ではありません。単純化した設計アプローチで、より多くを達成する能力としてそれをもっと読むべきだと思います。そして、単純にするためには、タスクを簡単に理解でき、組み立てやすい部品に分割する必要があります。率直に言うと、UNIXの哲学は次の例で説明できます。
すべてのプログラミングはある種のデータ操作です！場合によっては、プログラミングはプログラム操作そのものでもあります（メタプログラミング）。 UNIXの哲学のしくみは、テキストの処理を想像してみてください。テキストとは何ですか？結局のところ、テキストはある種のデータです。組織化された定義にアセンブルすると、テキストもXMLとJSONになります。テキストは数値のリストにすることもできます。テキストはcsv、tsvなどにすることもできます。他のテキストや文字列は、そのコンテキストがねじれて、私たちが望むものに変わっただけで、プログラミングデータの実際の巨大な領域を表すことができます。
すべてのプログラミングには、ある種のデータ編成が必要です。整理するには検索が必要です...
a。 「grep」、「fgrep」、およびそのファミリを使用するだけで、それを実行できます。
検索したら、並べ替えを行う必要があります。
b。これを行うための「sort」コマンドがあります。
2つのファイルをソートしたので、それらを比較したいとします。
c。これで「diff」、「cmp」などができました。
ファイル間に違いがないことがわかりました。整理されたデータがもっと必要です。
d。ファイルに書き込むための「cat」、パイプ、およびリダイレクト演算子があります。
より具体的な解析が必要です。
e。あなたは頭、尾、もっと、もっと少なく、それを行うために他をカットしています...
これらすべては '|'を使用して一緒に縫いますコードをまったく書かずに、いつか本当の強力なものを生成する。あなたが持っているより多くの検索と縫製のために..
f。 awk、Shell、sed。
awk、Shell、sedを使用すると、diffなどが提供するカットよりもテキストをより詳細に制御できます。そのcommand1 |コマンド2 | command3 ...シリーズは、一種のワークフローメカニズムです。 Ifと組み合わせると、これはより強力になります。
もっと楽しくなりました。
'Perl'と呼ばれるユーティリティを聞いたことがありますが、これは非常に強力であり、想像できるほどのわずかな作業でほぼすべてのタスクを実行できます。 DBMのようなユーティリティと一緒に縫い合わせると、アプリケーションの短い時間の永続化の要求も実行できます。テキストの世界から抜け出したことはありませんが、プログラミング環境のほとんどの側面をカバーすることができました。
したがって、UNIXは単なるオペレーティングシステムではないと思います。最も簡単な方法で問題を解決するために設計されたツールと環境のコレクションです。単純な方法は、必ずしもソリューションの実装の単純さを意味するわけではありません。しかし、単純さ自体はそれほど遠くに行きません。
私はこれをredditのどこかで読みました。
「設計の目標がシンプルである場合、Plan9と同じ数のユーザーを獲得できます。」
それらがコマンドラインで結合され、互いに相互作用する方法は非常に機能的です。ただし、これはシェルの設計に大きく関係し、それらの基礎となるプログラムが命令的または機能的に記述されているかどうかには関係ないと思います。ほとんどの優れた関数型言語は、全体的な設計が関数型プログラミングに適している場合でも、命令型/手続き型の概念をサポートしています。はい、多くのUNIXシェル機能は機能的な概念を採用していますが、これも、基礎となるプログラムの特定の実装よりもシェルの設計によるものです。
お役に立てれば、
-tjw