电子表格“编程”是一种数据流编程。
我们对此有语言上的问题，我们不应该将其称为“编程”，因为它远不如我们所称的编程，但绝对比将数据输入程序要多。
数据流编程是一种体系结构和学科，其中应用程序是独立模块的网络，它们相互发送消息（数据）。该模型不适用于所有问题，仅适用于存在源数据或流（或更多）并经过处理网络并产生输出数据/流的问题。请参阅下面的列表。
数据流编程有几种类型，让我们来看一些：
- 电子表格：输入数字由公式处理，然后是结果数字和图形。特殊特征：执行时间是“一次性”，当输入值（组件）改变时，处理图的适当部分将重新运行并产生输出。
- Unix管道：shell启动几个程序，并链接stdout-> stdin。特殊特征：仅允许使用管道样式的链接，该图为单个队列。
- 同步执行：有一个时钟，它以指定的频率触发帧或样本的处理。每个组件每个时钟周期运行一次。以视频和音频处理系统为例，它们以指定的帧/采样率工作。
- 异步执行：图形处于空闲状态，直到发生外部事件。然后，它处理事件，生成（或不生成）某些输出，并进入空闲状态。
回到您的问题：我认为是的，将数据流应用程序发布为独立应用程序是个好主意。我已经做到了。两次。
我和我的一个朋友创建了用于家庭自动化的DF系统原型。我们没有图形编辑器，因此该应用程序无法由用户编辑，一些参数存储在配置文件中，但没有其他内容。我们有一种DF脚本语言，可以“编译”为C ++代码（组件创建和消息定义的列表），然后将其编译为本机可执行文件。这些模块是C ++类（其他类只是为了获取有关我们系统的信息：Message，Dispathcer，Component（抽象），Port（抽象），ConsumerPort，ProducerPort）。
另外，我们对DF系统提供的优势感到惊讶：我们在2分钟内制作了串行嗅探器应用程序，或者我们在现场制作了一个测试程序，该程序可以使指示灯一一闪烁（没有文档在硬件ID上）。我们创建了MIDI和Joypad组件只是为了好玩，我还用它制作了一个轻便的风琴（请参阅http://homeaut.com/under_construction/）。
对于电子表格，我只能看到一个困难：由于每个数字和公式（可能是每个单元格）都是一个组件，因此您的图形不是最终的。当您在简单的sum（）应用中添加一行时，这意味着数据流图已更改。因此，您必须在运行时“重新编程”图形，否则我们应该将其称为“元编程”。在Excel中，宏可以完成这项工作，但是随后我们失去了数据流的纯度。
我有一个不太坏但不是完美的解决方案。我制作了一个电子表格，一个带有PHP后端的AJAX应用。纵轴是时间（天），线是分量。包括输入（行可以由用户编辑），垂直平均，水平平均/总和以及某些特定于域的统计计算之类的组件。它只有一个问题：这是“一维的”。只要我想要sum和avg之类的东西，我就可以添加新行，并创建用于计算内容的组件。但是有一个很强的约束：列始终是天（我已经做了周和月的“视图”，将每日数据显示为sum / avg，但仍然是一维的）。我无法展示它，它是协作的，需要PHP后端任务才能运行7/24，但我的主机提供商不支持它。
因此，我的模型（最好用“水平的日子”来形容）无法处理其他类型的问题。
我有个主意，如何解决这个问题：tabs。
当您陷入Excel并不得不创建另一个表时，可以在同一选项卡上使用不同的区域，或打开另一个选项卡。另外，在选项卡之间进行引用也不舒服，我更喜欢第一种方法。我认为，选项卡应该显示在同一屏幕上，例如不重叠的窗口。
每个桌子都应有其增长轴：垂直，水平或固定。垂直生长表具有线成分（如我的日式电子表格），其中所有列均具有“相同”公式，水平成分具有列成分，固定大小的表格与任何电子表格一样。
因此，当用户添加新行/列时，新行/列将具有相同的公式。
另外，在电子表格中，我讨厌这样的事情：如果我有1000行，我需要将相同的公式复制1000次。它是错误的来源（在某些行中保留公式的旧版本），浪费内存（将相同的公式存储1000x）。
也许我是错的，并且该模型中存在概念错误，但是我希望它是一个很好的发人深省的方法。