Excellent. This is a far more positive angle. Point taken. On Saturday, 13 October 2012 05:40:17 UTC+10, Dominic wrote: > > It's really about collaboration. The answer to the problem "too many > modules" isn't Write Less Modules, it's Collaborate More! > > the ability to collaborate is a soft human skill, but a skill that you can > develop. > > On Fri, Oct 12, 2012 at 3:34 PM, Rick Waldron > <[email protected]<javascript:> > > wrote: > >> >> 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]<javascript:> >> > 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]<javascript:> >> To unsubscribe from this group, send email to >> [email protected] <javascript:> >> 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]<javascript:> >> To unsubscribe from this group, send email to >> [email protected] <javascript:> >> 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]<javascript:> >> To unsubscribe from this group, send email to >> [email protected] <javascript:> >> 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
