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. 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]> 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<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<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<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] > 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
