文芸的プログラミング、良い/悪い設計方法論

私は最近、文芸的プログラミングの概念を見つけました。そして、私はそれがかなり興味深いと感じました。それでも、プログラムを構成するのは悪い方法であるという主張には遭遇していません。多くの場所をカバーしていないようです。ここでさえこれに関する質問を見つけることができませんでした。

私の質問は、その欠陥やドキュメントの処理方法についてではありません。ドキュメンテーションは、文芸的プログラミングの流れにとってそれが何を意味するのかという副作用だと考えています。この設計はもともと、簡単な文書化とフォワードプログラミングフローの概念を目的としたものでした。

問題を小さな文ベースの問題に分割するという概念は、本当に素晴らしいアイデアのようです。これにより、プログラムの流れの理解が容易になります。

文芸的設計法の結果として、必要な機能の数はプログラマーの想像力に制限されます。特定のタスクの関数を定義する代わりに、それをscrap文芸的メソッドとして作成することができます。これにより、個別の関数コンパイルの代わりにコードが自動的に挿入され、同等の速度を得るために手続き間コンパイルの最適化ステップが必要になります。実際、ドナルドE.クヌースの最初の試みは、この事実のために実行時間が劣っていました。私はコンパイラがこれの多くに作られることができることを知っています、しかしこれは私の心配ではありません。

それで、なぜこれが悪い/良い設計方法論であると考える必要があるのか​​についてフィードバックを得たいですか？

これにより、個別の関数コンパイルの代わりにコードが自動的に挿入され、その後、同等の速度を得るための手続き間コンパイルの最適化ステップが必要になります。

これは無関係です。何十年もされています。最近のコンパイラではオプティマイザを破壊するのは意味がないので、質問から削除できます。

それで、なぜこれが悪い/良い設計方法論であると考える必要があるのか​​についてフィードバックを得たいですか？

文芸的プログラミングにマイナス面はありません。（私はその感情に対して数十の-1票を期待しています。）開業医として、私は問題を見たことがありません。

「高水準言語でのプログラミングは、結果のコードを微調整することによって覆されてしまう」ことに反対するいくつかの議論があります。正しい。C ++でのプログラミング.oが生成されるファイルを微調整することによって破壊されるのと同じ方法で。それは本当ですが、無関係です。

文芸的プログラムを書くということは、高レベルで詳細な（コードレベルの）設計を1つのドキュメントに組み合わせ、コンパイラーフレンドリーなファイルと人に優しいファイルを生成する適切なツールセットで書くことを単に意味します。

クヌースが文芸的プログラミングを発明したとき、主流のオブジェクト指向言語は存在しませんでした。したがって、元の多くのWebツールとウィーブツールを使用して、抽象データ型のクラスのような定義を作成できました。

その多くは今日では無関係です。識字率の高いプログラミングツールは、最新の高レベルのオブジェクト指向（または関数型）プログラミング言語に焦点を当てている場合、非常にシンプルです。C（またはPascalまたはアセンブラー）の制限により、複雑な回避策の必要性が少なくなります。

文盲のプログラムを書くアプローチは、文盲のプログラムを書くアプローチと同じです。それでも、慎重な設計、単体テスト、およびきちんとしたコーディングが必要です。唯一の追加作業は、コードの記述に加えて説明の記述です。

この理由だけ-首尾一貫した説明を書く必要-は、一部のプログラマーにとって文芸的プログラミングが困難です。かなりの数のプログラマがいますが（彼らのコードはすべての単体テストに合格し、きちんとしていて理解しやすい）、母国語で首尾一貫した文章を書くことができないようです。これが真実である理由がわかりません。

ほんのわずかしか成功せず、偶然だけで成功しているように見える非常に多くのプログラマーがいます。（スタックオーバーフローには、多くのプログラマーが基本を理解するのに苦労していることを示す十分な悪い質問があります。）一貫性のないスタックオーバーフローの質問をするプログラマーの場合、知識のあるプログラミングをうまくやることができません。プログラミングはうまくいきません。

私にとって文芸的プログラミングの最も重要な側面（または単に優れたコメント）は、ドキュメントを提供するほど多くはなく、むしろプログラマーの意図を述べています。述べられた意図を知ることで、それに続くコードが本当にそれがすべきことを実際に行うかどうかをすぐに判断することができます。意図がなければ、コードが正しいという仮定から始めて、それが帰納法によって正しいか間違っているかを証明する必要があります。これは、周囲のすべてのコードにも精通する必要があるため、より多くの時間と時間がかかります。

そのため、意図が明記されていると、コードに不慣れな他のユーザーが、コードを取り巻く大きなコンテキストを知らなくても、すぐにジャンプしてエラーを見つけることができます。

そしてもちろん、それはあなたがコードの基本的な流れとデザインをより速く学ぶのにも役立ちます。普通の英語はほとんどの人にとってポインタ計算よりも直感的であることが多いからです。

自分自身でプログラミングを散らかすという概念は比較的新しいものです（そのため、ボートを完全に見逃している可能性があります）が、DSLの概念と一致しているようです。

DSLの背後にある考え方は、問題のドメインを単純な自然言語指向の文法に蒸留して、それらの問題を解決するためのアルゴリズムを構築するために使用できるようにすることです。

私にとって、その同じアイデア、または少なくともそのコアとなる基礎は、文芸的プログラミングと同じか、少なくとも密接に関連しています。

たとえば、グルーヴィーな世界では、DSLをより定期的に使用し、新しいDSLを作成して一般的な問題を解決することが強く求められています。このプッシュは、言語内の両方のツール（簡単なビルダー）と、DSLベースのAPIをサポートするコアライブラリから行われます。

トレンドは、少なくとも世界のあちこちで、文芸的なプログラミングに向かっているので、私はそれが努力するのに良い方法論だと思います。

残念ながら、優れた dsl を作成するために必要な考え方のレベルは、多くのプログラマーを超えていることがよくあります。私は時々必要とされるいくつかの概念に個人的に苦しんでいることを知っています。このような技術がこのような技術の普及を妨げてきたのは、この問題が原因かもしれません。

これは、ツールを使用することが典型的なケースですが、作成はまったく異なるレベルで行われます。

私の見解を少し広げると、DSLが文芸的プログラミングと同じであるということではなく、文芸的プログラミングをはるかに可能にするということです。特に、それらが自然言語DSLである場合。

Groovyのバージョン1.8では、より強力なコマンドチェーンが追加され、自然言語DSL機能が大幅に改善されました。

たとえば、次のコード行は、単なる擬似文ではなくプログラミングです。

drink tea with sugar and milk
move left by 30.centimeters
sendFrom "Guillaume" to "Jochen"
send from: "Jochen" to "Lidia"
Email.from "Lidia" to "Guillaume" withBody "how are you?"
contact.name "Guillaume" age 33
move left by 30.centimeters
sell 100.shares of MSFT
take 2.pills of chloroquinine in 6.hours
blend red, green of acrylic
artist.paint "wall" with "Red", "Green", and: "Blue" at 3.pm
wait 2.seconds and execute { assert true }
concat arr[0] with arr[1] and arr[2]
developped with: "Groovy" version "1.8-beta-2"

注：コードサンプルは、Guillaume Laforgeのブログから引用しています

文芸的プログラミングの背後にある核となる考えは、自然言語は人間にとってより理解しやすいということであり、それが重要なことです。私の意見では、Groovyの自然言語DSL機能は、これをはるかに近い現実にします。特に、これらのDSLがアプリケーションのビジネスルールの作成に使用される場合。

自然言語を使用してシステムの重要なコンポーネントを「エンコード」できることは、文芸的プログラミングの本質です。コードのチャンクで自然言語を散在させることは、文芸的プログラミングの粗末な形です。有用ではありますが、コード自体として自然言語を使用できる自然言語DSL は、飛躍的な進歩であると思います。

機能をプログラミングに拡張することは一般にプロセスの次のステップですが、大部分はそうするためのツールがすでに用意されています。はい、「一般的な」DSLはまだありませんが、小さいドメインの場合は機能はあります。

実際のこの他の例について（順不同）：

• http://www.slideshare.net/glaforge/groovy-dsls-s2gforum-london-2011-guillaume-laforge
• http://docs.codehaus.org/display/GroovyJSR/GEP+3+-+Command+Expression+based+DSL
• /programming/6646811/groovy-1-8-abc-style
• http://svn.codehaus.org/groovy/trunk/groovy/groovy-core/src/test/gls/syntax/Gep3Test.groovy
• http://groovyconsole.appspot.com/script/355001
• http://docs.codehaus.org/display/GROOVY/Groovy+1.8+release+notes#Groovy18releasenotes-CommandchainsfornicerDomain-SpecificLanguages
• http://mrhaki.blogspot.com/2011/05/groovy-goodness-command-chain.html
• http://ice09.wordpress.com/2011/10/07/dsls-made-easy-with-groovys-chain-method-calls-gep-3/
• http://eric-berry.blogspot.com/2011/05/some-dsl-fun-with-groovy-18.html

LPはある種のDSLだと考えるのは間違いです。LPは-開発されたプログラムのジャーナル（ダイアグラム、スキーム、疑似コードフラグメント、つまりチャンクを含む）であるため、アーキテクチャなどです...紙のノートブックとまったく同じです。多くの開発者がそれらを使用していますが、プログラムの終了後です-あなたのノート、書類を捨てる...

昔、各物理学者、天文学者、化学者/錬金術師、数学者は、独自のノート、多くのスキームを含む原稿、必要な情報、表を持っています。これらがなければ、彼らの成功した経験、彼の結果を理解または繰り返すことができます。そして常にそのような人々の間にマヌクリープ/ノートの狩猟が存在します。

今日、多くのプログラマーがコードを記述しており、時にはコメントを追加しています！Bytプログラムはコードだけではありません-それは考え、アイデア、想像力、概念であり、新しい開発者がエイリアンコードを継承するとき-彼はすべてのアイデアと概念を頻繁に破り、異なる「抜け穴」と「バックドア」を作ります、私が理解してくれることを願っています:)

したがって、LPの（ツールとしての）主な要件は、単純で軽量で読みやすい構文でこれらすべてを許可することです。私は多くのLPツールを試しましたが、今日私は自分で開発しています-NanoLP（http://code.google.com/p/nano-lp/）は、この要求を達成することを目的としています。