On Friday, October 12, 2012 at 6:15 AM, Dominic Tarr wrote:
> I was worried for a second that this post was gonna be about punctuation. > > Pleasantly Surprised! > > The hardest part is the bit about NIH. This isn't really something we > understand properly yet. It can be a struggle just to find other modules that > do the think you want. Sometimes you've written a module before you even > discover that other solutions exist. > > If you do find someone has a module that is close to what you need, > but not quite, in some important way, then you need to communicate with them. > The best way to do this is on IRC. Unfortunately not everyone uses IRC. > > Please use IRC. +9001 > > Code is a personal thing, and it's important to try and understand the VIBE > the author is going for. Issues aren't really a way to communicate vibe. > > If someone is posting issues, or telling you about stuff in irc, please > listen to them. Even if they are annoying. They will probably improve the > usability of your module quite a bit. > > To really understand this though, I think we need anthropologists to live > with hackers, and write a whole book about it. > > On Fri, Oct 12, 2012 at 9:52 AM, Tim Oxley <[email protected] > (mailto:[email protected])> wrote: > > Yep, the idea of best practices is "do this unless you have a good reason > > not to", which doesn't mean it's a blanket rule that must never be broken. > > A guideline, not a rule. > > > > The main issue with inconsistent sync/async functions is the behaviour has > > low discoverability unless it's documented (unlikely), you read the source, > > or you get gotcha'd by it. > > > > -Tim > > > > > > On Friday, 12 October 2012 08:46:52 UTC+10, Jimb Esser wrote: > > > Though process.nextTick() *itself* is fast, delaying calling the callback > > > until it gets through that queue can have large performance implications, > > > for example, in our case, we may have a tick of our physics simulation > > > queued up (which could take hundreds of ms), and if some logic has to go > > > through a few process.nextTicks, all interspersed with some other > > > expensive operations in between, this kind of API can lend itself to some > > > poorly performing side effects. > > > > > > That being said, I do agree that it's generally "best practice" to do > > > this, but it's good to be aware that it's not always the best for > > > performance (in some of our own APIs, where we set them up to always call > > > the callbacks asynchronously, we have needed to add short-cuts in a > > > couple of cases where it had a significant impact on latency). > > > > > > On Thursday, October 11, 2012 1:36:58 PM UTC-7, Adam Crabtree wrote: > > > > It's a best practice because it helps those unfamiliar with the > > > > reasoning to keep from shooting themselves or their users in the foot. > > > > There are several ways that this may affect you, but a quick summary > > > > can be found here: > > > > > > > > http://howtonode.org/understanding-process-next-tick > > > > > > > > How slow is process.nextTick? A quick benchmark reveals it's not just > > > > <1ms, but in fact is roughly 1µs (0.001ms for the lazy): > > > > > > > > var i = 0, sum = 0 > > > > ;(function foo() { > > > > var t = process.hrtime() > > > > process.nextTick(function() { > > > > sum += process.hrtime(t)[1] > > > > if(++i<10000000) return foo() > > > > console.log('Average time: ', sum/i) > > > > }) > > > > })() > > > > > > > > > > > > That being said, there are always exceptions to the rule, and if you > > > > understand the tradeoffs and have a need to shave off µs, then go for > > > > it. Chances are though, for the other 99.9% it's a micro-optimization > > > > (no pun intended ;P). Again, this requires a special set of > > > > circumstances to be an issue, but when it is, discovering that the > > > > cause was a cache hit and a synchronous call to callback can be > > > > frustrating. > > > > > > > > Cheers, > > > > Adam Crabtree > > > > > > > > On Thu, Oct 11, 2012 at 12:50 PM, Axel Kittenberger <[email protected]> > > > > wrote: > > > > > > I'd rather see client patterns that are immune to callbacks being > > > > > > called before the function returns sometimes. > > > > > > > > > > Ditto! > > > > > > > > > > We should encourage people to write callers that are good, rather than > > > > > libraries that deliberately waste performance and tell the callers > > > > > "its alright you wrote bad code, they have to put in a > > > > > process.nextTick anyway". And < 1ms can be a lot in some areas. > > > > > > > > > > Document your function accordingly, if it guarantees a particular > > > > > callback/return order or not. In many situations, standard is, > > > > > callback immediately if you have all what is needed for the callback. > > > > > If the caller fucks up, that one should be fixed, instead of the > > > > > callee. > > > > > > > > > > Or in other words, cure the problem, not the symptom. > > > > > > > > > > -- > > > > > 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 > > > > > > > > > > > > > > > > -- > > > > Better a little with righteousness > > > > than much gain with injustice. > > > > Proverbs 16:8 > > -- > > 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] > > (mailto:[email protected]) > > To unsubscribe from this group, send email to > > [email protected] > > (mailto: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 -- 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
