タグ付けされた質問 「literate-programming」

最近、Literate Programmingについて少し読んで、考えさせられました...よく書かれたテスト、特にBDDスタイルの仕様は、散文よりもコードが何をするかを説明するのにより良い仕事をすることができ、大きな利点があります自身の精度を検証します。 テストするコードとインラインで記述されたテストを見たことはありません。これは、言語が同じソースファイルに記述されたときにアプリケーションとテストコードを簡単に分離する傾向がないため（そして誰も簡単にしなかったため）、または人々がテストコードをアプリケーションコードから分離するより原則的な理由があるからですか？

91 testing  unit-testing  bdd  literate-programming 

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

32 programming-practices  literate-programming 

私は最近、文芸的プログラミングの概念を見つけました。そして、私はそれがかなり興味深いと感じました。それでも、プログラムを構成するのは悪い方法であるという主張には遭遇していません。多くの場所をカバーしていないようです。ここでさえこれに関する質問を見つけることができませんでした。 私の質問は、その欠陥やドキュメントの処理方法についてではありません。ドキュメンテーションは、文芸的プログラミングの流れにとってそれが何を意味するのかという副作用だと考えています。この設計はもともと、簡単な文書化とフォワードプログラミングフローの概念を目的としたものでした。 問題を小さな文ベースの問題に分割するという概念は、本当に素晴らしいアイデアのようです。これにより、プログラムの流れの理解が容易になります。 文芸的設計法の結果として、必要な機能の数はプログラマーの想像力に制限されます。特定のタスクの関数を定義する代わりに、それをscrap文芸的メソッドとして作成することができます。これにより、個別の関数コンパイルの代わりにコードが自動的に挿入され、同等の速度を得るために手続き間コンパイルの最適化ステップが必要になります。実際、ドナルドE.クヌースの最初の試みは、この事実のために実行時間が劣っていました。私はコンパイラがこれの多くに作られることができることを知っています、しかしこれは私の心配ではありません。 それで、なぜこれが悪い/良い設計方法論であると考える必要があるのか​​についてフィードバックを得たいですか？

10 design-patterns  language-design  literate-programming 

この宝石に偶然出会ったとき、私は（通常）技術文書へのセマンティック/オントロジーベースのアプローチを研究していました。 識字プログラミングとセマンティックWebは異なる時代のアイデアであり、関連性があります。 リンクされた論文、Norman WalshによるLiterate Programming in XMLは、セマンティックWebの中心であるXMLテクノロジーについて説明していますが、文芸的プログラミングとセマンティックWeb またはオントロジーベースのドキュメントとの間の概念的なつながりを見ることはできません。助けて？

9 documentation  semantic-web  literate-programming