+1 on this being blogged. not into TypeScript but would be very interested in you elaborating on the two rules / js optimization info you mention in the beginning.
On Monday, October 1, 2012 4:11:12 PM UTC-7, Dick Hardt wrote: > > +1 to putting this on your blog Isaac. > > On Oct 1, 2012, at 3:50 PM, Rick Waldron <waldro...@gmail.com<javascript:>> > wrote: > > > > On Mon, Oct 1, 2012 at 6:46 PM, Isaac Schlueter <i...@izs.me <javascript:> > > wrote: > >> I've been through the paces quite a few times trying to optimize the >> hell out of very hot code. In the last few years, this has been >> mostly in V8, of course, but the basic principles are not too far off >> in different JS environments. >> >> It's important to not put too much weight in rules of thumb, and we >> programmers are particularly bad at that, given our tendencies towards >> abstraction. But that disclaimer out of the way, I've found very few >> exceptions to these two rules: >> >> 1. If you have more than one of something, use a class; not a "plain >> old object". I recently changed the "url" module in node-master, and >> made it twice as fast by replacing the plain {}-style objects with Url >> class instances. >> 2. Always put the same kinds of things in the same places. An array >> of numbers should only ever have numbers; an array of objects should >> always only have objects. If a FooBar object has a "foo" member, then >> set this.foo to *something* in the constructor. >> >> It's really nice writing code in a loosely typed language. Most of >> the time, these optimizations are not all that relevant, and when they >> are, the odd exception is probably fine, if it's truly exceptional. >> But when you really care about maximizing speed, that flexibility can >> make it surprisingly tricky to track down all the deviations. >> >> I'm probably not going to stop using Vim to write code any time soon. >> I'm probably never going to use Windows as my development environment. >> Code completion sort of annoys me, and I've usually turned it off >> when I had editors that did it. But I'm actually very excited about >> TypeScript. >> >> It'd be a great idea to write up a TypeScript header file for the API >> surface in Node. Then, we could automatically test for API >> deviations, validate and flesh out our documentation, etc. Static >> typing *does* confer some very relevant value. Typically it does so >> at the cost of flexibility, but this brings a lot of the benefits to >> JavaScript in an optional way, which is very powerful. >> >> Also, it's not reinventing the language. It is JavaScript, mostly. >> Or JavaScript entirely, if you just write JS and have a separate >> declaration file, but with the benefits of linting that does more than >> whine about comma placement and indentation, and *actually finds >> subtle errors* in your programs. >> >> There have been a lot of attempts to come up with ways to add type >> hints and API-auto-documentation to JavaScript. (JSDoc, YUIDoc, >> AS3/ES4, etc.) Most of those are not very compelling. The fact that >> Microsoft is doing this, and building products on top of it (which >> they will inevitably hope to make money on), is very encouraging. It >> says to me that this is going to be a real thing with real developers >> working on it, with budgets and timelines, and the whole bit. It's >> somebody's job. >> >> >> I had some suggestions that I passed along to the folks at Microsoft: >> >> 1. It'd be *amazing* if there was a way to automatically try to guess >> at the best types, given a set of JavaScript code. Writing a >> declaration file is insanely tedious. I don't want to do it, and >> that's a blocker to adoption. I know that this is a hard problem, and >> totally not what you'd expect in a first release, but hey, V8 is >> guessing types pretty good, so it must be possible. That would make >> me happy. >> >> 2. It'd be nice (as I think someone mentioned in this thread) to let >> it put run-time type-checking into exposed functions at the API >> surface. If this needed to be a dev flag or something, then that's >> fine. I'd go ahead and let it in exported functions, though. We have >> a lot of that code in Node, and it's tedious to write and maintain. >> > > > Isaac, > > This belongs on your blog, no joke. I'm going to nag you until you do it. > > Rick > > > >> >> -- >> 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 nod...@googlegroups.com<javascript:> >> To unsubscribe from this group, send email to >> nodejs+un...@googlegroups.com <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 nod...@googlegroups.com <javascript:> > To unsubscribe from this group, send email to > nodejs+un...@googlegroups.com <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 nodejs@googlegroups.com To unsubscribe from this group, send email to nodejs+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/nodejs?hl=en?hl=en