I'm sorry I don't have Windows running to test it on. Can you write
multiple constructors/methods of varying types? How does TypeScript
translate this code to equivalent JS code?
constructor (message: string) {
this.greeting = message;
}
constructor (message: number) {
this.greeting = message;
}
If it can translate properly, this definitely looks like a big plus for
easing development in JS.
On Tue, Oct 2, 2012 at 4:40 AM, Dick Hardt <[email protected]> wrote:
> +1 to putting this on your blog Isaac.
>
> On Oct 1, 2012, at 3:50 PM, Rick Waldron <[email protected]> wrote:
>
>
>
> On Mon, Oct 1, 2012 at 6:46 PM, Isaac Schlueter <[email protected]> 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 [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
>
>
> --
> 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
