NoFlo: 两年的基于流程的编程(NoFlo: two years of flow-based programming)

编程语言 William 324浏览 0评论
NoFlo — the flow-based programming system I started — is now two years old. I
pushed the first commits to GitHub on June 5th 2011 from
Hacker Dojo in Mountain View. To get us started with the story, I’ll let
Wikipedia summarize:

Flow-based programming (FBP) is a programming paradigm that defines applications as networks of "black box" processes, which exchange data across predefined connections by message passing, where the connections are specified externally to the processes. These black box processes can be reconnected endlessly to form different applications without having to be changed internally.

While flow-based programming is still far from mainstream, it has been great to watch to the community grow around NoFlo.

There are several start-ups using it as their base infrastructure, with several of their engineers contributing to the open source effort. I’ve personally used the system for quite a wide range of tasks from web services and document transformations to handling payments and user on-boarding processes.

NoFlo — 我发起的基于流程编程的系统 — 现在两岁了。我是在山景市(Mountain View)
第一次
Hacker Dojo提交到GitHub,那天是2011年6月5日。 在故事开始之前我先列出
维基百科的概述:

Flow-based programming (FBP)是一个编程范式,它把应用程序看成一个“黑盒”网络的流程,它通过预定义的链接传输信息来交换数据,这些链接对流程来说是外部的指定说明。这些黑盒流程可以无须改变内部而不断得重连到不同的应用程序。

虽然基于流程编程依然不是主流,但关于NoFlo的社区正在茁壮的成长,这是很好的事情。

有几个创业型公司将它作为自己的基本的基础设施,他们的工程师也努力的为开源做出了贡献。我也亲自使用了这个系统去做一些非常广泛的任务,从web服务文档转换处理到支付处理和用户加载过程等。

Why I started NoFlo

Two years ago I was undergoing a transition from PHP and Python to the JavaScript world, largely lured by the benefits of a universal runtime and the event-based multi-protocol paradigm Node.js offers.

While new programming languages and environments are easy to get into, this transition provided yet another point where I would have to sit down and port over all the little libraries and utilities I’ve grown to rely on over the years.

I wondered if there could be a better way.

To figure that out, I spent the time I had when traveling between conferences and hackathons of the IKS Project reading various computer science papers on different programming paradigms. Eventually I stumbled upon some mentions of flow-based programming. I dug deeper, and finally read the canonical book on the subject — Paul Morrison’s Flow-based programming, 2nd edition.

为什么我要发起NoFlo

两年前我正在经历从PHP和Python向JavaScript世界的转移,这是源于一个叫Node.js的基于事件的多协议范式的通用运行库提供的好处对我的极大的诱惑。

随着新的编程语言和环境很容易的进入,这次转变也给我一个机会让我必须坐下来并转向所有的那些我依赖多年的不断增长的小函数库和工具。

我想知道是否会有更好的办法。

为了想明白这个问题,我花了我在IKS Project的会议和黑客马拉松之间的时间去阅读各种关于不同的编程范式的计算机科学论文。最终我偶然发现一些提到了基于流程编程。我深入的了解,最后阅读了关于这个话题的规范书 — Paul Morrison的 Flow-based programming, 2nd edition

Having worked with component architectures and Unix pipes before, the idea resonated with me. To think things through, I took the excuse of having some meetings in Portland to drive up there following the beautiful California 1 coastal road. Couple of days alone in a car is a great way to let your mind flow!

The coastal road in Oregon

Implementing your own is usually the best method for learning a new concept, and so when I got back to the Bay Area, I decided to write an FBP system of my own on Node.js.

I also kept a Qaiku thread on the things I discovered, parts of which I later republished on this site.

由于以前曾在组件化设计和Unix管道方面工作过,一个想法浮现在我的脑海。为了把事情想清楚,我借口到Portland参加一些会议,我是沿着美丽的California 1号海滨公路一路开车到那里。单独呆在车里两天是让你的思想流动起来的一个伟大的方式。

The coastal road in Oregon

自己实现一般是学习一个新概念的最好的方式,于是当我回到Bay Area,我决定在Node.js上写一个我自己的FBP system

我也将我发现的这个事情上发布到了Qaiku,其中一部分我过会也会在这个网站上转载。

Beyond OOP

Object-oriented programming and Model-View-Controller have been the dominant programming paradigms since the desktop computing era of the 90s, even while the world has become more connected and multi-device. While these concepts did improve some things, the big promises of programmer productivity and component reuse have mostly been left unrealised.

Software has become one of the most important aspects of business and the society. As an effect, the demand for programmers vastly outstrips the amount of computer science graduates we’re able to produce.

The tools side of things isn’t looking much better, either. While IDEs are admittedly improving all the time, most of the talented programmers have ditched them and moved back to the console-based editors of the 80s like vim and Emacs, many following the Unix as your IDE idea. Clearly the productivity boost given by IDEs doesn’t yet match the overhead of using them.

These areas are where flow-based programming can help.

OOP之上

尽管这个世界已经变得联系更紧密、设备多元化,面向对象编程和MVC依然是上世纪九十年代有了桌面电脑以来的主流编程范式。虽然这些概念曾经推动了一些东西的发展,但程序员的工作效率和组件重用这个最大的承诺却未能实现

软件已经成为商业和社会的一个最重要的方面。一个特点就是程序员的需求已经大大超过了我们能拥有的计算机科学方面的毕业生数量。

工具方面的东西也并没有变好。虽然IDE改善了各方面的时间,但大多数有才华的程序员却抛弃了它们而转向了80年代的控制台编辑器,比如vim、Emacs等,许多都认同Unix作为自己的IDE这个想法。IDE明确提升的生产效率并不能匹配使用它们带来的开销。

基于流程的编程可以帮助这些领域。

The logic is in the graph

When we design software, we usually start by drawing boxes and arrows on a whiteboard. Later on these are then translated to actual software through various text files containing classes, methods, and configuration information.

As the software evolves, people rarely go back to the original drawing and update it, effectively making the source code only place documenting how different pieces of a system fit together.

With FBP, the logic of the software is designed as a graph — much like a flowchart — and stays as a graph.

The boxes of the graph depict various instances of reusable components, and the arrows the wiring connecting their ports together.

逻辑在图表中

当我们设计软件时,我们经常从在白板上画一些方框和箭头开始。然后这些再通过转变成一些包含类、方法和配置信息的文本文件来成为实际的软件。

随着软件的发展,人们很少再回到原来的图纸并更新它,而是更有效地将这些源码成为记录系统的不同部分如何组合在一起的唯一地方。

有了FBP,软件的逻辑就是像图表一样来设计 — 更像一个流程图 — 保留为一张图表。

这个图的框描述了一些可复用组件的各种实例,并使用箭头将它们通过它们的端口连接到一起。

The graph is what FBP systems like NoFlo execute, and it is also something that can be easily drawn on the screen, or even edited visually.

NoFlo graph in DrawFBP

We humans are visual creatures. We are much better at recognizing shapes and visual connections than at finding them from a jumble of text files.

Each node (orprocessin FBP terminology) of a graph is an instance of a component. Just like objects in OOP can receive and react to messages (method calls), NoFlo components react to packets they receive through their input ports, process them, and eventually send something to their output ports.

The graph decides where the output is sent, meaning that the overall behavior of a program can be modified by just rewiring some of these connections. In traditional OOP the connections between various objects are usually hardcoded, or managed by a complicated dependency injection systems.

这个图表就是像NoFlo这样的FBP系统执行的,它也是可以很容易的在屏幕上画出来或很直观的被修改。

NoFlo graph in DrawFBP

我们人类是视觉动物。 我们更擅长识别形状和可视化关系而不是从一大堆的文本文件中找出来这些关系。

图的每一个节点(orprocessin FBP 术语)都是一个组件的一个实例。就像OOP中的对象可以接收并反应消息(方法调用)一样,NoFlo的组件也可以对通过它们的输入端口输入的数据包做出反应并处理,最后发送些东西到它们的输出端口。

图决定这些输出被发送到哪里,这意味着一个程序的整体行为的修改只需通过重新部署这些连接关系。在传统的OOP中不同的对象之间的连接关系通常是硬连接或由一个复杂的依赖注入系统来管理。

Component reuse

Because FBP components are just black boxes performing some well-defined task on incoming packets, they can be connected with each other in multitude of different ways to produce a different behaviour. This gives FBP systems a much better scale of code reuse than traditional OOP or procedural environments.

As an example, my typical NoFlo applications only contain some 5-15% of components written specifically for that project. The rest are all coming from the growing ecosystem of ready-made NoFlo components.

Writing and publishing components is already quite easy, and is becoming even faster and more reliable through tools like the Grunt component scaffolder and noflo-test.

The more components are out there the less time we need to spend writing code, and the more we can focus on designing the software logic itself.

组件重用

由于FBP组件只是在接收到数据包时执行一些定义良好的任务的黑盒,因此它们可以通过连接为多种不同的方式来产生不同的行为。这个特性让FBP系统拥有比传统OOP或面向过程的环境更好的代码重用规模。

例如,我的典型的NoFlo应用程序包含的专门为该项目编写的组件大约占5-15%,其他的都来源于日益增长的生态系统中的现成的NoFlo组件。

编写并发布组件是很容易的,并且通过Grunt component scaffoldernoflo-test这样的工具会变得更快更可靠。

发布出来的组件越多我们编写代码花费的时间就越少,这样我们就有了更多的时间来关注软件逻辑设计本身。

NoFlo on the browser

Apart of better tooling and more components, the other big improvement in NoFlo has been support for running FBP programs on the client. Originally NoFlo was designed for server-side flows, but thanks to the improving client-side Component ecosystem, it became feasible to expose the environment also to web browsers.

This is keeping true with the promises of the universal runtime. With the next release of NoFlo, flow-based programs can be run on pretty much any computing device, whether a Node.js equipped web server, or a smartphone with a browser.

浏览器中的NoFlo

除了更好的工具和更多的组件之外,NoFlo更大的发展就是支持在客户端执行FBP程序。原来的NoFlo是为服务器端流程设计的,但多亏了客户端组件生态系统的发展,在web浏览器中的显示环境也变得可行了。

通用运行库的承诺是不会变的。在NoFlo的下一个发布版本时基于流程的程序将可以运行在无论是Node.js的web服务器还是智能手机的浏览器等等几乎所有的计算设备上。

The ability to run client-side flow-based programs presents new opportunities. There is a tradition of using tools like FilterForge for visual effects, or Quartz Composer for user interaction design. As a matter of fact, Facebook Home was designed using flow-based tools:

…something like Facebook Home is completely beyond the abilities of Photoshop as a design tool. How can we talk about physics-based UIs and panels and bubbles that can be flung across the screen if we’re sitting around looking at static mocks? (Hint: we can’t.) It’s no secret that many of us on the Facebook Design team are avid users of Quartz Composer, a visual prototyping tool that lets you create hi-fidelity demos that look and feel like exactly what you want the end product to be.

Since NoFlo graphs run on any device including the tablets and smartphones that the application being designed is likely to target, it can provide an even better environment for such prototyping. There are lots of opportunities for a new tool here, especially given that Quartz Composer’s future is quite uncertain.

We are already doing some work on visual interaction components for NoFlo. This could be huge for NoFlo and FBP in general!

运行客户端基于流程的程序的能力带来的新的机遇。对于视觉效果有一个像FilterForge的传统工具,或像Quartz Composer的传统工具来做用户接口设计。事实上,Facebook主页就是使用基于流程的工具来设计的:

…像Facebook主页是使用超出Photoshop的设计工具完成的。我们坐看静态模拟时如何能来讨论那些可以出现在屏幕上的基于物理的UI、面板和气泡?(提示:我们不能)这不是什么秘密,我们中的在Facebook设计小组的许多人都是Quartz Composer的狂热用户,这是一个可视化的原型工具,可以让你创建高传真的外观和感觉都与你希望的最终产品一样的样例。

由于NoFlo图可以运行在包括平板电脑和智能手机等应用程序设计的可能运行的任何设备上,它可以提供给这样的原型提供很好的环境。这是一个新工具出现的很好的机会,特别是考虑到Quartz Composer的未来是很不确定的

我们已经关于NoFlo的可视化交互组件做了很多的工作,总之对NoFlo和FBP是非常巨大的。

UI is the missing part

What we have with NoFlo is already a quite solid programming environment:

However, the missing part is a tool that would allow viewing and editing NoFlo graphs visually. Sure, DrawFBP is there, and can be used with NoFlo. But something fitting modern touchscreen interactions and more connected to the live graphs would be better.

I did some prototypes on this with noflo-ui, and wrote down bunch of thoughts on how the graphs would be best shown. There has also been some collaboration with Forrest Oliphant of Meemoo fame.

Last week I sat down with Leigh Taylor, the original designer behind the Medium blogging platform, to go through the various ideas and concepts we had. Based on this we’re starting to have a quite solid design to continue working with.

There will be more on that in the near future, but here is a sneak preview:

Leigh's NoFlo UI concept

UI是缺失的哪部分

与NoFlo相伴的是我们拥有一个非常稳固的编程环境:

然而,缺少的部分是可视化地查看和修改NoFlo图形的工具。确实,DrawFBP可以做到,而且DrawFBP可以使用NoFlo。不过满足现代触摸屏交互和更多连接活生生的图形的东西就更好。
我用noflo-ui做了一些有关这方面的原型,并且写下许多如何最佳展示图形的想法。还做了与Forrest Oliphant的Meemoo框架合作的一些事。
上周,我与Medium博客平台的最初设计者Leigh Taylor坐下来谈了我的各种设想和理念。正是因为有了这些,我们才开始有了继续下一步工作的非常稳固的设计。
在近期将有更多有关这方面的事情,不过先泄露一点预览一下:

Leigh's NoFlo UI concept


via:oschina

转载请注明:AspxHtml学习分享网 » NoFlo: 两年的基于流程的编程(NoFlo: two years of flow-based programming)

发表我的评论
取消评论

表情

Hi,您需要填写昵称和邮箱!

  • 昵称 (必填)
  • 邮箱 (必填)
  • 网址