「スプレッドシートプログラミング」の用途はありますか？[閉まっている]

少し前に、プログラミングロジックを指定する方法としてスプレッドシート（​​マクロコードではなくセルと数式を使用する）を使用するという概念に出会いました。アイデアは次のとおりです。

• 明確に定義された計算フローでスプレッドシートを作成します（プロシージャまたはオブジェクト指向のプログラミングスタイルではなく、スプレッドシートの「データフロー」パラダイムにより適している場合があります）

• 入力セルを定義する

• 出力セルを定義する

• 全体をスタンドアロンの実行可能クラス（または関数、プロシージャなど）にコンパイルする

• より広範なソフトウェアプロジェクト内の通常のコードで使用する

• スプレッドシートをソースコードとして使用し、長期にわたって維持する

アイデアは、モデルに実際に適合する問題に対してこの手法を使用することであり、これにより、自然に文書化された、保守が容易なコードが作成されるということです。このテクニックの使用経験があるかどうか、また何のために興味があるかを知りたいです。私の頭に浮かんだアプリケーションの例は保険料金計算機で、通常Excelシートでアクチュアリーによって作成、作成、検証され、保守が難しいプログラミングロジックで後でコーディングされます（苦痛なプロセスです）。

「スプレッドシートを作成し、コードにコンパイルする」というスタイルではありませんが、CellsのCLOSへのデータフロー拡張機能は、同様のモデルを使用します。データフローと変換を表す式は「ソースマテリアル」/「表現」ですオブジェクト/クラス設計の記録」。あなたが求めていたものを構築するための代替方法と考えてください。

楽しみのために：スプレッドシートマクロ

手続き型またはオブジェクト指向のプログラミングスタイルではなく、スプレッドシートの「データフロー」パラダイムにより適している場合があります

正直なところ、これが当てはまる現実の計算についてはほとんど考えられません。「データフロー」プログラミングは、多くの最新のプログラミング言語（.NETのLINQ、またはPerlとPythonのリスト処理演算子を見てください）で簡単に実行できます。メンテナンスが難しいセル参照を含む「スプレッドシートの数式」

一方、私と同僚は、Excelを入力データの入力/入力マスクの作成を非常に迅速に行うための使いやすいツールとして使用した、スプレッドシートベース（正確にはMS-Excel）のアプリケーションを多数作成しました。フォーマットされた出力、またはその両方を作成します。これらのすべての場合、そのデータの計算または処理は、Excelの式ではなく（または部分的にのみ）Excelの式ではなく、プログラムコードによって行われました（Excelの式は十分に強力または完全に間違ったツールではなかったため） Excelの数式で可能なこととできないことに関する多くの知識）。

この記事を読んで以来、私はコンセプトについて何度も考えていました。私は間違いなくその用途があると思います。

そのようなことを最適化することに関する1つのこと、スプレッドシートはメモリ空間に非常に似ています。また、表示および印刷スペースに非常に似ています（x、yなど）。そこにも多くの利点があります。

あなたが保守性に気付いたとき、それは私にとって多くのアイデアを開きました。本当にコンパイルできる言語が何なのかわかりませんし、言語機能やライブラリなどもかなり苦痛かもしれません。それでも、どこかに未来があるかもしれません。

スプレッドシート、成績表、会計「ソフトウェア」用のVBスクリプトのみを実際に作成しました。C ++アプリのExcelファイルインターフェイス以外のスプレッドシートベースから実行可能アプリを作成したことはありません。

はい、ただし、「スプレッドシートプログラミング」ではなく「スプレッドシートテスト」と考えています。たとえば、最近、私はプロジェクトの機能に取り組んでおり、多数のデータベースレコードで計算を実行する必要がありました。計算は比較的単純でありながら重要であったため、特別なテストの注意が必要でした。さらに、私たちが使用していた式は、私たちの状況に適用するために少量の適応が必要でした。

手作業でいくつかの計算を実行してユニットテストを作成し、作業中のテスターは、エンドツーエンドテストで使用するために説明したようなスプレッドシートを作成しました。ソース式の適応により、比較する独立したテストデータがなかったため、スプレッドシートは、コードが正しいという自信を与える一種の「二重記入簿記」スタイルチェックを提供しました。

そのため、この手法は、関連する計算をスプレッドシートに簡単に実装できるが、コードに実装する必要がある場合のテストデータのソースとして非常に有用であると考えています。ただし、このようなスプレッドシートはそれ自体「プログラミングロジックを指定する」ために使用されるべきではなく、単に必要な最終結果に使用されるべきです。

スプレッドシートの「プログラミング」は、データフロープログラミングの一種です。

言語的な問題があります。「プログラミング」と呼ぶべきではありません。プログラミングと呼ぶよりもはるかに少ないからです。しかし、プログラムにデータを入力する以上のことです。

データフロープログラミングは、アプリケーションが独立したモジュールのネットワークであり、互いにメッセージ（データ）を送信するアーキテクチャおよび分野です。このモデルはすべての問題に適用できるわけではありません。処理ネットワークを通過して出力データ/ストリームを生成するソースデータまたはストリーム（またはそれ以上）がある問題にのみ適用されます。以下のリストを参照してください。

データフロープログラミングにはいくつかの種類があります。いくつか見てみましょう。

• スプレッドシート：入力数値は数式で処理され、結果の数値とグラフで処理されます。特別な特性：実行時間は「ワンショット」です。入力値（コンポーネント）が変更されると、処理グラフの適切な部分が再実行され、出力が生成されます。
• Unixパイプ：シェルはいくつかのプログラムを起動し、stdout-> stdinをリンクします。特別な特性：パイプスタイルのリンクのみが許可され、グラフは単一のキューです。
• 同期実行：指定された周波数でフレームまたはサンプルの処理をトリガーするクロックがあります。すべてのコンポーネントは、クロックサイクルごとに実行されます。ビデオおよびオーディオ処理システムの例では、指定されたフレーム/サンプルレートで動作します。
• 非同期実行：外部イベントが発生するまで、グラフはアイドル状態です。次に、イベントを処理し、何らかの出力を生成し（または生成しない）、アイドル状態になります。

質問に戻ります。はい、データフローアプリケーションをスタンドアロンアプリとして公開することをお勧めします。私はすでにそれを作った。二回。

私と私の友人は、ホームオートメーション用のプロトタイプDFシステムを作成しました。グラフエディターがないため、ユーザーがアプリを編集することはできません。一部のパラメーターは構成ファイルに格納されますが、他には何も格納されません。C ++コード（コンポーネント作成とメッセージ定義のリスト）に「コンパイル」され、ネイティブ実行可能ファイルにコンパイルされるDFスクリプト言語があります。モジュールはC ++クラスです（システムに関する情報を取得するための他のクラス：Message、Dispathcer、Component（abstract）、Port（abstract）、ConsumerPort、ProducerPort）。

また、DFシステムの利点に驚かされました。2分以内にシリアルスニファーアプリを作成したか、オンサイトでランプを1つずつ点滅させるテストプログラムを作成しました（ドキュメントはありませんでした）ハードウェアIDで）。楽しみのためだけにMIDIとジョイパッドのコンポーネントを作成しました。また、ライトオルガンも作成しました（http://homeaut.com/under_construction/を参照）。

スプレッドシートの場合、難易度は1つしかありません。すべての数値と数式（場合によってはすべてのセル）がコンポーネントであるため、グラフは最終的なものではありません。単純なsum（）アプリに行を追加すると、データフローグラフが変更されます。そのため、実行時にグラフを「再プログラミング」するか、「メタプログラミング」と呼ぶ必要があります。Excelでは、マクロが仕事をしますが、データフローの純度を失います。

悪くないが完璧ではないソリューションがあります。PHPバックエンドを備えたAJAXアプリであるスプレッドシートを作成しました。縦軸は時間（日）、線はコンポーネントです。入力（行はユーザーが編集可能）、垂直平均、水平平均/合計、およびドメイン固有の統計計算などのコンポーネントがあります。問題は1つだけです。これは「1次元」です。sumとavgなどを必要とする限り、新しい行を追加し、コンポーネントを作成して、それを計算できます。ただし、強い制約があります。列は常に日です（週と月を「表示」し、毎日のデータを合計/平均として表示しますが、それでも1次元です）。私はそれを示すことができません、それは協調的であり、7/24を実行するためにPHPバックエンドタスクを必要とします、それは私のホストプロバイダーによってサポートされていません。

したがって、私のモデル（「水平方向の日数」と最もよく説明できる）は、他の種類の問題を処理できません。

私は、この問題を解決する方法、つまりタブを考えています。

Excelで行き詰まって、別のテーブルを作成する必要がある場合は、同じタブの別の領域を使用するか、別のタブを開くことができます。また、タブ間の参照は不快で、私は最初の方法を好みます。重複しないウィンドウのように、タブは同じ画面に表示されるべきだと思います。

すべてのテーブルには、垂直、水平、または固定の成長軸が必要です。垂直に成長するテーブルには行コンポーネントがあり（私の日ベースのスプレッドシートとして）、すべての列に「同じ」式があり、水平コンポーネントに列コンポーネントがあり、固定サイズのテーブルはスプレッドシートとまったく同じです。

したがって、ユーザーが新しい行/列を追加すると、新しい行/列は同じ式になります。

また、スプレッドシートでは、1000行ある場合、非常に同じ式を1000回コピーする必要があることを嫌います。これはバグの原因（式の古いバージョンをいくつかの行に保持）、メモリの浪費（同じ式1000xを保存）です。

たぶん私は間違っており、このモデルにはコンセプトのバグがありますが、それが良い考えを誘発するものであったことを願っています。

私の考えは、スプレッドシートを使用して計算のロジックを定義し、これを行いながら、プログラミング言語に適した方法でスプレッドシートをセットアップすることです。つまり、cellXY座標の代わりに名前の範囲/参照を使用し、数式を小さな断片に分解します。