基于stream程的编程
过去几天我一直在阅读基于stream程的编程 。 有一个wiki提供了更多的细节。 维基百科也有很好的概述 。 我的第一个想法是“乐高乐园假装节目的另一个支持者” – 这个概念回到了80年代末。 但是，当我读了更多，我必须承认我已经变得好奇了。
- 你有没有使用FBP的一个真正的项目？
- 你对FBP有什么看法？
- FBP有未来吗？
从某种意义上说，自从程序语言出现以来，我们这个行业一直在追求的是再利用的圣杯。
有趣的讨论！ 昨天我发现，部分混乱可能是由于许多不同的符号使用有向弧，而是用它们来表示不同的东西。 在FBP中，这些线表示有界的缓冲区，数据包的旅行stream通过这些缓冲区。 由于组件通常是长时间运行的stream程，stream可能包含大量的数据包，FBP应用程序可以运行很长一段时间 – 甚至可能是“永久”（参见2007年的一篇名为Eon的项目文章，主要由麻省大学阿姆赫斯特分校）。 由于发送到有界的缓冲区在缓冲区（暂时）满（或暂时为空）时暂停，因此可以使用有限的资源处理不确定数量的数据。
相比之下，Grafcet中的E来自Etapes，意思是“步骤”，这是一个非常不同的概念。 在这种types的模型中（这里有一些这样的模型），步骤之间的数据stream或者限于一次可以保存在高速内存中，或者必须保存在磁盘上。 FBP还支持networking中的循环，这在基于步骤的系统中很难实现，例如http://www.jpaulmorrison.com/cgi-bin/wiki.pl?BrokerageApplication – 注意，该应用程序同时使用了MQSeries和CORBA以一种自然的方式。 此外，FBP本质上是并行的，所以它适用于网格networking，多核机器以及现代计算的一些方向。 最后一点评论：在文献中我发现了许多相关的项目，但很less有FBP的所有特征。 这些年来积累的清单（其中一些清单比Grafcet更接近）可以在http://www.jpaulmorrison.com/cgi-bin/wiki.pl?FlowLikeProjects中find 。
你有没有用FBP来做一个真正的项目？
我们为自动化项目（调度程序，组件接口，一组组件，DF语言，DF编译器，UI）devise并实现了一个DF服务器。 它是用C ++编写的，可以在几个类Unix系统（Linux x86，MIPS，avr32等，Mac OSX）上运行。 它缺乏几个function，例如复杂的stream程控制，复杂的线程控制（只有一个不太先进的组件），所以它只是一个原型，即使它工作。 我们现在正在开发一个全function的服务器。 在实施和使用原型的过程中我们学到了很多东西。
另外，我们有一天会做一个视觉编辑器。
2.你对FBP有什么看法？
2.1。 首先，数据stream编程是 最终的乐趣
当我遇到数据stream编程时，我感觉就像20年前，当我遇到编程第一。 另外，DF编程与程序/ OOP编程不同，它只是一种编程。 有很多事情要发现，即使是简单的！ 很有趣的是，作为一名经验丰富的程序员，遇到了一个非常基本的DF问题，但之前你完全不知道。 所以，如果你跳入DF编程，你会觉得自己就像一个刚刚遇到“周期”或“条件”的新手程序员。
2.2。 它只能用于特定的体系结构
这只是一个锤子，用来钉钉子。 DF不适合UI，Web服务器等。
2.3。 数据stream体系结构对于某些问题是最佳的
数据stream框架可以创造奇迹。 它可以将程序并行化，这些程序本来不是为了平等化而devise的。 组件是单线程的，但是当它们组织成DF图时，它们变成了multithreading。
例如：你知道，这是一个DF系统吗？ 试试make -j （参见man，用什么-j）。 如果您有多核机器，请使用和不使用-j编译项目，并比较时间。
2.4。 问题的最佳分割
如果你正在编写一个程序，你通常会将问题分解成更小的子问题。 对于众所周知的子问题，通常会出现一些分歧点，您不需要实现它们，只需使用现有的解决scheme，如用于数据库的SQL或用于graphics/animation的OpenGL等。
DF架构将您的问题分解成一个非常有趣的方式：
- 数据stream框架，它提供了架构（只使用现有的架构）
- 组件：程序员创build组件; 组件简单，分离的单元 – 制造组件很容易;
- configuration：aka数据stream编程：configuration器使用程序员提供的组件将数据stream图（程序）放在一起。
如果你的组件集合devise的很好，configuration器可以build立这样的系统，这是程序员从未梦寐以求的。 configuration器可以实现新function，而不会打扰程序员。 客户很高兴，因为他们有个性化的解决scheme。 软件制造商也很高兴，因为他/她不需要维护几个客户特定的软件分支，只是客户特定的configuration。
2.5。 速度
如果系统build立在本地组件上，则DF程序速度很快。 与简单的OOP程序相比，唯一的时间损失是组件之间的消息分配，这也是最小的。
3. FBP有未来吗？
是的，当然。
主要原因是它可以解决大量的多处理问题，而不需要引入全新的奇怪的软件架构，怪异的语言。 数据stream编程很容易，我的意思是：组件编程和数据streamconfiguration构build。 （甚至数据stream框架写作也不是火箭科学。）
而且，这非常经济。 如果你有一套好的组件，你只需要把乐高积木放在一起。 DF程序易于维护。 DFconfigurationbuild设不需要经验丰富的程序员，只需要系统集成商。
我会很高兴，如果本地系统传播，打开门自定义组件创build。 还应该有一个标准的DF语言，这意味着它可以与平台无关的可视化编辑器和几个DF服务器一起使用。
我不同意FBP只是一种实现FSM的方式：我认为FSM是整洁的，我相信它们在构build应用程序方面有一定的作用，但FBP的核心概念是多个组件进程asynchronous运行，通过跨越现在称为有界缓冲区的数据stream进行通信。 是的，绝对有限状态机是构build组件stream程的一种方式，事实上，我在FBP专门讨论这个想法的书中有一整章，以及相关的PDA（ 1 ） – http://www.jpaulmorrison.com/ fbp / compil.htm – 但在我看来，实施一个不平凡的FBPnetworking的FSM将是非常复杂的。 如图所示的示例 
是在大型机上运行的单个批处理作业的大约1/3。 每一个块都与所有其他块asynchronous运行。 顺便说一下，我会很感兴趣的听到第一篇文章中更多的答案！
1 ： http : //en.wikipedia.org/wiki/Pushdown_automaton下推自动机
每当我听到术语基于stream程的编程时，我都会想起LabView。 即调度的组件进程主要是通过改变其input数据来驱动的。 这是真正的乐高编程，这意味着labview平台被用于最新的头脑风暴产品。 然而我不同意这使得它不太有用的编程模型。
对于通常涉及数据收集，控制和自动化的工业系统来说，它非常合适。 如果没有数据转换成数据，什么是控制系统？ 也就是说，如果你可以这样做的话，你的控制scheme中的哪一个组成部分，你不会更愿意在一个更大的图像中代表一个黑匣子。 要使用其他方法来实现这种架构清晰度，您可能需要绘制一个数据域类图，然后问题域运行时间类关系，然后再使用一个用例图，并在它们之间来回翻转。 使用stream动驱动的系统，您可以将许多这些信息精确地合并到一起，从而在构build和定义组件时可以实际可视地devise系统。
在用labview编写的应用程序时，我从来不需要问的一个问题是“什么样的代码设置了这个值？”，因为它是固有的，并且容易从数据中追溯到后面，而且像多个未预期的作者的错误是不可能的创造错误。
如果只是以更典型的程序方式编写的代码才是真的！
1）我为一个exception检测项目构build了一个小的FBP框架，事实certificate这是一个好主意。
你也可以看看一些KNIMEvideo ，这些video给出了一个很好的概念，当一个伟大的团队把框架放在一起时，基于stream的框架是什么感觉。 无可否认，它是基于批处理的，并不是为了连续操作而创build的。
到目前为止，基于stream程编程的最好例子是UNIXpipe道 ，这是最古老，最容易被忽视的FBP框架之一。 我不认为我必须详细说明尼克斯pipe的力量…
2）FBP是解决大量问题的强大工具。 内在的并行性是一个很大的优势，任何FBP框架都可以通过使用适配器模块来完全networking化。 智能框架也具有荒谬的容错能力，并且能够在必要时dynamic地重新加载崩溃的模块。 简单的概念也允许与参与项目的每个人进行更清晰的沟通，并且更简洁的代码。
3）绝对！ pipe道在这里留下来，是UNIX的最强大的function之一。 与静态程序相比，FBP框架中固有的function有很多，并且变化微不足道，以至于某些框架可以在没有特殊措施的情况下进行重新configuration。
FBP FTW！ 😉
在汽车开发中，它们具有语言不可知的消息协议，该协议是MOST规范（面向媒体的系统传输）的一部分，其被devise为通过networking或者在同一设备内在组件之间进行通信。 系统通常具有真实的和可视化的消息总线 – 因此，您实际上有一种基于stream程的编程forms。
那是几年前我为我做的灯泡，把我带到了这里。 这是一个非常棒的工作方式，比传统编程更有趣。 消息目录形成中心规范和参考点。 它对于开发人员和pipe理人员都很有效。 即pipe理能够浏览消息目录而不是查看源代码。
通过集成日志logging还可以引用目录来产生可理解的分析结果，从而获得非常高的效率。 我有这样的开发商业产品的真实世界的经验。 我有兴趣进一步研究，特别是在工具和IDE方面。 不幸的是，我认为汽车行业的很多人都忽略了这个问题的重要性，而且还没有build立起来。 他们现在被其他时尚所分散，并没有意识到， 大部分发展都比实物巴士要多得多。
我已经在Java Web应用程序中广泛使用了Spring Web Flow来模拟（通常）应用程序进程，这些应用程序进程往往是复杂的向导式事务，并且有许多条件逻辑要显示哪些页面。 它令人难以置信的强大。 新产品增加了，我设法在一两个小时内将现有的作品重新编成一个全新的应用程序（添加了一些新的视图/状态）。
我也研究过使用OS Workflow来模拟业务stream程，但是由于各种原因，这个项目变成了jar头。
在微软的世界里，你有Windows Workflow Foundation （“WWF”），它正变得越来越stream行，特别是与Sharepoint一起使用。
FBP只是一种实现有限状态机的手段 。 这不是什么新鲜事。
我意识到这不是完全一样的东西，但是这个模型已经在PLC编程中使用了多年。 ISO把它称为顺序stream程图，但是很多人在stream行的实现之后称之为Grafcet。 它提供并行处理并定义状态之间的转换。
现在商业智能领域正在使用它来混搭和处理数据。 ETL，查询，join和生成报告等数据处理步骤可由最终用户完成。 我是开放系统上的开发人员 – ComposableAnalytics.com在CA中，可以通过浏览器共享和执行基于stream的应用程序。
这是MQ系列，MSMQ和JMS的用途。
这是Web服务和企业服务总线实施的基石。
像TIBCO和Sun的JCAPS这样的产品基本上是基于stream而不使用这个特定的时髦词。
应用程序的大部分工作都是通过处理networking传递消息的小模块完成的。
