o**2 发帖数: 168 1
FMP 是 Fast Messenger Programming 的缩写,我去年在 Java 版介绍过一次:http://www.mitbbs.com/article_t0/Java/31128149.html
现在 FMP 更成熟了,方向也更明确了,我计划要多在 Programming 版发言,希望得到
大家的指点。凡我发的帖子,一律以 FMP 开头。
最近重新写了一下 FMP 的机制,在这里: fastmessenger.com/model-api/ d********g 发帖数: 10550 2
不懂帮顶
建议去hacker news吼一嗓子让高手给把把脉
【在 o**2 的大作中提到】: FMP 是 Fast Messenger Programming 的缩写,我去年在 Java 版介绍过一次:http://www.mitbbs.com/article_t0/Java/31128149.html : 现在 FMP 更成熟了,方向也更明确了,我计划要多在 Programming 版发言,希望得到 : 大家的指点。凡我发的帖子,一律以 FMP 开头。 : 最近重新写了一下 FMP 的机制,在这里: fastmessenger.com/model-api/ n***e 发帖数: 723 3
这个,我不大明白,但是是不是和qt里面的signals有点像?
【在 o**2 的大作中提到】: FMP 是 Fast Messenger Programming 的缩写,我去年在 Java 版介绍过一次:http://www.mitbbs.com/article_t0/Java/31128149.html : 现在 FMP 更成熟了,方向也更明确了,我计划要多在 Programming 版发言,希望得到 : 大家的指点。凡我发的帖子,一律以 FMP 开头。 : 最近重新写了一下 FMP 的机制,在这里: fastmessenger.com/model-api/ c****e 发帖数: 1453 4
贴个完整程序吧。看了一下,感觉
(1)verbose,自己要写这么多send/receive message?
(2) 丢了类型检查?都通过字符串来传.
如果只是考虑async, threading简单,还是python, c#那样的coroutine更好用。而且
你这个对于Akka有什么优势吗? o**2 发帖数: 168 5
会用OO编程的应该就会用FM编程,因为FM可以被当作utilities来用,门坎很低。你只
需要在你需要的地方加一点点FM就可以了。
比如说你有一段程序如下,其中的两个worker objects做的都是耗时的工作。因为是顺
序执行的,程序要花25秒才能到300行。
100 Object result1 = worker1.do10seconds();
200 Object result2 = worker2.do15seconds();
300 makeUseOf(result1, result2);
不管你的整个程序或系统有多大,你可以只在这三行程序上使用FM编程。
// 必要的设置
50 Messenger messenger = new Messenger();
60 messenger.registerReceiver(worker1, "worker1", "do10seconds");
70 messenger.registerReceiver(worker2, "worker2", "do15seconds");
100 IDeferredReturn result1 = messenger.callFunction("worker1:do10seconds");
200 IDeferredReturn result2 = messenger.callFunction("worker2:do15seconds");
300 makeUseOf(result1.get(), result2.get());
现在新的100和200行会立即返回,worker1和worker2会在messenger的管理下并发执行
。result1 & 2是延后了的,result1.get()是block的,会等worker1真正完成了,
result1.get()才能返回。也就是说,程序只要花15秒就能到300行了。
而且主程序愿意的话,可以在200到300行之间干点别的事。 o**2 发帖数: 168 6
更正一下: 程序能立即到300行,但result1.get()要10秒才能返回, result2.get()要
等15秒。因为是并发的,所以一共要15秒,makeUseOf()就能有两个值ready了。 l*********s 发帖数: 5409 7
but thread in java is fairly trivial to write and it is the standard, there
is not much to gain by using fmp.
【在 o**2 的大作中提到】: 会用OO编程的应该就会用FM编程,因为FM可以被当作utilities来用,门坎很低。你只 : 需要在你需要的地方加一点点FM就可以了。 : 比如说你有一段程序如下,其中的两个worker objects做的都是耗时的工作。因为是顺 : 序执行的,程序要花25秒才能到300行。 : 100 Object result1 = worker1.do10seconds(); : 200 Object result2 = worker2.do15seconds(); : 300 makeUseOf(result1, result2); : 不管你的整个程序或系统有多大,你可以只在这三行程序上使用FM编程。 : // 必要的设置 : 50 Messenger messenger = new Messenger(); o**2 发帖数: 168 8
贴程序是个好建议,多谢。
1) 有初始设置,但使用不会觉得verbose
2) 对,没有静态类型检查;和字符串无关
完整的比较现在还没有做,突出的有几点:
a) FMP是基于OOP的,同时支持imperative和event-driven programming
b) 除了直接指定receiving active object,还支持动态的routing addressing
c) 可以在其他OO甚至非OO语言上实现,用法一致 (现有Java,C#,和JavaScript版)
d) 支持两种thread models:Java和C#的shared-memory by threads;JavaScript的
dedicated-momery per thread
e) 支持progamming in the large:messenger除了是container外,还是building
block
【在 c****e 的大作中提到】: 贴个完整程序吧。看了一下,感觉 : (1)verbose,自己要写这么多send/receive message? : (2) 丢了类型检查?都通过字符串来传. : 如果只是考虑async, threading简单,还是python, c#那样的coroutine更好用。而且 : 你这个对于Akka有什么优势吗? g*****g 发帖数: 34805 9
Future f1 = worker1.do10seconds();
Future 22 = worker2.do15seconds();
Object result1 = f1.get();
Object result2 = f2.get();
makeUseOf(result1, result2);
This is Java built-in. And there's no 50-60-70 registration you had there.
I don't see your example simpler.
【在 o**2 的大作中提到】: 会用OO编程的应该就会用FM编程,因为FM可以被当作utilities来用,门坎很低。你只 : 需要在你需要的地方加一点点FM就可以了。 : 比如说你有一段程序如下,其中的两个worker objects做的都是耗时的工作。因为是顺 : 序执行的,程序要花25秒才能到300行。 : 100 Object result1 = worker1.do10seconds(); : 200 Object result2 = worker2.do15seconds(); : 300 makeUseOf(result1, result2); : 不管你的整个程序或系统有多大,你可以只在这三行程序上使用FM编程。 : // 必要的设置 : 50 Messenger messenger = new Messenger(); o**2 发帖数: 168 10
首先,FMP和Java built-in的ExecutorService/Futre机制不是一个级别的东西。FMP在
这里只是展示它对imperative programming的支持。
其次,如果我们讨论的context仅仅限于这个例子的话,你的代码也缺了很多东西。要
写足了的话,会超过三行。
1)你要有一个ExecutorService,这相当与FMP的第50行;
2) worker1 & 2 必须是Callable或Runnable,改写的话,就超过了60/70这两行;
3) 你必须要有worker1和worker2的class源码,它们可能是同一个或两个不同classes;
4) 一个class里Callable或Runnable只能各implements一次;
5) messenger给它管理下的receivers(e.g. worker1&2)提供单线程环境。(这个有
点超出了刚才设定的context)
【在 g*****g 的大作中提到】: Future f1 = worker1.do10seconds(); : Future 22 = worker2.do15seconds(); : Object result1 = f1.get(); : Object result2 = f2.get(); : makeUseOf(result1, result2); : This is Java built-in. And there's no 50-60-70 registration you had there. : I don't see your example simpler.
s***o 发帖数: 2191 11
看上去跟C#里的Task类似。 不过如果 do10seconds(), do15seconds()是regular
methods, method body里面没有跟asyn相关的特殊处理的话,那就有意思了
【在 o**2 的大作中提到】: 会用OO编程的应该就会用FM编程,因为FM可以被当作utilities来用,门坎很低。你只 : 需要在你需要的地方加一点点FM就可以了。 : 比如说你有一段程序如下,其中的两个worker objects做的都是耗时的工作。因为是顺 : 序执行的,程序要花25秒才能到300行。 : 100 Object result1 = worker1.do10seconds(); : 200 Object result2 = worker2.do15seconds(); : 300 makeUseOf(result1, result2); : 不管你的整个程序或系统有多大,你可以只在这三行程序上使用FM编程。 : // 必要的设置 : 50 Messenger messenger = new Messenger(); o**2 发帖数: 168 12
messenger接受三种objects作为receiver:
1)POJO/POCO,来自没有任何metadata的class
2)带有IReceiver marker interface
3)带有ICallee marker interface
对第一种,也就是这里例子里的worker1&2,messenger直接用reflection来动态确定一
个method(根据当时arguments的数量和类型),并执行。
【在 s***o 的大作中提到】: 看上去跟C#里的Task类似。 不过如果 do10seconds(), do15seconds()是regular : methods, method body里面没有跟asyn相关的特殊处理的话,那就有意思了 t****a 发帖数: 1212 13
很有趣!看起来像是一个自己可以figure out dependency并且并行执行job的workflow
engine。
可能现有的一些FP语言里已经有类似的package了吧?上次曾在github上看到clojure的
一个workflow包。
楼主能说说这个比workflow engine好在哪些地方吗?
【在 o**2 的大作中提到】: 会用OO编程的应该就会用FM编程,因为FM可以被当作utilities来用,门坎很低。你只 : 需要在你需要的地方加一点点FM就可以了。 : 比如说你有一段程序如下,其中的两个worker objects做的都是耗时的工作。因为是顺 : 序执行的,程序要花25秒才能到300行。 : 100 Object result1 = worker1.do10seconds(); : 200 Object result2 = worker2.do15seconds(); : 300 makeUseOf(result1, result2); : 不管你的整个程序或系统有多大,你可以只在这三行程序上使用FM编程。 : // 必要的设置 : 50 Messenger messenger = new Messenger(); c****e 发帖数: 1453 14
你这个get和java的future是一样的,都是block的?C# await有个很大的benefit就是
continuation.Task没有执行完也马上返回:
如果makeUseOf(result1.get(), result2.get())是个很大的函数:
result1要很久才用到,get()如果一block, 要等25秒才能进makeUseOf?
classes;
【在 o**2 的大作中提到】: 首先,FMP和Java built-in的ExecutorService/Futre机制不是一个级别的东西。FMP在 : 这里只是展示它对imperative programming的支持。 : 其次,如果我们讨论的context仅仅限于这个例子的话,你的代码也缺了很多东西。要 : 写足了的话,会超过三行。 : 1)你要有一个ExecutorService,这相当与FMP的第50行; : 2) worker1 & 2 必须是Callable或Runnable,改写的话,就超过了60/70这两行; : 3) 你必须要有worker1和worker2的class源码,它们可能是同一个或两个不同classes; : 4) 一个class里Callable或Runnable只能各implements一次; : 5) messenger给它管理下的receivers(e.g. worker1&2)提供单线程环境。(这个有 : 点超出了刚才设定的context) w****k 发帖数: 6244 15
这个,简单的multiprocess就可以实现了嘛
【在 o**2 的大作中提到】: 会用OO编程的应该就会用FM编程,因为FM可以被当作utilities来用,门坎很低。你只 : 需要在你需要的地方加一点点FM就可以了。 : 比如说你有一段程序如下,其中的两个worker objects做的都是耗时的工作。因为是顺 : 序执行的,程序要花25秒才能到300行。 : 100 Object result1 = worker1.do10seconds(); : 200 Object result2 = worker2.do15seconds(); : 300 makeUseOf(result1, result2); : 不管你的整个程序或系统有多大,你可以只在这三行程序上使用FM编程。 : // 必要的设置 : 50 Messenger messenger = new Messenger(); g*****g 发帖数: 34805 16
While what you say is true with JDK, however, lots of frameworks already
remove
the boiler plate code. e.g.
@Async annotation in Spring is enough to make a method asynchronous and
hooked to a threadpool. I won't need 1) and 2) below, and if I don't have
the source code of worker1/2, I can always wrap worker1.doSomething in my
own method. So 3) and 4) are not applicable. 5) is more like actor model,
but that's not the requirement here.
classes;
【在 o**2 的大作中提到】: 首先,FMP和Java built-in的ExecutorService/Futre机制不是一个级别的东西。FMP在 : 这里只是展示它对imperative programming的支持。 : 其次,如果我们讨论的context仅仅限于这个例子的话,你的代码也缺了很多东西。要 : 写足了的话,会超过三行。 : 1)你要有一个ExecutorService,这相当与FMP的第50行; : 2) worker1 & 2 必须是Callable或Runnable,改写的话,就超过了60/70这两行; : 3) 你必须要有worker1和worker2的class源码,它们可能是同一个或两个不同classes; : 4) 一个class里Callable或Runnable只能各implements一次; : 5) messenger给它管理下的receivers(e.g. worker1&2)提供单线程环境。(这个有 : 点超出了刚才设定的context) o**2 发帖数: 168 17
我不是很熟悉workflow engine,没有实战经验,不好比较。定性地说,FMP是用于通用
编程的,不仅仅限于workflow engine能做的事。
workflow
【在 t****a 的大作中提到】: 很有趣!看起来像是一个自己可以figure out dependency并且并行执行job的workflow : engine。 : 可能现有的一些FP语言里已经有类似的package了吧?上次曾在github上看到clojure的 : 一个workflow包。 : 楼主能说说这个比workflow engine好在哪些地方吗? o**2 发帖数: 168 18
理论上result1.get()和result2.get()是并发的,你只要等最长的那个(也就是15秒)
结束,就可以进入makeUseOf()了。
【在 c****e 的大作中提到】: 你这个get和java的future是一样的,都是block的?C# await有个很大的benefit就是 : continuation.Task没有执行完也马上返回: : 如果makeUseOf(result1.get(), result2.get())是个很大的函数: : result1要很久才用到,get()如果一block, 要等25秒才能进makeUseOf? : : classes; o**2 发帖数: 168 19
我在8楼列举了一些FMP的优点,不过一时半会儿是解释不清的。所以我说“进驻
Programming 版”就是长期从各个方面介绍FMP的特色。
FMP的核心是active object,并规定active object是virtual的,要一个virtual
machine来realize它们,Messenger就是这样一个virtual machine。
如果把active object看成是一个interface,就可以更好理解用户的责任:用户需要实
现这个interface声明的function。(上面的例子中有两个activeobject:“worker1”
和“worker2”,它们的function分别是do10seconds和do15seconds。)
用户怎么做呢?这由Messenger来定,比如我提供的reference implementation中的
Messenger支持三种方式:POJO (via reflection),IReceiver,和ICallee。
FMP并不定义Messenger和用户之间的事,比如你完全可以开发一个你的Messenger,让
它支持用户定义的Annotation。
其实在我的JavaScript RI中,用户可以直接用JavaScript function来实现
activeobject定义的function,完全可以不用object。也就是说,FMP可以和OOP脱离,
在非OO语言上实现。
Annotation on the method, or on wrapper method, is typically more cleaner
and stronger-typed than reflection.
I am just trying to figure out the strength of your framework and maybe you
didn't show me your best example.
【在 g*****g 的大作中提到】: While what you say is true with JDK, however, lots of frameworks already : remove : the boiler plate code. e.g. : @Async annotation in Spring is enough to make a method asynchronous and : hooked to a threadpool. I won't need 1) and 2) below, and if I don't have : the source code of worker1/2, I can always wrap worker1.doSomething in my : own method. So 3) and 4) are not applicable. 5) is more like actor model, : but that's not the requirement here. : : classes; z*******3 发帖数: 13709 20
pojo是xml还是annotation?
【在 o**2 的大作中提到】: 我在8楼列举了一些FMP的优点,不过一时半会儿是解释不清的。所以我说“进驻 : Programming 版”就是长期从各个方面介绍FMP的特色。 : FMP的核心是active object,并规定active object是virtual的,要一个virtual : machine来realize它们,Messenger就是这样一个virtual machine。 : 如果把active object看成是一个interface,就可以更好理解用户的责任:用户需要实 : 现这个interface声明的function。(上面的例子中有两个activeobject:“worker1” : 和“worker2”,它们的function分别是do10seconds和do15seconds。) : 用户怎么做呢?这由Messenger来定,比如我提供的reference implementation中的 : Messenger支持三种方式:POJO (via reflection),IReceiver,和ICallee。 : FMP并不定义Messenger和用户之间的事,比如你完全可以开发一个你的Messenger,让
z*******3 发帖数: 13709 z*******3 发帖数: 13709 22
木有认真看你在做啥
不过从前面的人的说法看
貌似有两个东西你最好看看
一个是akka,akka有一个不好就是annotation支持比较差
如果你能做一个annotation支持的thread lib的话,还是有戏的
另外一个是work flow
work flow engine有一个标准叫做bpm
java的是jbpm,这个标准相对成熟
而且很多产品都已经可视化了,拖拖拽拽就搞定了
所以如果你想要继续
不妨认真思考一下这两个成型的产品系列会不会对你这个产品的生存造成冲击 m*******l 发帖数: 12782 23
why not let makeuseof() return immediately too?
【在 o**2 的大作中提到】: 理论上result1.get()和result2.get()是并发的,你只要等最长的那个(也就是15秒) : 结束,就可以进入makeUseOf()了。 o**2 发帖数: 168 24
让一个method(callee method)立即返回,是因为它需要时间去计算结果,同时调用
它的函数(caller method)并不急着使用那个结果。但最终来说,一个程序是要话时
间做计算的,你如果让每一个method都立即返回,那最后整个程序不也立即返回了吗?
【在 m*******l 的大作中提到】: why not let makeuseof() return immediately too? o**2 发帖数: 168 25
FMP特意和Actor Model拉开距离的,Carl Hewitt和Gul Agha的原始paper,以及Gul的
学生近年来做的东西,我都有看过。我深深体会到从73年就开始的actor model,从来
没有在mainstream deveoper里流行,真是有原因的。所以FMP全面采用OOP的用词,
active object在OOP里也是很早就提出了的。
至于和workflow engine相区别,我只能说FMP是用于通用编程的,并且目标就是no
thread,所以FMP不会变成thread library的。
【在 z*******3 的大作中提到】: 木有认真看你在做啥 : 不过从前面的人的说法看 : 貌似有两个东西你最好看看 : 一个是akka,akka有一个不好就是annotation支持比较差 : 如果你能做一个annotation支持的thread lib的话,还是有戏的 : 另外一个是work flow : work flow engine有一个标准叫做bpm : java的是jbpm,这个标准相对成熟 : 而且很多产品都已经可视化了,拖拖拽拽就搞定了 : 所以如果你想要继续 c****e 发帖数: 1453 26
Not every function, it's essentially future + yield, so you can get better
control and write code in a more straightforward way. Check out await in C#.
It's syntactic sugar, but quite powerful and intuitive. Python is adding it
to 3.4 as well.
http://www.youtube.com/watch?feature=player_embedded&v=sOQLVm0-
【在 o**2 的大作中提到】: 让一个method(callee method)立即返回,是因为它需要时间去计算结果,同时调用 : 它的函数(caller method)并不急着使用那个结果。但最终来说,一个程序是要话时 : 间做计算的,你如果让每一个method都立即返回,那最后整个程序不也立即返回了吗? z*******3 发帖数: 13709 27
actor在电信业,那些搞通信的人里面,还是比较常见的
今天pda那些个版面上面的id,大部分是搞通信出身的
非正统软件行当混出来的
anyway,有人愿意做东西,应该是要鼓励的
世界因为有你这种人才更美好
【在 o**2 的大作中提到】: FMP特意和Actor Model拉开距离的,Carl Hewitt和Gul Agha的原始paper,以及Gul的 : 学生近年来做的东西,我都有看过。我深深体会到从73年就开始的actor model,从来 : 没有在mainstream deveoper里流行,真是有原因的。所以FMP全面采用OOP的用词, : active object在OOP里也是很早就提出了的。 : 至于和workflow engine相区别,我只能说FMP是用于通用编程的,并且目标就是no : thread,所以FMP不会变成thread library的。 o**2 发帖数: 168