p*****2
发帖数: 21240 | 1 先不说可以用libarary 和 generator 解决
就node callback本身比fp， thread 已经容易百倍了 |
W***o
发帖数: 6519 | 2 曾经，折腾pthread, pre-emptive threads scheduling 折腾的我头疼， node
callback 感觉没有那么抽象，觉得要容易一些
【在 p*****2 的大作中提到】
: 先不说可以用libarary 和 generator 解决
: 就node callback本身比fp， thread 已经容易百倍了
|
a*****e
发帖数: 1700 | 3 你这里 fp 和 thread 指什么？
没有 functional programming 里面的闭包概念和内存垃圾回收，你用 C 来写
callback 程序（比如写个X11应用）就知道 javascript 其实已经是 fp 了。
(pre-emptive) thread 和 callback / co-routine 完全是两回事，面向的是不同问题
。请不要混为一谈。
【在 p*****2 的大作中提到】
: 先不说可以用libarary 和 generator 解决
: 就node callback本身比fp， thread 已经容易百倍了
|
d*******r
发帖数: 3299 | 4 1，2 楼的大概意思是，用 JS callback 的抽象来写并发执行的程序，比用 pthread
之类的抽象来写，要简单很多了。
【在 a*****e 的大作中提到】
: 你这里 fp 和 thread 指什么？
: 没有 functional programming 里面的闭包概念和内存垃圾回收，你用 C 来写
: callback 程序（比如写个X11应用）就知道 javascript 其实已经是 fp 了。
: (pre-emptive) thread 和 callback / co-routine 完全是两回事，面向的是不同问题
: 。请不要混为一谈。
|
n****1
发帖数: 1136 | 5 Thread显然是最简单直观的，只不过是运行效率差罢了，所以go有goroutine，haskell
里有forkIO,都是thread方式的api,callback级别的运行效率。
node要想摆脱callbk的恶名，必须脱胎换骨：把一个promise/future/generator/
whatever的东西彻底标准化，然后deprecate所有带callbk的api，强制放弃维护。否则
江山易改，禀性难移。
【在 d*******r 的大作中提到】
: 1，2 楼的大概意思是，用 JS callback 的抽象来写并发执行的程序，比用 pthread
: 之类的抽象来写，要简单很多了。
|
q*c
发帖数: 9453 | 6 callback 是串行， thread 是并行， 不是一回事吧？
【在 p*****2 的大作中提到】
: 先不说可以用libarary 和 generator 解决
: 就node callback本身比fp， thread 已经容易百倍了
|
c******o
发帖数: 1277 | 7 callback也可以并行，上面形式上是一样的，底下改成messaging就可以了。 |
p*****2
发帖数: 21240 | 8 node里callback就是并行 当然严格地说是并发
【在 q*c 的大作中提到】
: callback 是串行， thread 是并行， 不是一回事吧？
|
