n*****t
发帖数: 22014 | 1 丁点大的破事也要 callback，然后再 call，流水线的美感都破坏了。
顺便请教一下，node 里发一串 db query，是不是实际还是挨个跑的？ |
p*****2
发帖数: 21240 | 2
什么db？
【在 n*****t 的大作中提到】
: 丁点大的破事也要 callback，然后再 call，流水线的美感都破坏了。
: 顺便请教一下，node 里发一串 db query，是不是实际还是挨个跑的？
|
n*****t
发帖数: 22014 | 3 Mongo， 不过应该跟 node 有关吧？没开 cluster 不是只有一个线程吗？
【在 p*****2 的大作中提到】
:
: 什么db？
|
p*****2
发帖数: 21240 | 4
Node是多任务的。Mongo的读并发很好。Node跟Mongo配合不错。
写的话Mongo有global lock，并发效果不好，要上Cassandra。
【在 n*****t 的大作中提到】
: Mongo， 不过应该跟 node 有关吧？没开 cluster 不是只有一个线程吗？
|
n*****t
发帖数: 22014 | 5 啊？node 多任务啊？看样子我哪里理解错了，谢谢指教。
另外请教一下，一堆 callback 链在一起了，有什么好的技巧避免吗？假设我要更新一
堆记录，全部更新之后才能 ，find，每 update 一次结束后才能 callback update
next，貌似只能这么串了？
【在 p*****2 的大作中提到】
:
: Node是多任务的。Mongo的读并发很好。Node跟Mongo配合不错。
: 写的话Mongo有global lock，并发效果不好，要上Cassandra。
|
d******k
发帖数: 28 | 6 你可以用一些library来帮你回到流水线的美感，比如Step, Async |
p*****2
发帖数: 21240 | 7 我是用coffee的 感觉没有那么痛苦 还是比较直白
另外你这些操作一定要串行吗 并行可不可以
楼上说了可以用库 js马上要支持generator了 就是为了解决这个问题的
node的并发靠的是async non blocking io 跟threading不太一样 当然利用多核就需要
上cluster了 communication不如thread ing方便 但是也完全没有thread ing那些头疼
的问题了 综合来看特别适合web开发 每个request都是独立的
【在 n*****t 的大作中提到】
: 啊？node 多任务啊？看样子我哪里理解错了，谢谢指教。
: 另外请教一下，一堆 callback 链在一起了，有什么好的技巧避免吗？假设我要更新一
: 堆记录，全部更新之后才能 ，find，每 update 一次结束后才能 callback update
: next，貌似只能这么串了？
|
N********n
发帖数: 8363 | 8
LOL. Too many people here said it already: Callback = modern day
GOTO. It ruins your code. This is one of the many reasons I don't
see JS ever being use a serious backend language.
【在 n*****t 的大作中提到】
: 丁点大的破事也要 callback，然后再 call，流水线的美感都破坏了。
: 顺便请教一下，node 里发一串 db query，是不是实际还是挨个跑的？
|
p*****2
发帖数: 21240 | 9
我们用node做backend
【在 N********n 的大作中提到】
:
: LOL. Too many people here said it already: Callback = modern day
: GOTO. It ruins your code. This is one of the many reasons I don't
: see JS ever being use a serious backend language.
|
N********n
发帖数: 8363 | 10
My deepest condolences.
【在 p*****2 的大作中提到】
:
: 我们用node做backend
|
|
|
d*******r
发帖数: 3299 | 11 我说两句吧，callback 其实没想象的那么乱，
毕竟控制流程的单位是function, 不是statement，所以还是比Goto好一些。
避免 callback hell 的方法是两个，
1. 是把一个大的callback chain 里面的部分分别命名，然后拆开成很多小的函数，这
样你测试也方便，出错信息也容易看懂些。
2.不想把一个必要的 callback function 一直传很长很远, 传来传去的，可以换成
event.
http://nodejs.org/api/events.html |
N********n
发帖数: 8363 | 12
That's spinning. At the end of the day callbacks force control
flow to go elsewhere and thus turn your programs into spaghetti
code and breaks its readability.
I'll say it's worse than goto. W/ goto at least you can refine
your code to avoid it. W/ callback there's no avoiding - if you
wanna go async in JS you have to provide callbacks. Bad design.
【在 d*******r 的大作中提到】
: 我说两句吧，callback 其实没想象的那么乱，
: 毕竟控制流程的单位是function, 不是statement，所以还是比Goto好一些。
: 避免 callback hell 的方法是两个，
: 1. 是把一个大的callback chain 里面的部分分别命名，然后拆开成很多小的函数，这
: 样你测试也方便，出错信息也容易看懂些。
: 2.不想把一个必要的 callback function 一直传很长很远, 传来传去的，可以换成
: event.
: http://nodejs.org/api/events.html
|
b***e
发帖数: 1419 | 13 node 11 provides generator functions, which will solve all the call back
hell problem.
【在 N********n 的大作中提到】
:
: That's spinning. At the end of the day callbacks force control
: flow to go elsewhere and thus turn your programs into spaghetti
: code and breaks its readability.
: I'll say it's worse than goto. W/ goto at least you can refine
: your code to avoid it. W/ callback there's no avoiding - if you
: wanna go async in JS you have to provide callbacks. Bad design.
|
d*******r
发帖数: 3299 | 14 大牛是搞语言设计的牛人，从语言的角度来说，大牛怎么看 Node 的前景，
我感觉 Node 还是挺简单直白的，特性比较少.
【在 b***e 的大作中提到】
: node 11 provides generator functions, which will solve all the call back
: hell problem.
|
d*******r
发帖数: 3299 | 15 我觉得并发的程序最后都会变成类似 spaghetti 的东西吧, 只是 organize 得好或者
坏的问题。
因为不管你用什么语言特性来设计，最后都要面对：在某个地方停住，等待某个event
的发生, 然后才能做后面的事情。
在这种情况下，我觉得 event-based 的模型，已经是非常直白了，接近本质了。
难道有某种模型，能绕过这个本质上的逻辑?
【在 N********n 的大作中提到】
:
: That's spinning. At the end of the day callbacks force control
: flow to go elsewhere and thus turn your programs into spaghetti
: code and breaks its readability.
: I'll say it's worse than goto. W/ goto at least you can refine
: your code to avoid it. W/ callback there's no avoiding - if you
: wanna go async in JS you have to provide callbacks. Bad design.
|
i**i
发帖数: 1500 | 16 目前最好的解决方式是promise.
node 0.11+ 可以用 ECMAScript6 的 generator, 配合 co 基本可以做到异步并且代码
“串行”.
https://github.com/visionmedia/co
ECMA Script 6 有很多有趣的用法。node 0.12 值得期待。
【在 n*****t 的大作中提到】
: 丁点大的破事也要 callback，然后再 call，流水线的美感都破坏了。
: 顺便请教一下，node 里发一串 db query，是不是实际还是挨个跑的？
|
i**i
发帖数: 1500 | 17 目前还没有一个公认的最好的module来利用generator解决call back的问题. 等等看吧
。 |
N********n
发帖数: 8363 | 18
It reminds early .Net days where async code was all done in CBs.
Many people got so fed up w/ CBs they simply avoided writing
asynchronous code even when it's called for. It's solved later
when continuation support comes to .Net.
【在 d*******r 的大作中提到】
: 我觉得并发的程序最后都会变成类似 spaghetti 的东西吧, 只是 organize 得好或者
: 坏的问题。
: 因为不管你用什么语言特性来设计，最后都要面对：在某个地方停住，等待某个event
: 的发生, 然后才能做后面的事情。
: 在这种情况下，我觉得 event-based 的模型，已经是非常直白了，接近本质了。
: 难道有某种模型，能绕过这个本质上的逻辑?
|
k**********g
发帖数: 989 | 19
http://fsharpforfunandprofit.com/posts/recipe-part2/
http://www.cs.hmc.edu/~keller/courses/cs156/s98/slides/023.html
【在 N********n 的大作中提到】
:
: It reminds early .Net days where async code was all done in CBs.
: Many people got so fed up w/ CBs they simply avoided writing
: asynchronous code even when it's called for. It's solved later
: when continuation support comes to .Net.
|
c***r
发帖数: 4631 | 20 当年用c写windows程序的时候，不都是callback么？
【在 N********n 的大作中提到】
:
: It reminds early .Net days where async code was all done in CBs.
: Many people got so fed up w/ CBs they simply avoided writing
: asynchronous code even when it's called for. It's solved later
: when continuation support comes to .Net.
|
|
|
l**********n
发帖数: 8443 | 21 callback hell. too many callbacks are hellish. it simply means the
programmer lacks control or design pattern skills. |
a*****e
发帖数: 1700 | 22 核心问题出在 inversion of control。
更早的（比如 X window）就不说了，单是 callback 方式从 windows 3.0 的时候就流
行（且退流行）过。设计语言的人（比如说 nodejs 的设计者），如果不吸取历史教训
，注定要掉进前人踩过的坑里。nodejs 所倡导的 non-blocking/async programming
就是一个不折不扣的谎言。
解决 inversion of control 方法有很多，但基本原理都是一样的。利用
continuation 构建 co-routine 和 event-driven 的互换，因为两者等价（这个也被
证明过)。而 continuation 这种概念从 Lisp 开始就已经被 FP 玩透了。在所谓的主
流语言里，但凡不支持它的，最后都不得不通过各种方式来弥补，成为各种各样的半调
子框架，which unfortunately is the sad truth of status-quo.
建议使用 nodejs 的同学都先来学习一下它的坑：
http://notes.ericjiang.com/posts/751
【在 n*****t 的大作中提到】
: 丁点大的破事也要 callback，然后再 call，流水线的美感都破坏了。
: 顺便请教一下，node 里发一串 db query，是不是实际还是挨个跑的？
|
i**i
发帖数: 1500 | 23 你根本不知道什么是ioc. ioc是指程序自己寻找合适的资源服务来满足要求，完成任务
。所谓don't call me, I will call you.
这跟异步一毛钱关系也没有。
你的连接是给你这样的傻逼看得。
【在 a*****e 的大作中提到】
: 核心问题出在 inversion of control。
: 更早的（比如 X window）就不说了，单是 callback 方式从 windows 3.0 的时候就流
: 行（且退流行）过。设计语言的人（比如说 nodejs 的设计者），如果不吸取历史教训
: ，注定要掉进前人踩过的坑里。nodejs 所倡导的 non-blocking/async programming
: 就是一个不折不扣的谎言。
: 解决 inversion of control 方法有很多，但基本原理都是一样的。利用
: continuation 构建 co-routine 和 event-driven 的互换，因为两者等价（这个也被
: 证明过)。而 continuation 这种概念从 Lisp 开始就已经被 FP 玩透了。在所谓的主
: 流语言里，但凡不支持它的，最后都不得不通过各种方式来弥补，成为各种各样的半调
: 子框架，which unfortunately is the sad truth of status-quo.
|
a*****e
发帖数: 1700 | 24 我什么时候说过 inversion of control 和 async 有关系？我说的是：
1. "callback 反人类" 是因为 "inversion of control"
2. nodejs 鼓吹的 async programming 和 callback 没有一毛钱关系，用 co-routine
一样可以做 async，而且早很多年就被做过了。强迫用户使用 callback 是 nodejs
的设计者脑残。
3. continuation 是实现 co-routine 和 event-driven 之间转换的核心方法。你前面
说的 promise 和 generator 什么的，都属于 imitation of co-routine
【在 i**i 的大作中提到】
: 你根本不知道什么是ioc. ioc是指程序自己寻找合适的资源服务来满足要求，完成任务
: 。所谓don't call me, I will call you.
: 这跟异步一毛钱关系也没有。
: 你的连接是给你这样的傻逼看得。
|
i**i
发帖数: 1500 | 25 1. "callback 反人类" 是因为 "inversion of control"
> 查查什么是ioc. 屎盆子扣错了．
2. nodejs 鼓吹的 async programming 和 callback 没有一毛钱关系，用 co-
routine
一样可以做 async，而且早很多年就被做过了。强迫用户使用 callback 是 nodejs
的设计者脑残。
> nodejs 鼓吹的 async programming. 错了吗？ ＂强迫用户使用 callback ＂是历
史问题，没办法的事． 说什么 ＂强迫 ．．． 设计者脑残。＂ 是你脑残．
3. continuation 是实现 co-routine 和 event-driven 之间转换的核心方法。你前面
说的 promise 和 generator 什么的，都属于 imitation of co-routine
> 这跟 nodejs 鼓吹的 async programming 有毛关系？ 跟你的链接有毛关系？
routine
【在 a*****e 的大作中提到】
: 我什么时候说过 inversion of control 和 async 有关系？我说的是：
: 1. "callback 反人类" 是因为 "inversion of control"
: 2. nodejs 鼓吹的 async programming 和 callback 没有一毛钱关系，用 co-routine
: 一样可以做 async，而且早很多年就被做过了。强迫用户使用 callback 是 nodejs
: 的设计者脑残。
: 3. continuation 是实现 co-routine 和 event-driven 之间转换的核心方法。你前面
: 说的 promise 和 generator 什么的，都属于 imitation of co-routine
|
Y**G
发帖数: 1089 | 26 callback中用匿名函数，还可以访问closure中的变量，这不是挺好的事吗？
【在 n*****t 的大作中提到】
: 丁点大的破事也要 callback，然后再 call，流水线的美感都破坏了。
: 顺便请教一下，node 里发一串 db query，是不是实际还是挨个跑的？
|
c******o
发帖数: 1277 | 27 这个我觉得scala的 future/promise Monad很好。不会在太大的时候混乱。非常接近人
类对async/parallel的思维。
不知道你们看过scala的future/promise Monad实现，其实里面都是callback,但是被
hide了。用起来就很舒服了。 |
a*****e
发帖数: 1700 | 28
以下来自 Wikipedia 字条：
"Inversion of control carries the strong connotation that the reusable code
and the problem-specific code are developed independently even though they
operate together in an application. Software frameworks, callbacks,
schedulers, event loops and dependency injection are examples of design
patterns that follow the inversion of control principle, although the term
is most commonly used in the context of object-oriented programming."
Callback 之所以难以使用，直接原因就是因为 inversion of control，这个没什么好
争辩的。
你骂我我都不和你计较，你又何必嘴硬到底呢？
nodejs
什么“历史问题”？把 callback 作为唯一 I/O 操作方式，难道不是 nodejs 首创的
设计？
你可以仅仅提供 async I/O，但是仅提供 callback 来组织 async 程序就不对了。质
疑 nodejs 的脑残设计的多了去了，你把枪口对准我也没用不是。
前面
假如 nodejs 从语言设计角度能够深刻认识到两者是一个硬币的两面，就可以在语言实
现时提供first class continuation 来方便组织 co-routine 和 callback 两者之间
的互换，也就不需要第三方框架或者库提供的其他方案（overhead比较大）。这才是对
待 async programming 的正确方式。
我给的连接是用来帮助认识 nodejs 缺陷的，我原贴已经说的很明白了。callback
hell 只是其中之一。
【在 i**i 的大作中提到】
: 1. "callback 反人类" 是因为 "inversion of control"
: > 查查什么是ioc. 屎盆子扣错了．
: 2. nodejs 鼓吹的 async programming 和 callback 没有一毛钱关系，用 co-
: routine
: 一样可以做 async，而且早很多年就被做过了。强迫用户使用 callback 是 nodejs
: 的设计者脑残。
: > nodejs 鼓吹的 async programming. 错了吗？ ＂强迫用户使用 callback ＂是历
: 史问题，没办法的事． 说什么 ＂强迫 ．．． 设计者脑残。＂ 是你脑残．
: 3. continuation 是实现 co-routine 和 event-driven 之间转换的核心方法。你前面
: 说的 promise 和 generator 什么的，都属于 imitation of co-routine
|
a*****e
发帖数: 1700 | 29 对，这就是我说的两者等价。
Scala 和 Haskell 也没有 first class continuation，但是支持 continuation
monad 这种抽象方式，在 co-routine 和 callback 间灵活转换没有任何问题，虽然还
是有一定的 interpretive overhead。
【在 c******o 的大作中提到】
: 这个我觉得scala的 future/promise Monad很好。不会在太大的时候混乱。非常接近人
: 类对async/parallel的思维。
: 不知道你们看过scala的future/promise Monad实现，其实里面都是callback,但是被
: hide了。用起来就很舒服了。
|
n****1
发帖数: 1136 | 30 板上好多id张嘴就开大的，真不知道现实中也是和其他人这么相处的么？
难怪喜欢窝里横，便宜口蜜腹剑的三哥 |
|
|
i**i
发帖数: 1500 | 31 嘴下无德，向你道歉。
一般来说，ioc是指运行中的程序通过莫种协议得到所需的资源。 可以通过call back
的方式实现。但是并不是所有的call back都是 ioc.
http://stackoverflow.com/questions/9403155/what-is-dependency-i
比如，angularjs里service的引用.
app.controller("ctrl",function(aService){
这里的aService是在其他地方定义的，运行中通过 "aService" 这个string和定义联系
起来。 这种module发现并调用service的方式叫ioc/di. 并不是一般的call back都是
ioc.
node.js 创造了一个framework, 没有创造一个新的语言。 node.js 可能只有六全六美
。但是 你对node.js缺乏基本的认识，批评的不到点子上。
code
【在 a*****e 的大作中提到】
: 对，这就是我说的两者等价。
: Scala 和 Haskell 也没有 first class continuation，但是支持 continuation
: monad 这种抽象方式，在 co-routine 和 callback 间灵活转换没有任何问题，虽然还
: 是有一定的 interpretive overhead。
|
n****1
发帖数: 1136 | 32 For god sake, IoC != DI |
i**i
发帖数: 1500 | 33 Inversion of Control (IOC) and Dependency Injection (DI) are used
interchangeably. IOC is achieved through DI. DI is the process of providing
the dependencies and IOC is the end result of DI.
【在 n****1 的大作中提到】
: For god sake, IoC != DI
|
n****1
发帖数: 1136 | 34 IoC is much broader problem. DI is a partial solution to a tiny fraction of
the problem.
The main() function in C/C++ is to solve IoC, the method overriding in OOP
is to solve IoC, reflection is to solve IoC. If you put an equal sign
between them, then your definition of "IoC" is clearly different than the
rest of the world, so there is no point to argue here. |
i**i
发帖数: 1500 | 35 我就这么说了． 一般也是这么理解的．
If
argue
【在 n****1 的大作中提到】
: IoC is much broader problem. DI is a partial solution to a tiny fraction of
: the problem.
: The main() function in C/C++ is to solve IoC, the method overriding in OOP
: is to solve IoC, reflection is to solve IoC. If you put an equal sign
: between them, then your definition of "IoC" is clearly different than the
: rest of the world, so there is no point to argue here.
|
i**i
发帖数: 1500 | |
i**i
发帖数: 1500 | 37 说我吗？ 正在学习中。 请多指教。
【在 n****1 的大作中提到】
: 板上好多id张嘴就开大的，真不知道现实中也是和其他人这么相处的么？
: 难怪喜欢窝里横，便宜口蜜腹剑的三哥
|
a*****e
发帖数: 1700 | 38 一定程度上的 hair splitting 也是有意义的。至少我现在明白你说的 IoC is
strictly in a OO sense。
如果我们追溯一下 IoC 这个词的起源，wiki 上给出的是 Martin Fowler 的博文:
http://martinfowler.com/bliki/InversionOfControl.html
里面提到:
"There is some confusion these days over the meaning of inversion of control
due to the rise of IoC containers; some people confuse the general
principle here with the specific styles of inversion of control (such as
dependency injection) that these containers use. The name is somewhat
confusing ..."
我使用 IoC 这个词的原意和 Fowler 给的例子相近，都是泛指这种把程序的 control
flow 交给 framework 掌控的这种现象。而你谈到这个 IoC 词，指的是 dependency
injection。
【在 i**i 的大作中提到】
: 我就这么说了． 一般也是这么理解的．
:
: If
: argue
|
i**i
发帖数: 1500 | 39 我指的是spring的ioc。以后我得加上这个前提，免得有歧义。
言语有冒犯之处，再次道歉。 |
b***e
发帖数: 1419 | 40 https://www.npmjs.org/package/node-sync
I use this one.
【在 i**i 的大作中提到】
: 目前还没有一个公认的最好的module来利用generator解决call back的问题. 等等看吧
: 。
|
|
|
d*******r
发帖数: 3299 | 41 我觉得这个贴的讨论很好呀，没说好，立马道歉纠正就避免吵架了呀
我1个多月下来，其实已经用习惯了 Node 的 callback 了，
感觉代码组织的好，多模块化自己的函数，代码也不至于乱的。
不过还是需要注意，async callbacks 和 sync executed statements 混着用，有时候
还是有点容易出错.
其实每次调用 async callbacks 的时候，相当于在 C 里面调用了 fork(), 之后的执
行逻辑就 virtually 分叉了。
不过我是觉得 callback 确实 *不是必要的*.
其实要表现 代码段A (或者 event A) 必须执行在 代码段B (或者 event B) 之前，
callback 的方法确实不是必须的.
sync executed statements 确实是更自然的表现方式，所以这个和 async callbacks
混着用的时候，还是觉得 async callbacks 用着没这么舒服。而且 async 和 sync 的
方式混用，其实是增加了 programer 的思维负担的. |
d*******r
发帖数: 3299 | 42 """
建议使用 nodejs 的同学都先来学习一下它的坑：
http://notes.ericjiang.com/posts/751
"""
本着认真学习的态度看了下这个帖子，黑Node黑得极其没有水平。
很多时候还都在说 exception 的问题，我怎么记得我看过的 Node tutorial 都劝说直
接不用 exception 得了。
【在 a*****e 的大作中提到】
: 核心问题出在 inversion of control。
: 更早的（比如 X window）就不说了，单是 callback 方式从 windows 3.0 的时候就流
: 行（且退流行）过。设计语言的人（比如说 nodejs 的设计者），如果不吸取历史教训
: ，注定要掉进前人踩过的坑里。nodejs 所倡导的 non-blocking/async programming
: 就是一个不折不扣的谎言。
: 解决 inversion of control 方法有很多，但基本原理都是一样的。利用
: continuation 构建 co-routine 和 event-driven 的互换，因为两者等价（这个也被
: 证明过)。而 continuation 这种概念从 Lisp 开始就已经被 FP 玩透了。在所谓的主
: 流语言里，但凡不支持它的，最后都不得不通过各种方式来弥补，成为各种各样的半调
: 子框架，which unfortunately is the sad truth of status-quo.
|
L***s
发帖数: 1148 | 43 我不熟js。略懂Python。
Python的coroutines (`yield` / enhanced generators)
和async io (`yield from`) 也是都callbacks的上层封装抽象，
底下都是裸体callbacks实现的。上下层同时暴露，虽然鼓励用上层封装。
js若要提供上层抽象估计也是类似思路，在现有的callbacks基础上封装。
coroutines和callbacks不是对立的，只是抽象层次不同，前者可用后者实现。
【在 a*****e 的大作中提到】
: 核心问题出在 inversion of control。
: 更早的（比如 X window）就不说了，单是 callback 方式从 windows 3.0 的时候就流
: 行（且退流行）过。设计语言的人（比如说 nodejs 的设计者），如果不吸取历史教训
: ，注定要掉进前人踩过的坑里。nodejs 所倡导的 non-blocking/async programming
: 就是一个不折不扣的谎言。
: 解决 inversion of control 方法有很多，但基本原理都是一样的。利用
: continuation 构建 co-routine 和 event-driven 的互换，因为两者等价（这个也被
: 证明过)。而 continuation 这种概念从 Lisp 开始就已经被 FP 玩透了。在所谓的主
: 流语言里，但凡不支持它的，最后都不得不通过各种方式来弥补，成为各种各样的半调
: 子框架，which unfortunately is the sad truth of status-quo.
|
a*****e
发帖数: 1700 | 44 的确不是对立的，可以互换，callback 也可以用 co-routine 实现。所以并不存在抽
象层次上的差别。
【在 L***s 的大作中提到】
: 我不熟js。略懂Python。
: Python的coroutines (`yield` / enhanced generators)
: 和async io (`yield from`) 也是都callbacks的上层封装抽象，
: 底下都是裸体callbacks实现的。上下层同时暴露，虽然鼓励用上层封装。
: js若要提供上层抽象估计也是类似思路，在现有的callbacks基础上封装。
: coroutines和callbacks不是对立的，只是抽象层次不同，前者可用后者实现。
|
T*******x
发帖数: 8565 | 45 同意。
而且突然发作，像是控制不住。
【在 n****1 的大作中提到】
: 板上好多id张嘴就开大的，真不知道现实中也是和其他人这么相处的么？
: 难怪喜欢窝里横，便宜口蜜腹剑的三哥
|
i**i
发帖数: 1500 | 46 用不着你来当裁判。
【在 T*******x 的大作中提到】
: 同意。
: 而且突然发作，像是控制不住。
|
