flat-file - フラットファイルを使ってプログラミングを続けるのはなぜですか?

Question

フラットテキストファイルがソースコードを表現するための最新技術であるのはなぜですか?

確かに - プリプロセッサとコンパイラはファイルのフラットファイル表現を確認する必要がありますが、それは簡単に作成できます。

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 を使いたい場合は、コメントを飛ばしてください。

最先端のエディターを使用したい場合、約 10 種類の便利な方法でそれを確認できます。

だから、それは私の大まかな考えです。画面上でドラッグするのは、写真の「積み木」ではありません... 私はそんなに好きではありません。:)

score 140 · Accepted Answer

あなたはそれらを比較することができます
あなたはそれらをマージすることができます
誰でも編集できます
シンプルで扱いやすい
それらは何千ものツールから普遍的にアクセス可能です

score 25 · Accepted Answer

私の意見では、特定のツールに縛られていることは、考えられるメリットよりも重要です。

プレーンテキストソース (フラットファイル自体ではなく、あなたが話しているようです) を使用すると、チャンクをメールに貼り付けたり、シンプルなバージョン管理システムを使用したり (非常に重要です!)、スタックオーバーフローのコメントにコードを書き込んだりできます。任意の数のプラットフォームで 1,000 のテキストエディターのうちの 1 つを使用するなど。

コードの一部のバイナリ表現を表示または編集するには、専用のエディターを使用する必要があります。テキストベースの表現を生成できたとしても、変更を標準バージョンに単純にロールバックすることはできません。

score 14 · Accepted Answer

Smalltalk はイメージベースの環境です。ディスク上のファイルでコードを操作する必要はなくなりました。実行時に実際のオブジェクトを操作および変更しています。それはまだテキストですが、クラスは人間が読めるファイルに保存されていません。代わりに、オブジェクトメモリ全体 (イメージ) がバイナリ形式でファイルに保存されます。

しかし、smalltalk を試している人の最大の不満は、ファイルを使用しないことです。私たちが持っているファイルベースのツール (vim、emacs、eclipse、vs.net、unix ツール) のほとんどは、smalltalk 独自のツールを優先して放棄する必要があります。smalltalk で提供されるツールが劣っているわけではありません。それはただ違う。

score 11 · Accepted Answer

エッセイはなぜテキストで書かれているのですか？法律文書はなぜテキストで書かれているのですか？ファンタジー小説はなぜテキストで書かれているのですか？テキストは、人々にとって、自分の考えを持続させるための唯一の最良の形式だからです。

テキストは、人々が概念、およびその複雑さ、階層、相互関係について考え、表現し、理解し、保持する方法です。

score 11 · Accepted Answer

Lisp プログラムはフラットファイルではありません。それらはデータ構造のシリアル化です。このデータとしてのコードは古いアイデアであり、実際にはコンピューターサイエンスにおける最も優れたアイデアの 1 つです。

score 8 · Accepted Answer

<?xml version="1.0" encoding="UTF-8"?><code>フラットファイルの方が読みやすい</code></xml>

score 7 · Accepted Answer

いい質問です。FWIW、Wiki スタイルのコード管理ツールが欲しいです。各機能ユニットには独自の wiki ページがあります。ビルドツールは、wiki からソースコードをまとめます。そのページにリンクされた「ディスカッション」ページがあり、アルゴリズムや API などについて議論することができます。

まあ、既存の Wiki 実装からハッキングするのはそれほど難しいことではありません。受験者は…？

score 7 · Accepted Answer

理由は次のとおりです。

人間可読。これにより、ファイルと解析方法の両方で間違いを見つけやすくなります。声に出して読むこともできます。これは XML では得られないものであり、特に顧客サポートにおいて違いを生む可能性があります。
陳腐化に対する保険。正規表現が存在する限り、わずか数行のコードで非常に優れたパーサーを作成できます。
てこの作用。リビジョン管理システムからエディター、フィルターに至るまで、そこにあるほとんどすべてのものは、フラットファイルを検査、マージ、および操作できます。XML のマージは混乱する可能性があります。
grep、cut、sed などの UNIX ツールと簡単に統合できます。

score 5 · Accepted Answer

皮肉なことに、あなたが記述したものを正確に使用するプログラミング構造があります。

たとえば、コンポーネントを視覚的なデザインサーフェイスにドラッグしてロジックフローをコーディングする SQL Server Integration Services は、そのバックエンドを正確に記述した XML ファイルとして保存されます。

一方、SSIS はソース管理がかなり困難です。また、複雑なロジックを設計するのもかなり困難です。もう少し「制御」が必要な場合は、VB.NET コードをコンポーネントにコーディングする必要があります。

コーダーとして、問題のすべての解決策には結果が伴うという事実を考慮する必要があると思います。すべてが UML で表現できるわけではありません (また、UML で表現する必要があると主張する人もいます)。すべてを視覚的に表現できるわけではありません。すべてを単純化して、一貫したバイナリファイル表現を実現できるわけではありません。

そうは言っても、コードをバイナリ形式 (そのほとんどはプロプライエタリなものになる傾向があります) に追いやることの欠点は、それらをプレーンテキストにすることの利点をはるかに上回っていると思います。

score 5 · Accepted Answer

人々は長い間、フラットファイルを超える編集環境を作ろうと試みてきましたが、誰もがある程度失敗しています。私が見た中で最も近いものは、Charles Simonyi の Intentional Programming のプロトタイプでしたが、その後、ビジュアル DSL 作成ツールに格下げされました。

コードがどのようにメモリに格納または表現されても、最終的には (フォーマットを変更することなく) テキストとして表示および変更できる必要があります。プログラミングで問題解決。

フラットファイルを使用すると、これを無料で入手でき、(正しい文字エンコーディングをサポートする) プレーンな古いテキストエディターで動作します。

score 4 · Accepted Answer

実際、およそ10年前、意図的なプログラミングのためのCharles Simonyiの初期のプロトタイプは、フラットファイルを超えて、さまざまな方法で視覚化できるコードのツリー表現に移行しようとしました。理論的には、ドメインエキスパート、PM、およびソフトウェアエンジニアはすべて、自分たちに役立つ方法でアプリケーションコードを確認（および統合）でき、製品は宣言型の「意図」の階層に基づいて構築され、低レベルまで掘り下げられます。必要な場合にのみレベルコード。

ETA（質問のリクエストごと）これに関する彼の初期の論文の1つのコピーがMicrosoftResearchWebサイトにあります。残念ながら、シモニーは数年前に別の会社を立ち上げるためにMSを去ったので、プロトタイプはまだダウンロードできないと思います。私がマイクロソフトにいたときにいくつかのデモを見ましたが、彼の初期のプロトタイプがどれほど広く配布されたかはわかりません。

彼の会社であるIntentSoftは、市場に提供する予定の内容についてはまだ少し静かですが、MSRから生まれた初期のもののいくつかは非常に興味深いものでした。

ストレージモデルはバイナリ形式でしたが、MSRプロジェクト中にこれらの詳細がどれだけ開示されたかはわかりません。また、初期の実装以降、いくつかの点が変更されたと確信しています。

score 4 · Accepted Answer

IMHO、XML、およびバイナリ形式は完全に混乱し、大きなメリットはありません。

OTOH、関連するアイデアは、データベース、おそらくレコードごとに1つの関数、または階層構造に書き込むことです。この概念に基づいて作成された IDE は、ソースのナビゲートをより自然にし、特定の瞬間に読んでいるコードに関係のないものを簡単に隠すことができます。

score 4 · Accepted Answer

いつものように、Steve McConnell の言うとおりです。プログラムは、コンピューターではなく、他のプログラマー (自分自身を含む) のために作成します。

とはいえ、Microsoft Visual Studio は、非常に構造化された形式で記述したコードを内部で管理する必要があります。そうしないと、「すべての参照を検索」したり、変数やメソッドの名前を変更したりリファクタリングしたりすることが簡単にできなくなります。誰かがこれがどのように機能するかについてのリンクを持っていれば、私は興味があります。

score 3 · Accepted Answer

LabviewとSimulinkは、2 つのグラフィカルプログラミング環境です。どちらもそれぞれの分野 (PC からハードウェアへのインターフェース、および制御システムのモデリング) で人気がありますが、それらの分野以外ではあまり使用されていません。私は両方の大ファンだった人々と一緒に仕事をしたことがありますが、私自身はそれらに夢中になったことはありません.

score 3 · Accepted Answer

古い習慣は死ぬのが難しいと思います。

最近まで、構造化データの一般的なストレージ用の高品質でパフォーマンスが高く、広く利用できるライブラリはあまりありませんでした。そして、XML を今日でもそのカテゴリーに入れるつもりはありません。つまり、冗長すぎて、処理に負荷がかかりすぎて、細心の注意を払いすぎているからです。

最近、人間が読める必要のないデータに使用する私のお気に入りの方法はSQLiteで、データベースを作成します。フル機能の SQL データベースを任意のアプリに埋め込むのは信じられないほど簡単です... C、Perl、Python、PHP などのバインディングがあります...そしてオープンソースであり、非常に高速で信頼性が高く、軽量です。

私 <3 SQLite。

score 3 · Accepted Answer

テキストファイルが支配するのはなぜですか？マキロイのテストのため。あるプログラムの出力を別のプログラムのソースコードとして受け入れられるようにすることが重要であり、テキストファイルは最も簡単に機能します。

score 2 · Accepted Answer

Mathematicaを試したことのある人はいますか？

上の写真は古いバージョンのものですが、Google が提供してくれる最高のものでした。

とにかく...最初の方程式をMath.Integrate(1/(Math.Pow("x",3)-1), "x")と比較してください一般的な言語。Imo の数学的表現ははるかに読みやすく、それはまだかなり小さな方程式です。

はい、必要に応じて、コードをプレーンテキストとして入力し、コピーして貼り付けることができます。

次世代の構文強調表示と考えてください。この種の表現から利益を得ることができる数学以外のものがたくさんあるに違いない.

score 1 · Accepted Answer

フラットファイルを扱うのは誰ですか？

Eclipseはソースのビューを提供するので、内部クラス、メソッド、およびデータをすべてソートおよびグループ化して表示できます。内部クラスを編集したい場合は、それをクリックします。技術的には基礎となるフラットファイルがありますが、そのようにナビゲートすることはほとんどありません。

score 1 · Accepted Answer

プレーンテキストが王様である理由は明らかです。しかし、構造化された形式がさらに優れている理由も同様に明らかです。

ほんの一例: メソッドの名前を変更した場合、差分/マージ/ソース管理ツールは、変更されたのは 1 つだけであると判断できます。現在使用しているツールは、メソッドが呼び出されたり宣言されたりした場所やファイルごとに 1 つずつ、長い変更リストを表示します。

(ちなみに、お気づきかもしれませんが、この投稿は質問への回答ではありません)

score 1 · Accepted Answer

「なんらかの形式の XML」を使用する必要があるとおっしゃいましたか。XHTML と XAML は何だと思いますか?

また、XML は依然として単なるフラットファイルです。

score 1 · Accepted Answer

への回答で説明されているように、私は同じことを切望していました。どのツール/アプリケーション/何があればいいですか?

多くのメリットがあることは容易に想像できますが、対処しなければならない最大のハードルは、誰も実行可能な代替案を作成していないことだと思います。

ソースをテキストとして保存する代わりの方法を考えるとき、すぐにグラフィカル表現の観点から考えることが多いようです (ここでは、利用可能な商用製品について言及しています。たとえば、HP-vee です)。そして、FPGA 設計者のような人々の経験を見ると、(もっぱら) グラフィカルなプログラミングは機能しないことがわかります。つまり、Verilog や VHDL などの言語です。

しかし、ソースのストレージは、そもそもそれを記述する方法に必ずしもバインドする必要があるとは思いません。ソースの入力は主にテキストとして行うことができます。つまり、コピー/貼り付けの問題は引き続き達成できます。しかし、トークン化されたメタソースに基づいてマージとロールバックを実行できるようにすることで、より正確で強力な操作ツールを実現できることもわかりました。

score 1 · Accepted Answer

Visual FoxPro は、dbf テーブル構造を使用して、フォーム、レポート、クラスライブラリなどのコードとメタデータを格納します。これらはバイナリファイルです。また、実際のテキストファイルである prg ファイルにコードを保存します。

私が見る唯一の利点は、組み込みの VFP データ言語を使用して、それらのファイルでコード検索を実行できることです...それ以外は、責任があるということです。少なくとも数か月に 1 回、これらのファイルの 1 つが理由もなく破損します。ソース管理と差分との統合も非常に苦痛です。これには回避策がありますが、ファイルを一時的にテキストに変換する必要があります。

score 1 · Accepted Answer

従来のテキストプログラミングを廃止した言語の例については、Lava 言語を参照してください。

最近発見したもう 1 つの気の利いたものは、subtext2 (ビデオデモ) です。

score 1 · Accepted Answer

あなたの質問を読んで最初に頭に浮かぶのは、DSL について私たちが目にしている傾向です。問題は、モデル (UML など) と実装の間に 1 対 1 の関係が存在しないことです。Microsoft などは、UML のようなものとしてアプリを作成し、コードを生成できるように、その実現に向けて取り組んでいます。そして重要なこと - コードを変更することを選択すると、モデルはこれを再び反映します。

Windows Workflow Foundation は非常に良い例です。バックグラウンドでフラットファイルや XML が存在するのは当然ですが、通常はオーケストレーションツールでビジネスロジックを定義することになります。そして、それはかなりクールです！

「ソフトウェアファクトリ」の考え方がもっと必要であり、将来的にはよりリッチな IDE エクスペリエンスが見られるでしょう。すでに何人かが述べているように、単純なテキストファイルは非常に柔軟です。

score 0 · Accepted Answer

触れられていないことの1つは、一部の言語には、変数のスコープなどに関してソースファイルの概念が組み込まれていることです。他の何かに変更する（データベースに関数を格納するなど）には、言語自体を変更する必要があります。

score 0 · Accepted Answer

これはあなたの質問に正確に答えないかもしれませんが、ここにエディターがコードのより高いビューを持つことを可能にします： http ://webpages.charter.net/edreamleo/front.html

score 0 · Accepted Answer

プログラムのコードは、xml またはバイナリ形式で作成される構造を定義します。プログラミング言語は、XML やバイナリ表現よりもプログラムの構造をより直接的に表現したものです。文書に構造を与えると、Word がどのように誤動作するかに気づいたことがありますか。WordPerfect は、少なくとも「コードを表示」して、ドキュメントの下にあるものを確認できるようにします。フラットファイルは、プログラムに対して同じことを行います。

score 0 · Accepted Answer

私は同じビジョンを持っています！私は本当にこれが存在することを望みます。

Fortress は、Sun の研究言語です。ソースコード内の数式を特別にサポートしています。以下、ウィキペディアより引用

Fortress は最初から複数の構文スタイルシートを持つように設計されています。ソースコードは、ASCII テキスト、Unicode、またはきれいな画像としてレンダリングできます。これにより、レンダリングされた出力で数学記号やその他の記号をサポートできるようになり、読みやすくなります。

テキストをソースとして保持する主な理由は、テキスト以外の日付のバージョン管理などの強力なツールがないことです。これは、平文のバイトコードが常にコアダンプに保持される Smalltalk での私の経験に基づいています。今日のツールを使用した非テキストシステムでは、チーム開発は悪夢です。

score 0 · Accepted Answer

おそらくそれがソフトウェアツールを販売する方法なので、それはまだフラットファイルです:D

ソースコード自体は、メンバーとしてカプセル化されたオブジェクト指向である必要があります。私が知っている唯一の製品で、これは非常に長い間 (Windows 3.0) から存在し、Paul Allen 自身によって設計されています。これはもともと Mac の Hypercard に触発されたものですが、Bill Gates が次のように語っています。

「それは HyperCard を超えた世代です」と Gates は言います。

残念ながら、彼らは適切な人々をターゲットにしていませんでした:

In pursuing (interests of) software developers,'' says Alsop, AsymetrixToolBook は小さな男には複雑すぎるかもしれません。」

彼らは、愛好家ではなくプロのプログラマーをターゲットにするべきでした。

今日でも概念レベルでは、もちろん Rebol 以外の他の言語を超えています ;)

score 0 · Accepted Answer

開発でテキストファイルを使う理由は、さまざまな開発ツールに対して万能だからだと思います。単純なテキストエディタを使用して、内部を調べたり、一部のエラーを修正したりすることもできます (修正によって他のデータがどのように破壊されるかわからないため、バイナリファイルでは実行できません)。ただし、テキストファイルがこれらすべての目的に最適であるとは限りません。

もちろん、それらを比較してマージすることもできます。ただし、差分/マージツールが、このテキストファイルによってエンコードされたデータの明確な構造を理解しているという意味ではありません。diff/merge を実行できますが、(特に XML ファイルで見られる) diff ツールは違いを正しく表示しません。つまり、ファイルの違いと、ツールが「考える」データの部分を示します。同じだ。ただし、XML ファイルの構造の違いは表示されません。同じように見える行が一致するだけです。

バイナリファイルを使用しているかテキストファイルを使用しているかに関係なく、差分/マージツールは、行や文字ではなく、このファイルが表すデータ構造を処理する方が常に優れています。たとえば、C++ または Java ファイルの場合、一部の識別子がその名前を変更したことを報告し、一部のセクションが追加の if(){} で囲まれていることを報告しますが、一方で、インデントまたは EOL 文字の変更は無視します。最善の方法は、ファイルを内部構造に読み込み、特定のフォーマットルールを使用してダンプすることです。このようにして、内部構造を介して差分が作成され、マージ結果がマージされた内部構造から生成されます。

score 0 · Accepted Answer

ナイスアイデア。私自身、もっと小さい規模で疑問に思っていました...はるかに小さいのに、なぜIDE Xはこれまたはあれを生成できないのでしょうか。

あなたが話していることや私が考えていることと同じくらいクールで複雑なものを開発するプログラマーとしての能力があるかどうかはわかりませんが、試してみたいと思います.

.NET、Eclipse、Netbeans などのプラグインから始めてみませんか? 何ができるかを示し、コーディングの新しいトレンドを開始します。

score 0 · Accepted Answer

これのもう 1 つの側面は、コードが重要だということだと思います。それが実行されるものです。たとえば、UML の例では、UML (おそらく「コード」に直接関係なく、何らかのエディターで作成されたもの) を「ソース blob」に含めるのではなく、ほとんど役に立たないと思います。UML をコードから直接生成する方がはるかに優れているため、コードがどうあるべきかを思い出すためではなく、コードを理解するためのツールとしてコードの正確な状態を記述します。

自動化されたドキュメントツールに関しては、これを何年も行ってきました。実際のプログラマーがコード内にコメントを生成すると、コードと同期しなくなる可能性がありますが、JavaDoc などのツールは、オブジェクトのメソッド、戻り値の型、引数などを忠実に表現します。無限の設計会議から生まれたアーティファクト。

ランダムなアーティファクトをいくつかの「ソースブロブ」に任意に追加できるとしたら、これらはおそらく時代遅れになり、すぐには役に立たなくなると思われます。このようなアーティファクトをコードから直接生成できる場合は、ビルドプロセスで生成するためのわずかな労力で、前述のプレーンテキストソースファイルから離れることによる落とし穴よりもはるかに優れています。

これに関連して、プレーンテキストの UML ツール( UMLGraph ) を使用する理由の説明は、プレーンテキストのソースファイルが必要な理由とほぼ同じように当てはまるようです。

score 0 · Accepted Answer

現代のプログラムはフラットな要素で構成されていますが、それらはフラットなのでしょうか? オブジェクトの使用、インクルード、ライブラリなどがあります。通常の関数呼び出しは、別の場所への覗き見です。複数のスレッドがあるなどの理由で、ロジックはフラットではありません。

score 0 · Accepted Answer

今夜、友人 (プログラマーも) と酒を飲んでいるときに、そのうちの 1 人が UML を使用してコードを生成していると言っていました。しかし彼は、生成されたコードを手動で編集する必要があり、UML で簡単に記述できない問題ドメインがいくつかあると述べました。

すべての LINQ の利点、ラムダ、およびすべてを使用して、一部の問題ドメインは UML で表現できません。コンピューターが入札を行うために、生成されたコードを回避する必要があります。

XML は言うまでもなく、次の問題を UML でどのように表現できるでしょうか? GROUP BY と COUNT(DISTINCT) を使用した LINQ to SQL

この単純な問題に対する答えの量は、UML、SQL (最も重要なアセンブリ言語であり、ORM 担当者が別の言い方をしても)、XML が XOR 命題ではないことを示しています。私たちは、これらのテクノロジーの組み合わせを引き続き使用し、他のテクノロジーを排除するためにそれらの 1 つだけを使用するのではありません。

flat-file - フラットファイルを使ってプログラミングを続けるのはなぜですか?

34 に答える 34

Related

Reference