That was an interesting paper, and thank you for sending it along. I often find myself describing the essential problems I have working in Node as rooted in resolving the tensions inherent in JavaScript. This is precisely due to the presence in JS of both OO and functional paradigms.
Some things to consider, though: 1. JavaScript uses OO techniques to manage state, especially when performance is a consideration. It is much faster to use direct mutation on an object than it is to create any kind of persistent data structure. 2. JavaScript has a simply-typed functional core. While there is imperative control flow, in most circumstances JS developers are encouraged to use anonymous functions passed to higher-order functions to achieve most common goals. 3. Node.js's fundamental control flow paradigm is the asynchronous execution of chains of callbacks. In some ways this is similar to continuation-passing style, but because it is the result of ad hoc design decisions (as opposed to the result of a mechanical transformation applied by a compiler or macro system), user and library code can make few assumptions about control flow beyond those specified by their own interfaces. 4. "Simplicity" in the Node world is coming to mean "composability" first and foremost. Each module should export one unit of functionality, and then users can choose the modules that they feel will work best to solve their particular problems. This places a premium on the traditional software engineering values of loose coupling and tight cohesion. It also means that the streams of data passed between modules tend to be basic data types rather than structures, with Buffers being about the most complex type commonly encountered. 5. Node was designed to build fast web services. As such, it's accumulated a body of lore that can be used to work with V8's JIT, the system calls for each platform, and other things that frequently result in awkward combinations of JS's twin OO and functional natures. Jake's sketched-out solution does a good job of reconciling some of the contradictions inherent in Node's approach. It's stateful but not based on mutation, it uses two simple functions to define control flow, and it's quite clear and explicit about how it works without slapping a pile of abstractions in the way. Node is built to do a certain class of tasks as quickly and efficiently as possible. Its design decisions were made with an eye towards simplicity and performance, not elegance or purity. The emerging consensus of the community seems to be that the best way to deal with the rough edges of Node's use of JavaScript is to keep things small and simple, but also idiomatic. New techniques for control flow are fun to develop and play with, but the more they become controlling abstractions, the less useful they are to the general body of Node developers. IMHO, at least. F On Saturday, December 29, 2012, Eldar wrote: > @Raynos, @greelgorke I would recommend reading Out of the > tarpit<http://shaffner.us/cs/papers/tarpit.pdf>. > It argues that traditional imperative approach with control flow being > messed with logic leads to complex unmaintainable just ugly software. > > On Saturday, December 29, 2012 11:39:28 AM UTC+4, Raynos wrote: >> >> You can implement the same idea with two functions >> >> Here the code is explicit about how it runs code. >> >> ```js >> var execute = require("execute") >> , serial = require("serialize") // unimplemented see >> https://gist.github.com/**4405173 <https://gist.github.com/4405173> >> >> var run = serial([ >> function (cb) { >> execute({ >> sum1: function (cb) { add(1, 2, cb) } >> , sum2: function (cb) { add(3, 4, cb) } >> }, cb) >> } >> , function (result, cb) { >> add(result.sum1, result.sum2, cb) >> } >> ]) >> >> run(printResult) >> >> function printResult(err, result) { >> if (err) { >> throw err >> } >> console.log("result", result) // prints "result=10" >> } >> ``` >> >> Although your idea is interesting, it's hard to build something that's >> cleaner then just being explicit about how you do things. >> >> Also notice that because we are using clean functional abstractions they >> compose trivially ( http://jsfiddle.net/fvz7N/4/** ) like functions >> should. >> >> Your ideas however are interesting, the problem is that they are far more >> complex to grok and require trust on self organizing code. Also it's full >> of implicit magic by the very definition of self organizing code. >> >> It should be noted substack had a similar idea with disorder ( >> https://github.com/substack/**node-disorder#disorder<https://github.com/substack/node-disorder#disorder> >> ) >> > -- > 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]<javascript:_e({}, 'cvml', '[email protected]');> > To unsubscribe from this group, send email to > [email protected] <javascript:_e({}, 'cvml', > 'nodejs%[email protected]');> > For more options, visit this group at > http://groups.google.com/group/nodejs?hl=en?hl=en > -- 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
