17

ご挨拶。私は今、Literate Programming を少し見てきましたが、その背後にあるアイデアが気に入っています。基本的には、コードについて小さな紙を書き、設計上の決定事項、おそらくモジュールを囲むコード、モジュールの内部作業などを書き留めます。モジュール、設計上の決定から生じる仮定と結論、潜在的な拡張、これらすべてを tex を使用して適切な方法で書き留めることができます。確かに、最初のポイント: それはドキュメントです。最新の状態に保つ必要がありますが、変更には正当な理由が必要であり、それを書き留めることができるため、それほど悪いことではありません。

しかし、リテレート プログラミングはどのようにしてより大きな規模に拡張できるのでしょうか? 全体として、Literate Programming はまだ単なるテキストです。もちろん、非常に人間が読めるテキストですが、それでもテキストであるため、大規模なシステムを追跡するのは困難です。たとえば、コンパイラの大部分を作り直して、>> を使用し、いくつかの魔法を使用してコンパイル手順を連鎖させました。 " 非常に扱いにくくなり、これを x >> y >> z >> a に変更すると少し改善されましたが、これも限界点にあります。

では、Literate Programming はどのように大規模システムに拡張されるのでしょうか? 誰かがそれをやろうとしていますか？

私の考えでは、LP を使用して、イベント ストリームを使用して相互に通信するコンポーネントを指定し、graphviz のサブセットを使用してこれらすべてをチェーン化することを考えています。ネットからドキュメント (データフロー図) を抽出し、そこからコードを生成することもできるため、これは LP のかなり自然な拡張です。どう思いますか？

――テタ。

4

9 に答える 9

8

「物理ベースのレンダリング」（pbrt.org）という本は、私が知っている大規模な文芸的プログラミングの最良の例です。本は完全なレンダリングシステムを実装しており、本のテキストとレイトレーサーコードの両方が同じ「ソース」から生成されます。

実際には、Doxygenのようなシステムを使用し、そのすべての機能を実際に掘り下げて利用する方が、教科書や教材などの本格的な「文芸的」プログラミングよりも優れていることがわかりました。

于 2008-11-18T16:14:20.870 に答える
4

「全体として、文芸的プログラミングはまだ単なるテキストです」

誤り。

ダイアグラムは問題ありません。

私の考えは、LPを使用して、イベントストリームを使用して相互に通信するコンポーネントを指定することです。

それはただのアーキテクチャであり、それは問題ありません。

ネットからドキュメント（データフロー図）を抽出し、そこからコードを生成することもできます。どう思いますか？

データフロー図は、詳細なコードを生成するのにそれほど役立ちません。これらは便利な要約であり、正確な情報源ではありません。

優れた筆記具（LaTexなど）は、ドキュメント内の図をエンコードできます。おそらく、ドキュメントの他の部分から図への道を見つけることができます。

結論

長期的には、テキストの要約として図を生成する方がよいでしょう。

なんで？

ダイアグラムは意図的に詳細を省略しています。ダイアグラムは要約または概要です。しかし、コードのソースとして、図はひどいものです。すべての詳細を提供するために、図は非常に雑然としています。

しかし、他のいくつかのLPマークアップの図式的な要約はうまくいくでしょう。

于 2010-03-31T10:38:43.663 に答える
4

私は約 15 年前に WEB を使って文芸的なプログラミングを行いました。最近では、wiki からコードを抽出し、Squeak Smalltalk 環境からドキュメントを生成しようとしました。

ボトムアップの部分は、TDD/BDD フレームワークからドキュメントを生成することで比較的うまく処理できますが、LP はコードを読者に説明することに重点を置いています。

いくつかの問題があります:

  • 伝えるべきストーリーは、利害関係者/読者によって異なります。
  • ほとんどの環境におけるプロジェクト構造は、ストーリーテリングに必要な構造ではありません。
  • 継続的な改良/開示のサポートがありません。
  • テキストに加えて、画像のサポートが必要です。
  • ソース管理システムのコメントから、システムがどのように構築されたかを導き出すことができます。ストーリーは、システムがどのように構築されたかである必要があります（完全な後知恵で）。

大規模なシステムで LP を機能させるには、wiki やオブジェクト ブラウザーよりも優れた IDE サポートが必要です。

于 2008-11-18T16:38:36.780 に答える
4

素晴らしい質問です。読み書きのできるプログラミングへのモチベーションがなくなることはありませんが、それは流動的なものとして扱われるべきだと思います。それは「読者に休憩を与え、あなたがやろうとしていることを彼らに教育する」ことを意味します. 「コードを非常に冗長にする」という意味ではないと思います。

とはいえ、読者は、すでに知っていることに応じて、ある程度の努力をしなければなりません。おそらくコードは理解する価値があり、無料のものは何もありません。

また、読みやすいコードを作ること以上の意味があると思います。ほとんどの場合、誰かがコードを読んでいる理由は、変更を加える必要があるからです。必要になる可能性のある変更を予測し、必要に応じて変更方法を伝える必要があります。

于 2008-11-18T15:52:37.357 に答える
3

pbrtは、コンピュータサイエンスの卒業生（および私）の教育のために読み書きのできるスタイルで記述された物理ベースのレイトレーサーであり、適度に大規模なシステムです。専門家ではないプログラマーとして、このレベルのドキュメントは、プログラムが何をするのか、なぜそれを行うのかを理解するために非常に重要です。

また、Javaのリサーチレンダラーにもアクセスできます。これは、よく書かれていますが、比較的文書化されていませんが、いくつかのSIGGRAPHペーパー用です。これも比較的理解できますが、著者にもアクセスできます。

私もImageJをかなり頻繁に使用しており、基礎となるJavaの内部を調べました。基礎となる哲学を理解せずにフォローするのはかなり困難です。

要するに、私の見解では、誰かがそれをうまくやる時間を見つけることができれば、文芸的プログラミングは素晴らしいです、そしてこれは教育の場である可能性が高いです。それが商用コードの生産で行われているのを見るのは難しいです。私は、コードが完全に自己文書化できるという考えには懐疑的です。

于 2008-11-18T16:18:37.927 に答える
3

リテラル プログラミングの背後にある考え方は、コードに散りばめられたコメントではなく、ドキュメントに散りばめられたコードを使用して、ドキュメントを強調することです。

これは本質的に異なる哲学であり、より長い変数名、名前空間、およびクラスなどの違いは哲学に影響しません。文芸的なプログラミングは、意味のある変数名を提唱します。

ドキュメンテーションとコードの基本的な比率はコードのサイズに比例するため、より大きなシステムにスケールアップできます。

于 2010-01-11T02:48:57.407 に答える
0

NanoLPをお試しください-LP拡張可能ツールで、多くのドキュメント形式（Markdown、OpenOffice、Creole、TeX、Asciidocなど）をサポートし、別のLPプログラムのインポート、テンプレート作成などを行います。ユーザーは独自のコマンド/マクロを（Pythonで）追加して、たとえば、VCSから特別なインポートを行うことができます... http：//code.google.com/p/nano-lp

于 2013-01-24T06:46:01.943 に答える
0

Literate Programming は、長い変数名や関数名が単純に不可能だった時代に開発されました。このため、コードは実際にはそれほど読みやすくありませんでした。

明らかに、それ以来多くのことが起こりました。

今日の世界では、コード自体がドキュメントであるため、「セルフ ドキュメンテーション コード」という用語が使われています。認識されているのは、コメントや外部ドキュメントのセットが基になるコードと同期していることは決してないということです。したがって、今日の多くのプログラマーの目標は、他の人が読めるようにコードを書くことです。

于 2008-11-18T15:41:02.933 に答える