システムを100％データ駆動型にすることはできますか？
私の上司は長年このプロジェクトに取り組んできました。私はここに数週間しか来ていませんが、それが可能かどうかはわかりません。 「100％データ駆動型」のシステムを設計したいと考えています。
したがって、十分なデータを入れれば、アプリケーションを定義して生成できます。私は少なくとも彼にユーザーなどのいくつかのものを認めさせることができました、またはアプリは事前定義された値を持っている必要がありますが、彼はシステムの構造、ユーザーインターフェイス、およびロジックがすべてデータとして格納されているという概念を気に入っています。
単純なもののデモがいくつかあり、彼は基本的にオブジェクト指向プログラミングと基本的なテンプレートシステムのいくつかの単純なアイデアを再発見しましたが、全体としてこの目標は実際には不可能かもしれないと思います。
とにかく実際にプログラミングをしているほどシステムが複雑になることなく、データを使用してロジックを定義する方法を知りません。
理論的には、アプリケーションを説明するためにデータを解釈するものが完全にチューリングする必要があり、正味の利益がないように問題を1レベル上にシフトしただけではないと思います。
このような100％データ駆動型アプリケーションは可能ですか？
上司はこの部分を読む必要があります： 悪いカルマ：「ビジョン」プロジェクト、内部プラットフォーム効果または2番目のシステム効果に関する注意書き
概要
情報技術（IT）に携わっている私たち全員が、何か重要なことが正しくないプロジェクトに取り組んでいます。私たちはそれを知っています、ほとんどの人はそれを知っていますが、誰もが説得力のある方法で問題に指を置くことはできません。
この話は、私が今まで経験した中で最も壮観な失敗である、そのようなITプロジェクトについてです。その結果、中規模のIT部門が完全に解雇され、最終的には成長中の業界で成長している企業の破壊につながりました。 「アップスタート」と呼ぶこの会社は、成功し収益性の高いサブスクリプションテレビビジネスでした。
このプロジェクトは1990年代初頭に発生し、現在は顧客関係管理（CRM）と呼ばれているものに非常によく似ており、カスタム作成された注文入力および顧客サービスアプリケーションでした。システムのコア機能は次のとおりです。
- 注文と在庫
- カスタマーサービス、ヘルプデスク
- 総勘定元帳、売掛金、請求、および買掛金
このアプリケーションは「ビジョン」と呼ばれ、その名前はUpstartへの正式な約束であり、そのアーキテクトへの自己主張的なうなずきでもありました。このアプリケーションは革新的であり、将来のビジネスの変化に対応するのに十分な柔軟性を持つように構築されています。ビジネスへの予測可能な将来の変更だけでなく、ビジネスへの絶対的な変更も、あらゆる形で。それは非常に注目に値する主張でしたが、ビジョンはこれまでに構築された最後のアプリケーションになることを目的としていました。 完全にデータ駆動型であり、無限の抽象化を提供し、当時最先端であったオブジェクト指向プログラミング技術を使用することで、この完全な柔軟性を実現しました。
ミッションクリティカルなアプリケーションの作成に着手した多くのそのようなプロジェクトと同様に、開発作業は2年間にわたり、当初の計画よりも約1年長くかかりました。しかし、これは永遠に続くアプリケーションであり、将来の要件に適応し、無制限の投資収益率（ROI）を提供するアプリケーションであったため、それは受け入れられました。アプリケーションがようやく「稼働」したとき、会社のほぼ全員が多額の投資をしていたため、文字通り会社の運命は成功にかかっていました。
しかし、プロジェクト全体が機能不全になった場合、多国籍企業の中核ビジネスを実行するミッションクリティカルなアプリケーションは、インターネットバブル時代の何千もの「ドットコム」企業が示したタイプの高速フレームアウトの贅沢を許可されません。ビジョンが「稼働」してから1か月も経たないうちに、その建設に大いに力を注いだ人を除いて、それが失敗であることが明らかになりました。
こちらもご覧ください
答えは「はい」です。完全にデータ駆動型のシステムを作成することは可能であり、「はい」は通常、非常に悪い考えです。
完全にデータ駆動型のプログラムとは、すべてのロジックと構成が、別のコンテキストではデータと見なされるような方法で格納された値によって処理されるプログラムです。 1980年代に生産された4GL製品の多くは、多数のフォームに入力され、テーブルに格納され、レポートからアクセスできるデータ項目を使用して、レポート、フォーム、テーブル、ロジックを生成する機能を提供しました。以前は「数字によるペイント」と呼んでいましたが、「内部システム」効果として知られるようになりました。いい名前。
これらのシステムを作成する人々は、（それを知っているかどうかにかかわらず）新しいプログラミング言語を作成しようとしています。彼らはスキルを持っていないので、ひどくそれをします。 JVM/CLRの観点からは、コンパイルされたJava/C＃プログラムは単なるデータです。この場合、それはうまく行われています。どちらの場合でも、言語は何であれ、プログラマーは言語を使用する必要があります。
私が知っている、これを機能させる特定の方法が1つあります。必要な各コンポーネント（フォーム、レポート、テーブルなど）のスケルトンを構築します。データ項目を設定することにより、これらのコンポーネントのさまざまな部分を構成するメカニズムを提供します。選択した機能のセットについて、決定を下してシステムに固定し、特にそれらの機能を構成する機能を拒否します。
また、論理演算をコーディングする機能を持つ言語を実装します。私の推奨は、luaやPythonなどの既存の言語を使用することです。このコードの一部は、論理演算が必要な場所に埋め込みます。
これにより、各フォーム、レポート、テーブルなどを実装するために必要な書き込み量を大幅に削減できます。システムはデータ駆動であるように見えますが、ある程度までです。
この時点で、新しい4GLが実装されました。これが正常に実行された場合は、お知らせください。ほとんどの人は大げさに失敗します。私はあなたの業績を祝福する最初の人になります。
基本的に正しいと思います。言語ランタイムはすでに完全に柔軟なデータ駆動型システムです。 1つのデータ（プログラム）を取得し、それを使用して他のデータにどのように作用するかを決定します。 （インクルードパスから適切なインストール管理に至るまで）他のプログラムで再利用するためのコードを格納するマルチユーザースキームも含まれる場合があります。
「スクリプト言語」は、大まかに言えば、このコード入力が人間が読める言語ランタイムです。コンパイラーは、ユーザーとランタイムの間に追加のステップを配置します。 Malbolgeのような「ジョーク」言語 とAPL 人間が判読できる形式である必要はありません。しかし、それは1つのレベルですべて同じことであり、とにかく人間が読めるということは、すべての潜在的なユーザーがそれを読み書きするスキルを持っている、またはそれらを開発することが期待できるという意味ではありません。
正当な理由通常、言語ランタイムを直接エンドユーザーに公開しない理由があります。主なものは、柔軟性を排除することで利便性が向上することです。
SO投稿を入力したい場合は、それを入力したいだけです。代わりに、C++プログラムを記述して出力することはできますが、公開されているWebブラウザーは使用しません。通常のテキストボックスではなくC++プログラムエディターC++を知らない人は、ブラウザーを使用するだけでなく、使用することもできませんでした。
特定のビジネスパラメータを構成する必要がある場合は、必ずしもチューリング完全な仕様言語を使用してそれを実行する必要はありません。私が作成した場合でもこれは、おそらくそれらの "ハードコーディング"と区別できません他のプログラミング言語の同じビジネスパラメータ。あなたはまだあなたが書いていることがあなたがそれが意味したいことを意味するかどうかを考慮する必要があります。変更が正しいことをテストする必要があります。つまり、doesを構成するための特別なサブシステム（「アプリケーション」）を準備したプログラミングスキルを持っている誰かが予期しない、重要なタスクのプログラミングスキルが依然として必要です（ "使用する"）。
したがって、100％データ駆動型のシステムを採用しようとしていて、適切なデータがあれば何でもできる場合は、次の2つの質問に答えてください。
- 私たちはプログラミング言語を発明するビジネスをしているのですか、それとも私たちがすべきなのでしょうか？
- 私たちの新しいプログラミング言語は、私たちが既に持っているものよりも（私たちの目的のために）優れているのでしょうか？それを必要に応じてサポートし、開発するでしょうか？
時々答えはイエスであり、あなたはある種のドメイン固有の言語を書きます。または、Sun/Microsoft/Stroustrup/van Rossum /他の多くの人なら、実際の汎用プログラミング言語です。時々答えはノーであり、あなたは「内部プラットフォーム」効果を持っています-多くの努力と試行錯誤の後、あなたは何かで終わります。運が良ければ、それを書いたプログラミング言語よりもわずかに劣っており、使いやすくはありません。
一部の言語は他の言語よりも使いにくい、または使いにくい場合があります。特にRのような目的に特化している場合、一部のユーザーははるかに使いやすいでしょう。おそらくやらないことは、一般的なアプリケーションのプログラミングを根本的に簡単にすることです。いつでもそれをする可能性のある人々/組織が世界中におそらくあるでしょうが、あなたの上司/会社はそれが彼/あなたを含むかどうかを正直に考えなければなりません。
ゲームでよく使用されるトリックは、Luaバインディングをゲームエンジンに公開することです。これにより、設計者は比較的簡単な言語でプログラミングできますが、パフォーマンスやエンジンやプラットフォームの特定の機能にアクセスする必要がある場合は、「実際の」プログラマーを利用できます。結果として得られるLuaスクリプトは、エンジンに関する限り「データ」です。構成データとは対照的に、「ロジック」と呼ぶものの多くをすべて含める必要はなく、多くの場合、すべてのプロットと環境を定義しますが、ゲームプレイ全体を定義するわけではありません。これは100％データ駆動型ではなく、100％エラーがないわけではありませんが、実用的な妥協策として興味深いものです。
これが目標だった会社で働きました。 SQLのスニペットは、データベーステーブルに格納され、実行時に読み取られ、実行されました。ご想像のとおり、パフォーマンスはひどく、バグも頻繁に発生しました。また、スタックトレースなど、作業を容易にするものがないため、デバッグも不可能でした。
「データ駆動型プログラミング」は、プログラマーとして私たちが何をしているのかを根本的に理解していないことが原因です。アルゴリズムを実行できるデータは、実際には「プログラミング」ですユーザーインターフェイスで。ただし、これは、2つのアイデアを別の方向から組み合わせることができないため、すべてのコードがデータになるという意味ではありません。これがLISPの背後にある前提です。LISPは同型性によって可能になり、マクロシステムによって利用されます。はい、これらの概念は同じように聞こえますが、それらの意味とアプリケーションは実際には非常に異なります。
また、これは編集的なものかもしれませんが、「完全にデータ駆動型」のプログラミングを必要とする私が遭遇した場所は、実際にはプログラマーを重視していません。彼らはコードをコストセンター、アウトソーシング、または無視されるものと考えています。
あなたの上司はあなたにこれを書くことを望んでいることを意味します：
[
{
"statement": "Assignment ",
"variable": "App",
"value": {
"type": "Function",
"arguments": [],
"function-body": [
{}
]
}
},
{
"statement": "Assignment",
"variable": "App.prototype.action",
"value": {
"type": "Function",
"arguments": [
"data"
],
"function-body": [
{
"statement": "Call",
"function-name": "console.log",
"arguments": [
"data"
]
}
]
}
}
]
これを生成するには：
var App = function () {};
App.prototype.action = function ( data ) {
console.log( data );
}
1つ目は[〜＃〜] json [〜＃〜]で、2つ目はJavaScript。
明確化
理論的には、アプリケーションを説明するためにデータを解釈するものが完全にチューリングする必要があり、正味の利益がないように問題を1レベル上にシフトしただけではないと思います。
このような100％データ駆動型アプリケーションは可能ですか？
これは私が始めたところです。私の回答では、元の投稿に同意しようとしています：それは可能ですが、正しいです。[明白な]利点がないため、問題を1レベル上にシフトします。
私は、どのWebブラウザーアプリケーションも100％データ駆動型と見なすことができると、説得力のあるように主張できます。1。
もちろん、それによってWeb上でのアプリケーションの構築が単純になったり簡単になったりするわけではありません。実際には、アプリケーションがはるかに難しくなります。
上司にWebブラウザを再発明していることを伝えます。彼は最終的にJavaScriptを再発明して、かなり複雑なものを構築する必要があります。
1 ええと、プラグイン、JavaScript、そして HTML5 を無視すると、.