I would put it like this: People are writing concurrent applications. Basically, people who used to write Rails apps are writing servers now. This is harder.
The hardest part of concurrent programming is understand and managing state mutations. We all hate dealing with threads in C right? There are many different ideas on this list about what the best visual representation of state mutations is. JavaScript is not Erlang, it doesn't enforce a serialization between two pieces of code that will run concurrently so that they don't mutate shared state, JavaScript runs exactly one piece of code at any time and *we* write APIs that give the programmer an indication of *when* that state is allowed to change and assume it will not change the rest of the time. Callbacks are at the farthest side of the "show me very explicitly when my state changes" spectrum and all these other libraries fall somewhere on "hide or abstract it" spectrum. People's preferences have a lot more to do with how they program and how they think about programming than the problems they are solving. Most of the assertions that any particular approach is better for a particular class of problems are incredibly exaggerated. Some people think very serially and don't want to have the state changes as visible. Other people, and I put myself in this camp, think about their concurrent program very specifically in terms of state and the mutations of that state between concurrent actors that have access to change it. Others are far more comfortable abstracting and chaining state changes in to higher order abstractions. None of these are "simpler" than another. callbacks require the least amount of additional API and conceptual understanding (all the features of callbacks have to be understood to write any other javascript code) but not everyone can keep the closure scoping rules in their head as part of their application logic. The whole "programmers should be lazy" thing is a strange point of view. It's *more* work to learn another additional abstractions. It's also more work for people like to me keep that abstraction in their head because we *need* to understand the state changes and scopes being created while others find the opposite is true. Your statement about core adopting callbacks over promises/futures is ill informed. The point of callbacks is to provide a layer of compatibility in core's APIs for IO. Problems like this, of which there are differing and entirely valid points of view, should *never* be decided by core. Callbacks require no additional features or API other than convention, this provides the largest scope of compatibility for higher order abstractions. If core used promises internally it would be much harder for these libraries that you advocate for to exist. -Mikeal On May 24, 2013, at 11:41AM, Billy Te <[email protected]> wrote: > @Raynos and Bruno Jouhier > > Creating a good language and good supporting functionality is not about > catering to what *you* like or what *you* are ok with dealing with. Its about > creating easy to use, powerful functionality that can be combined in ways > that > > A. make new ways of doing things possible, so people can experiment and > improve, and > B. allow people to program and think in a way that more closely matches their > programming domain > > By saying "We don't need them, because people that do are lazy" shows how > little you know about good design. You *should* be the lazy programmer > because lazy programmers don't like doing repetitive monotonous work that > drives down their productivity and creativity. > > The argument here is not about making every programmer write synchronous > versions of every method. This is how the core 'fs' module works, and tho > it's useful, its also bad design. Futures/promises are the solution to this. > No one needs to write two versions of functions. Futures allow for much more > maintainable code, as well as having the ability to write code in new, > non-cludgy ways. Node.js was originally planning on using futures as the main > concurrency scheme, but apparently the designers were overwhelmed by > different dogmas as to how futures should work that they just said "fuck it" > and went with callbacks, which aren't flexible but are dead simple. This was > short sighted of them. > > > > On Thursday, December 1, 2011 9:11:05 AM UTC-8, Raynos wrote: > On Dec 1, 4:51 pm, Jake Verbaten <[email protected]> wrote: > > You can use the sync version of any APIs available. > > Q: why do we need/have sync APIs? > > I would not mind if node did not have any sync APIs (not even > require). At least nobody would be tempted to put a blocking call in > the middle of a module. > > I'd agree we don't need them. They are there when people are too lazy to use > the async version. > > -- > -- > Job Board: http://jobs.nodejs.org/ > Posting guidelines: > https://github.com/joyent/node/wiki/Mailing-List-Posting-Guidelines > You received this message because you are subscribed to the Google > Groups "nodejs" group. > To post to this group, send email to [email protected] > To unsubscribe from this group, send email to > [email protected] > For more options, visit this group at > http://groups.google.com/group/nodejs?hl=en?hl=en > > --- > You received this message because you are subscribed to the Google Groups > "nodejs" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to [email protected]. > For more options, visit https://groups.google.com/groups/opt_out. > > -- -- Job Board: http://jobs.nodejs.org/ Posting guidelines: https://github.com/joyent/node/wiki/Mailing-List-Posting-Guidelines You received this message because you are subscribed to the Google Groups "nodejs" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/nodejs?hl=en?hl=en --- You received this message because you are subscribed to the Google Groups "nodejs" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. For more options, visit https://groups.google.com/groups/opt_out.
