なぜ今でもフラット ファイルを使ってプログラミングするのでしょうか?[閉まっている]
https://stackoverflow.com/questions/160633
-
03-07-2019 - |
italiano
english
français
española
中国
日本の
العربية
Deutsch
한국어
Português
Russian質問
フラット テキスト ファイルがソース コードを表現するための最新技術であるのはなぜですか?
確かに、プリプロセッサとコンパイラはファイルのフラット ファイル表現を参照する必要がありますが、それは簡単に作成できます。
何らかの形式の XML またはバイナリ データは、追跡するのが非常に困難な多くのアイデアを表す可能性があるように思えます。
たとえば、UML 図をコードに直接埋め込むことができます。これらは半自動的に生成され、開発者が設計の重要な側面を強調するために注釈を付けることができます。特に相互作用図。そうですね、ユーザーの描画を埋め込むと、状況がより明確になるかもしれません。
もう 1 つのアイデアは、コード レビューからのコメントをコードに直接埋め込むことです。
複数のブランチのマージを容易にするあらゆる種類の支援が存在する可能性があります。
私が熱心に取り組んでいることは、コード カバレッジを追跡するだけでなく、自動テストの対象となるコードの部分を確認することです。難しいのは、ソースが変更された場合でも、そのコードを追跡することです。たとえば、関数をあるファイルから別のファイルに移動するなどです。これは GUID を使用して実行できますが、テキスト ファイルに直接埋め込むのはかなり面倒です。リッチなファイル形式では、これらは自動的に行われ、目立たなくなる可能性があります。
では、なぜこのようにコードを操作できる IDE が (私の知る限りでは) 存在しないのでしょうか?
編集： 2009 年 10 月 7 日。
皆さんのほとんどは、私の質問の「バイナリ」という言葉に非常にこだわっていました。撤回します。画像 XML。コードのマークアップは最小限に抑えられます。通常のプリプロセッサまたはコンパイラに渡す直前に、XML マークアップをすべて取り除き、ソース コードのみを渡します。この形式でも、ファイルに対して通常の操作をすべて行うことができます。シンプルで最小限のエディターで差分、マージ、編集、操作を行い、それらを何千ものツールにフィードします。はい、最小限の XML マークアップを直接使用して差分、マージ、編集を行うと、少し複雑になります。しかし、その価値は非常に大きなものになる可能性があると思います。
すべての XML を尊重する IDE が存在すれば、現在できることよりもはるかに多くの機能を追加できるでしょう。
たとえば、DOxygen のコメントは実際には 見て 最終的な DOxygen 出力と同様です。
Code Collaborator のようにコード レビューを行いたい場合は、その場でソース コードをマークアップできます。
XML はコメントの背後に隠れることもあります。
// <comment author="mcruikshank" date="2009-10-07">
// Please refactor to Delegate.
// </comment>
vi または emacs を使用したい場合は、コメントをスキップしてください。
最先端のエディタを使用したい場合、約 12 種類の便利な方法でそれを確認できます。
これが私の大まかなアイデアです。画面上でドラッグするのは、写真の「積み木」ではありません。私はそこまで頭がおかしいわけではない。:)
解決
- それらを比較することができます
- それらをマージできます
- 誰でも編集できます
- これらはシンプルで扱いやすい
- これらは、何千ものツールから普遍的にアクセス可能です
他のヒント
私の意見では、特定のツールに結び付けられることで、考えられるメリットを上回ることができます。
プレーンテキストのソース（フラットファイル自体ではなく、議論しているようです）簡単なバージョン管理システムを使用して、チャンクをメールに貼り付けることができます（非常に重要です！ ）、Stack Overflowのコメントにコードを記述し、任意の数のプラットフォームで数千のテキストエディターの1つを使用します。
コードのバイナリ表現では、専用のエディターを使用して表示または編集する必要があります。テキストベースの表現を作成できる場合でも、変更を標準バージョンに簡単にロールバックすることはできません。
Smalltalkは画像ベースの環境です。ディスク上のファイル内のコードを使用しなくなりました。実行時に実際のオブジェクトを操作および変更しています。テキストのままですが、クラスは人間が読めるファイルに保存されません。代わりに、オブジェクトメモリ（画像）全体がバイナリ形式でファイルに保存されます。
しかし、smalltalkを試してみる人の最大の不満は、ファイルを使用しないためです。私たちが持っているほとんどのファイルベースのツール（vim、emacs、eclipse、vs.net、unixツール）は、smalltalk自身のツールを支持して放棄されなければなりません。 smalltalkで提供されるツールが劣っていることではありません。ただ違います。
なぜエッセイはテキストで書かれているのですか？法的文書がテキストで書かれているのはなぜですか？ファンタジー小説がテキストで書かれているのはなぜですか？なぜなら、テキストは、人々にとって、考えを持続させるための唯一の最良の形だからです。
テキストは、人々が概念をどのように考え、表現し、理解し、維持するか、およびその複雑さ、階層、相互関係を表します。
Lispプログラムはフラットファイルではありません。データ構造のシリアル化です。このデータとしてのコードは古いアイデアであり、実際にはコンピューターサイエンスの最大のアイデアの1つです。
<！> lt;？xml version = <！> quot; 1.0 <！> quot; encoding = <！> quot; UTF-8 <！> quot;？<！> gt; <！> lt; code <！> gt; Flatファイルは読みやすくなります。<！> lt; / code <！> gt ; <！> lt; / xml <！> gt;
理由は次のとおりです。
-
人間が読み取り可能。これにより、ファイルと解析方法の両方で間違いを見つけるのがはるかに簡単になります。大声で読み上げることもできます。これは、XMLでは得られないものであり、特にカスタマーサポートで違いが生じる可能性があります。
-
陳腐化に対する保険。正規表現が存在する限り、ほんの数行のコードで非常に優れたパーサーを書くことができます。
-
レバレッジ。リビジョン管理システムからフィルター処理するエディターまで、ほぼすべてのものがあり、フラットファイルの検査、マージ、操作が可能です。 XMLのマージは面倒です。
-
それらをgrep、cut、sedなどのUNIXツールとかなり簡単に統合する機能。
これはいい質問です。 FWIW、Wikiスタイルのコード管理ツールが見たいです。各機能ユニットには独自のWikiページがあります。ビルドツールは、Wikiからソースコードをまとめます。 <！> quot; discuss <！> quot;があります。そのページにリンクされているページ。ここでは、アルゴリズムやAPIなどについて議論できます。
まあ、既存のWiki実装からハックするのはそれほど難しくないでしょう。受験者...？
皮肉なことに、記述した内容を正確に使用するプログラミング構造があります。
たとえば、SQL Server Integration Servicesは、コンポーネントを視覚的なデザインサーフェイスにドラッグしてロジックフローをコーディングする必要があり、そのバックエンドを正確に記述するXMLファイルとして保存されます。
一方、SSISはソース管理がかなり困難です。複雑なロジックを設計することもかなり困難です。もう少し<！> quot; control <！> quot;が必要な場合は、VB.NETコードをコンポーネントにコーディングする必要があります。開始した場所に戻る。
コーダーとして、問題のすべての解決策には結果が伴うという事実を考慮する必要があると思います。 UMLですべてを表現できるわけではありません（また、そうすべきだと主張する人もいます）。すべてを視覚的に表現できるわけではありません。一貫性のあるバイナリファイル表現を得るためにすべてを十分に単純化できるわけではありません。
そうは言っても、コードをバイナリ形式に委譲することの不利な点（ほとんどが独自仕様である傾向もあります）は、プレーンテキストでコードを使用することの利点をはるかに上回ると思います。
IMHO、XML、およびバイナリ形式は完全に混乱し、大きな利点はありません。
OTOH、関連する考えは、データベースに書き込むことでしょう。おそらく、レコードごとに1つの関数、または階層構造です。この概念に基づいて作成されたIDEを使用すると、ソースのナビゲーションがより自然になり、特定の瞬間に読んでいるコードに関係のないものを簡単に隠すことができます。
人々は長い間、フラットファイルを超える編集環境を作成しようとしましたが、誰もがある程度失敗しました。私が見た中で最も近いものはチャールズ・シモニーの意図的プログラミングのプロトタイプでしたが、それは視覚的なDSL作成ツールに格下げされました。
コードがどのようにメモリに格納または表現されても、最終的にはテキストとして提示および変更可能である必要があります（書式を変更せずに）プログラミングによって問題を解決するために必要な抽象的な概念のほとんどを表現します。
フラットファイルを使用すると、これを無料で入手できます。また、（正しい文字エンコードサポートを備えた）プレーンテキストエディターはすべて動作します。
Steve McConnellは、いつものように正しく機能します。コンピューターではなく、他のプログラマー（自分を含む）のためにプログラムを作成します。
とはいえ、Microsoft Visual Studioは、非常に構造化された形式で記述するコードを内部で管理する必要があります。そうしないと、<！> quot;すべての参照を検索<！> quot;または、変数とメソッドの名前変更やリファクタリングを簡単に実行できます。誰かがこれがどのように機能するかについてのリンクがあれば興味があります。
実際、およそ10年前、意図的なプログラミングのためのCharles Simonyiの初期のプロトタイプは、フラットファイルを超えて、さまざまな方法で視覚化できるコードのツリー表現に移行しようとしました。理論的には、ドメインエキスパート、PM、およびソフトウェアエンジニアはすべて、有用な方法でアプリケーションコードを表示（および結合）でき、製品は宣言的な<！> quot; intention <！>の階層で構築できます。 quot ;、必要な場合にのみ低レベルコードに掘り下げます。
ETA（質問のリクエストごと） oneのコピーがありますマイクロソフトのリサーチWebサイトで彼の初期論文について。残念ながら、Simonyiは数年前にMSを離れて別の会社を立ち上げたので、プロトタイプがまだダウンロードできるとは思いません。マイクロソフトにいたときに戻っていくつかのデモを見ましたが、彼の初期のプロトタイプがどれほど広く配布されたかはわかりません。
彼の会社、 IntentSoft は、彼らが市場に提供しようとしていることについてまだ少し静かです。 、どちらかといえば、MSRから出てきた初期のもののいくつかはかなり興味深いものでした。
ストレージモデルは何らかのバイナリ形式でしたが、MSRプロジェクト中にそれらの詳細がどれだけ開示されたかはわかりません。また、初期の実装以降、いくつかの変更が加えられたと確信しています。
テキストファイルが支配するのはなぜですか？ McIlroyのテストのため。あるプログラムの出力を別のプログラムのソースコードとして受け入れられるようにすることが重要であり、テキストファイルが最も簡単に機能します。
<！> quot;何らかの形式のXML <！> quot ;? XHTMLとXAMLは何だと思いますか？
XMLもやはり単なるフラットファイルです。
古い習慣は一生懸命に死んでいると思います。
最近まで、構造化データの一般的なストレージ用の高品質で高性能で広く利用可能なライブラリは多くありませんでした。そして、今日でもXMLをそのカテゴリに 入れないことを強調します。
最近、人間が読めるようにする必要のないデータに使用する私のお気に入りは、 SQLite で、データベース。フル機能のSQLデータベースを任意のアプリに組み込むのは非常に簡単です... C、Perl、Python、PHPなどのバインディングがあり、オープンソースであり、非常に高速で信頼性が高く、軽量です。 I <！> lt; 3 SQLite。
誰もが Mathematica ？
上の写真は古いバージョンのものですが、グーグルが私に与えることができる最高のものでした。
とにかく...最初の方程式を Math.Integrate（1 /（Math.Pow（<！> quot; x <！> quot;、3）-1）、<！> quot;と比較してくださいx <！> quot;）は、ほとんどの一般的な言語でプレーンテキストを使用してコーディングする場合に記述する必要があります。 Imoの数学的表現ははるかに読みやすく、それでもかなり小さい方程式です。
そしてもちろん、必要に応じてコードをプレーンテキストとして入力およびコピーアンドペーストできます。
次世代の構文強調表示としてそれを参照してください。私は、この種の表現から利益を得ることができる数学以外の多くのものがあると確信しています。
プレーンテキストが重要な理由は明らかです。しかし、構造化されたフォーマットがさらに優れている理由も同様に明らかです。
1つの例：メソッドの名前を変更すると、diff / merge / source controlツールは、1つの変更のみが行われたことを認識できます。現在使用しているツールには、メソッドの呼び出しや宣言が行われた場所やファイルごとに1つずつ、長い変更点のリストが表示されます。
（ちなみに、この投稿はお気づきかもしれませんが質問には答えていません）
DSLについて私たちが見ている傾向は、質問を読むときに最初に頭に浮かぶものです。問題は、モデル（UMLなど）と実装の間に1対1の関係が存在しないことです。とりわけMicrosoftは、アプリをUMLのようなものとして作成し、コードを生成できるように、そこに到達するために取り組んでいます。そして重要なこと-コードを変更することを選択すると、モデルはこれを再び反映します。
Windows Workflow Foundationは非常に良い例です。原因として、フラットファイルやXMLがバックグラウンドで存在しますが、通常はオーケストレーションツールでビジネスロジックを定義することになります。そしてそれはかなりクールです！
さらに多くの<！> quot;ソフトウェアファクトリー<！> quot;将来的にはより豊富なIDEエクスペリエンスが実現しますが、コンピューターがゼロと1で実行されている限り、フラットテキストファイルは常に（おそらく）中間段階になります。すでに数人が述べているように、単純なテキストファイルは非常に柔軟です。
次の回答で説明されているように、同じことを切望して思いました。 どのツール/アプリケーション/何が存在したいですか
多くのメリットを想像するのは簡単ですが、対処しなければならない最大のハードルは、誰も実行可能な代替案を生み出していないということです。
人々がソースをテキストとして保存する代替案を考えるとき、彼らはしばしばグラフィック表現の観点からすぐに考えるように思われます（私はここで利用可能な市販の製品、例えばHP-veeを参照しています）。 また、FPGA設計者などの経験を見ると、（排他的に）グラフィカルなプログラミングが機能しないことがわかります。したがって、VerilogやVHDLなどの言語です。
しかし、ソースのストレージは、そもそもそれを書き込む方法にバインドする必要があるとは思いません。 ソースの入力は主にテキストとして行うことができます。つまり、コピー/貼り付けの問題は引き続き達成できます。 しかし、トークン化されたメタソースに基づいてマージとロールバックを許可することにより、より正確で強力な操作ツールを実現できることもわかりました。
Visual FoxProは、dbfテーブル構造を使用して、フォーム、レポート、クラスライブラリなどのコードとメタデータを格納します。これらはバイナリファイルです。また、実際のテキストファイルであるprgファイルにコードを保存します...
私が見る唯一の利点は、組み込みのVFPデータ言語を使用して、これらのファイルでコード検索を実行できることです。少なくとも数か月に1回は、これらのファイルの1つが明確な理由なしに破損します。ソース管理や差分との統合も非常に苦痛です。これには回避策がありますが、ファイルを一時的にテキストに変換する必要があります！
従来のテキストプログラミングを廃止した言語の例については、 Lavaをご覧ください。言語。
プログラムのコードは、xmlまたはバイナリ形式で作成される構造を定義します。プログラミング言語は、XMLやバイナリ表現よりもプログラムの構造をより直接表現しています。文書に構造を与える際に、Wordがどのように誤動作するかに気付いたことがありますか。 WordPerfectは、少なくとも「コードを明らかにする」ことで、ドキュメントの下にあるものを見ることができます。フラットファイルは、プログラムに対して同じことを行います。
素敵なアイデアですね。私自身、もっと小さなスケールで疑問に思ったことがある...はるかに小さいのに、IDE X があれやこれやを生成できないのはなぜでしょうか。
私がプログラマーとして、あなたが話していることや私が考えていることと同じくらいクールで複雑なものを開発する能力がまだあるかどうかはわかりませんが、試してみたいと思っています。
まずは .NET、Eclipse、Netbeans などのプラグインから始めてみてはいかがでしょうか?何ができるかを誇示し、コーディングの新しいトレンドを始めましょう。
これの別の側面は、コードが重要なことだと思います。実行されるものです。たとえば、UMLの例では、UML（おそらく<！> quot; code <！> quot;に直接関連しないエディターで作成されたもの）を<！> quot; source blob <に含めるのではなく、 ！> quot;ほとんど役に立たないでしょう。コードからUMLを直接生成する方がはるかに優れているため、コードの本来の状態を思い出させるのではなく、コードを理解するためのツールとしてコードの正確な状態を説明します。
自動化されたドキュメントツールに関してこれを長年行ってきました。実際のプログラマーがコード内でコメントを生成すると、コードと同期しなくなる可能性がありますが、JavaDocなどのツールはオブジェクトのメソッド、戻り値の型、引数などを忠実に表します。無限のデザイン会議から生まれたアーティファクト。
ランダムに任意のアーティファクトを<！> quot; source blob <！> quot;に任意に追加できた場合、これらは古く、すぐには役に立たない可能性が高いようです。このようなアーティファクトをコードから直接生成できる場合、ビルドプロセスを実行するための小さな労力は、プレーンテキストソースファイルから移動する前述の落とし穴よりもはるかに優れています。
これに関連して、理由の説明'プレーンテキストUMLツールを使用したい（ UMLGraph ）はほぼ同等に適用されるようですプレーンテキストのソースファイルが必要な理由も同様です。
これはあなたの質問に正確に答えないかもしれませんが、ここではエディターがコードのより高いビューを持つことができます： http://webpages.charter.net/edreamleo/front.html
テキストファイルが開発で使用される理由は、さまざまな開発ツールに対して普遍的であるためだと思います。簡単なテキストエディターを使用して、内部を確認したり、エラーを修正することもできます（修正によって他のデータがどのように破壊されるかが分からないため、バイナリファイルで修正することはできません）。ただし、テキストファイルがこれらすべての目的に最適であることを意味するわけではありません。
もちろん、それらを比較およびマージできます。しかし、diff / mergeツールがこのテキストファイルでエンコードされたデータの明確な構造を理解しているという意味ではありません。 diff / mergeはできますが、（特にXMLファイルで見られる）diffツールは違いを正しく表示しません。つまり、ファイルがどこで異なり、データのどの部分がツール<！>であるかを示します。 quot; thinks <！> quot;同じだ。ただし、XMLファイルの構造の違いは表示されません。同じように見える行に一致するだけです。
バイナリファイルまたはテキストファイルを使用しているかどうかに関係なく、diff / mergeツールは、行や文字ではなく、このファイルが表すデータ構造を処理する方が常に優れています。たとえば、C ++またはJavaファイルの場合、一部の識別子の名前が変更されたこと、一部のセクションが追加のif（）{}で囲まれていることを報告しますが、インデントまたはEOL文字の変更は無視します。最善のアプローチは、ファイルが内部構造に読み込まれ、特定の形式規則を使用してダンプされることです。このようにして、内部構造を介して差分が作成され、マージされた内部構造からマージ結果が生成されます。
現代のプログラムは平らな部分で構成されていますが、平らですか？オブジェクトの使用法、インクルード、ライブラリーなどがあります。通常の関数呼び出しは、別の場所を覗くものです。複数のスレッドなどがあるため、ロジックはフラットではありません。
同じビジョンを持っています！これが存在することを本当に願っています。
Sunの研究言語であるFortressをご覧ください。ソースコードの数式を特別にサポートしています。以下の引用はウィキペディアからのものです
要塞は 複数の構文を持つための開始 スタイルシート。ソースコードは ASCIIテキスト、Unicode、または きれいな画像として。これにより 数学記号のサポート用 およびレンダリングされた他のシンボル 読みやすくするための出力。
ソースとしてテキストが保持される主な理由は、非テキスト日付などのバージョン管理などのpowertoolsの欠如です。これは、Smalltalkでの私の経験に基づいています。Smalltalkでは、プレーンバイトコードが常にコアダンプに保持されます。今日のツールを備えた非テキストシステムでは、チーム開発は悪夢です。
