FAQ
+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 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+unsubscribe@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/nodejs?hl=en?hl=en

Search Discussions

Discussion Posts

Previous

Follow ups

Related Discussions

People

Translate

site design / logo © 2022 Grokbase