読み書きのプログラミングが主流ではないのはなぜですか？[閉まっている]

Literateプログラミングには理想があります。なぜこれが主流ではないと思いますか？配信に失敗したからですか？

私は最初にクヌースの著作の本でそれを見ました、そしてそれはきちんと見えると思いました。それから、文学のプログラミングディスプレイを使用して、プログラムで何が起こっているのかを理解しようとしましたが、見た目よりも難しいことがわかりました。私はプログラムのリストを見ることにあまりにも慣れていたのかもしれませんが、混乱しているように見えました。

それから私はソースコードを見ました、そしてそれはその時私を消しました。まったく新しい方法でプログラムを書くことを学ばなければなりません。プログラムテキストとコンパイラが見たものとの対応が少なく、対応する利点がありませんでした。

さらに、人々は実際にYを実行しているときにコードがXを実行しているという長く説得力のある議論を書くことができます。私は、コードを読んでコードがかなり早い段階で何をしているのかを見るのが好きになりました。識字プログラミングはその正反対です。

ネットワーク効果を非難します。他の人があなたのコードとドキュメントを編集するには、彼らがそれを理解できなければなりません。

これにより、人々はcweb / nowebのようなものから遠ざかります。それらを使用するには、プロジェクトで使用しているプログラミング言語に加えてTeXとプログラム固有の構文を学ぶ必要があるからです。これは、特にそもそもTeXにとって大きな魅力である数学の組版を必要としない場合、膨大な時間の無駄とみなすことができます。（そして、多くのアプリケーションプログラマにとって、彼らは本当にそれを必要としません。）その代わりに、彼らはVisual StudioのXMLコメントのようなものを好みます。

私がリテラシープログラミングの離陸を見た場所は科学/統計コンピューティングで、ほとんどのプログラマーは数学、CS、または統計の重要なトレーニング（PhD）を持っているため、すでにLaTeXで有名です。彼らが書いたドキュメントには、TeXで最もよく書かれた多くの複雑な式が含まれている可能性が高く、Rでプログラミングされている可能性が高くなっています。SWeaveを知っているRプログラマーの割合は、たとえばcwebを知っているCプログラマの割合。

90年代後半、勉強しながらLiterate Programmingの概念に魅了されましたが、プログラミングと組版に対するKnuthsのアプローチにはまだ興味があります。最高のものしかありません。

Knuthが設計したLiterate Programmingシステムは、すぐに目にするよりもはるかに多くのことを行いました。つまり、コード生成ツールがKnuthsのソースドキュメント、つまり標準Pascalから生成した基礎プログラミング言語の多くの欠点を克服します。

Standard Pascalを試していない幸運な人のために、いくつかのハイライトを紹介します。

• シングルパスコンパイラを使用しやすくするために、言語仕様では、すべての宣言は特定の順序で行わなければならないと述べています。ウィキペディアのページから：「各プロシージャまたは関数は、gotoラベル、定数、型、変数、および他のプロシージャと関数の独自の宣言を持つことができます。これらはすべてこの順序でなければなりません。」つまり、ソースファイルで物事を論理的にグループ化することはできませんでした。
• 文字列の処理は、プレーンなCよりも退屈でした。
• 識別子の長さを任意にすることはできませんでした。
• 私はもう覚えていないことがたくさんあります。

基本的にこれらすべてのことは、Knuthがより優れたプログラミング言語を必要とし（したがって彼が発明した）、アセンブリ言語としてPascalを使用したことを意味しました。

ほとんどの現代言語は、これらのことを多くの労力なしで行うことができるため、Literate Programmingが解決する作業の大部分を削除します。

また、現代の言語は表現力が豊かであり、コード自体により多くの思考を入れることができます。

それで、何が残っていますか？ソースコードからドキュメントのタイプセット形式を生成する機能、および今日存在します。

JavaDoc-JavaランタイムAPIは、おそらく現在利用可能なLiterate Programmingの最大の部分だと考えてください（ただし、コードは実際には表示されませんが、Javaが最初からオープンソースであった場合はそうでした）。たとえば、http：//download.oracle.com/javase/6/docs/api/java/util/Collection.htmlのコレクションフレームワークのプレゼンテーションを参照してください。

.NETやその他の主流のプログラムにも同様のシステムが存在すると思います。

90年代にリテラシープログラミングに夢中になったときに発見したことの1つは、Exactly The Right Thingをやりたいと思っている非常に情熱的な人々を惹きつけたことです。既存のリテラシープログラミングシステムを作成することは、彼らにとって十分ではなかったためです。nowebは、すべての人に十分な最小公分母を提供することで、それを断ち切る良い試みでしたが、それでも、LPのほとんどの時間をきれいなプリンターの開発に費やしました...

別の問題は、それが本当にアジャイルでないということです。いくつかの点で、速度を落とすことは良いことです。なぜなら、それはあなたがより前もって考え、最初に物事を正しくすることを強いるからです。一方、作業中に細心の注意を払って文書化することは、コードのリファクタリングに大きな障壁があることを意味します。そして、LP化する前にコードが強化されるまで待つと、数日間のドキュメント作成タスクになります。

私の謙虚な意見では、多くの企業には、Literate Programmingの目的とは反対の文化があります。私自身の経験では、私の上司は、より速い結果が「私が求めた翌日に実行可能なプログラム」を意味しないことを理解することを拒否していました。彼らにとって、開発者がキーボードでタイピングするのに忙しくなければ、彼は仕事をしておらず、「デザインに意味のない時間を無駄にしています」。はい、私は知っています、私のボスは恐ろしいです。

コーダーは英語ではないコードを書きます。

コーダーは、コードの実行に役立たないため、ドキュメントを書くことを好みません。

コーダーは、ドキュメントを書くのが苦手です。なぜなら、それは彼らのアイデアを表現するための貧弱な媒体だからです。

リテラルプログラミングは、ドキュメントを次のレベルに進めて、コードを後から考えるという考え方のようです。多分それは動作するでしょうが、ほとんどのコーダーにとっては不快なドキュメントのように見えます。

主に人々は非常に愚かだからです。この単純な手法の性質について若者が表現した推測と誤解の無限の流れである明らかな証言。

（a）ドキュメンテーションの方法（b）いくつかの特別なスキルや才能を必要とする洗練されたエッセイを書く方法（c）単に手がかりがない-レオプログラミングエディターの作成者として、彼自身の承認によってなどなど

ただし、LPは単純です。（1）（=）任意の人間の言語でコードとフレーズを組み合わせてプログラムを作成します。後者は他のコードのチャンクやフレーズを含みます。これはまさに、無数のプログラミング教科書の著者が行うことです..（2）それは人間のそれらのフレーズを展開する単純なプリプロセッサです（含まれるサブルーチンの名前のようになりました）。通訳）。それ以外の場合は、別の小さなユーティリティを使用して、書かれたテキストを展開し、「識字ソース」を適切にフォーマットされた読みやすいテキストに変換するフォーマット記号を含めることができます。

若い人たちは、この非常に単純なアイデアを決して試しません。そして、彼らが決してそれをやろうとしない偽の理由を想像したり想像したりします。

基本的には、人間の言語で書かれた「擬似コード」でプログラミングし、単純なプリプロセッサユーティリティで拡張するという主なアイデアです。詳細に没頭することはないが、マシンの実行には完全に不要であるために必要な関数/サブルーチンへ。

リテラシープログラミングには、メインストリームプログラミングに組み込まれることを望んでいる2つの側面があります。埋め込み画像（たとえば、設計図）と、以前および代替の試みへのポインター（たとえば、「このような理由は、他の方法で... "）が原因で機能しませんでした。これらの両方の側面は、doc-commentsとURIで処理できます。

プログラムのロジックは、私たちが話すのと同じように機能しないためです。プログラムには、明確に指定されたフロー、条件、およびループがあります。

たくさんのコーディングをした後、これらの用語で考えます。私の脳は、問題を実行可能コードのターゲットドメインに変換します。また、プログラムを読み書き可能にするために追加の変換ステップを実行するよりも、通常はプログラミング言語でこれを書き留める方がはるかに効率的です。

実際、私のプログラムはすでに読み書きができると思います...識別子を話す、良い関数名、数か月後にすぐには理解できないハッカーをしたコメント。

結論として：私のJavaコードは、すべての「リテラシー」プログラミングが望んでいるように、それ自体でリテラシーがあります。

私は逆の方法で文芸的プログラミングに行きました。コンパイラが必要とするのではなく、自分の心に合ったコードを編成することを夢見ていました。レオはこの目的にほぼ理想的だと思いました。また、外部で変更されたファイルの追跡をサポートします。これらのファイルには特別なマークアップを含める必要はないので、チームの他のメンバーが知る必要なしに自分でLeoを使用できます。この機能（「@シャドウツリー」）は非常に有望ですが、まだ少しバグがありますが、より多くの目玉が必要です。また、すべてをツリーアウトラインに整理することと、外部ファイルをサポートすることにより、「1つの大きなファイルにすべてを入れる」という問題も解決します。

私にとって、その名前とは反対に、「リテラシープログラミング」とはドキュメントに関するものではありません。以前よりも多くのドキュメントはありません。迷子にならないようにする構造を持つことです。特に、巨大なJSPファイルを管理するとき、私はそれを誓います（そして、LeoはもともとPythonを主に対象としていましたが、JSP言語をサポートしていません-ファイルをLeoツリーに手動で分割する必要があります！）

私は、コードに関する論文を書くことができる貴重な教育ツールであると考えています。次に、作業コードのスニペットを挿入して、コードのハウ、内容、理由を読者に指示します。

純粋に教育的な環境以外では、Knuthだけが実際にそれを使用する最善の方法を理解していると思います。

それはすべての世界の最悪です-非常に非特定の言語=英語で非常に正確で、非常に特定のコンピュータープログラムを作成する必要があります。したがって、正確なフレーズを正確に使用して慎重に記述する必要があります。したがって、コードを記述することもできます。