> On Mon, Oct 1, 2012 at 6:46 PM, Isaac Schlueter <i...@izs.me> 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.
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?
On Tue, Oct 2, 2012 at 4:40 AM, Dick Hardt <dick.ha...@gmail.com> wrote:
> +1 to putting this on your blog Isaac.
> On Oct 1, 2012, at 3:50 PM, Rick Waldron <waldron.r...@gmail.com> wrote:
> On Mon, Oct 1, 2012 at 6:46 PM, Isaac Schlueter <i...@izs.me> 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.
I also was hoping it could do this, but it's not a simple task if the
underlying language doesn't support it
(I wrote a Java to ActionScript converter and this is still one of the
few things I couldn't properly translate)
On Mon, Oct 1, 2012 at 7:46 PM, Shripad K <assortmentofso...@gmail.com> wrote:
> 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?
> 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 <dick.ha...@gmail.com> wrote:
>> +1 to putting this on your blog Isaac.
>> On Oct 1, 2012, at 3:50 PM, Rick Waldron <waldron.r...@gmail.com> wrote:
>> On Mon, Oct 1, 2012 at 6:46 PM, Isaac Schlueter <i...@izs.me> 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.
Okay I just tried it in the TypeScript playground. Doesn't seem like it
supports translating multiple constructors/methods. Also, support for
pre-initialization of variables before constructor is invoked would also be
a good feature. However, TypeScript is definitely a step in the right
direction. It would be cool if it could support multiple
constructors/methods. Helps in converting this code:
> 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?
> 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 <dick.ha...@gmail.com> wrote:
>> +1 to putting this on your blog Isaac.
>> On Oct 1, 2012, at 3:50 PM, Rick Waldron <waldron.r...@gmail.com> wrote:
>> On Mon, Oct 1, 2012 at 6:46 PM, Isaac Schlueter <i...@izs.me> 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.
> Okay I just tried it in the TypeScript playground. Doesn't seem like it
> supports translating multiple constructors/methods. Also, support for
> pre-initialization of variables before constructor is invoked would also be
> a good feature. However, TypeScript is definitely a step in the right
> direction. It would be cool if it could support multiple
> constructors/methods. Helps in converting this code:
> On Tue, Oct 2, 2012 at 8:16 AM, Shripad K <assortmentofso...@gmail.com>wrote:
>> 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?
>> 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 <dick.ha...@gmail.com> wrote:
>>> +1 to putting this on your blog Isaac.
>>> On Oct 1, 2012, at 3:50 PM, Rick Waldron <waldron.r...@gmail.com> wrote:
>>> On Mon, Oct 1, 2012 at 6:46 PM, Isaac Schlueter <i...@izs.me> 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.
A word about saving debugging time through statical typing: I come from java, and i can tell, that the strongly typed environment never reduced the debugging effort for me. 'use strict'-pragma, inclusive existence checking and unit-test save me from debugging not statical types. in comparison with java i save much development time with js.
plus: maintainability is a two headed beast, and it comes first through a clean code und documentation, it don't really matters which language it is.
Typescript sounds more like a me2 to me, nothing more. i wonder if it will be there in 1-3 years or even leave the .net ecosystem.
Am Montag, 1. Oktober 2012 22:50:01 UTC+2 schrieb Dick Hardt:
> On Oct 1, 2012, at 1:40 PM, José F. Romaniello <jfroma...@gmail.com<javascript:>> > wrote:
> 2012/10/1 Dick Hardt <dick....@gmail.com <javascript:>>
>> + Brings Visual Studio developers to node.js
> I was wondering about this... in the video<http://channel9.msdn.com/posts/Anders-Hejlsberg-Introducing-TypeScript> he > does a lot of emphasis in the code completion (intellisense). What is the > value of this outside Visual Studio? Why you will make your javascript > typed? just to compile it into something similar and get compiler errors?
> Many code editors do code completion -- it is a great productivity tool > for developers ramping on using modules they are not intimately familiar > with. MS made the code available which makes it easier for other editors / > IDEs to do the same.
> For less sophisticated developers (most people, and most of the VS > market), the compiler errors will remove much debugging frustration and > allow them to focus on creating rather than debugging.
> Code completion was a HUGE feature for Perl and Python developers when I > built Komodo at ActiveState.
+1. I come from .Net (I am C# MVP) and this is exactly my opinion. TDD
saves me from debugging not statical typing.
There is also another confusion I see a lot, when talking about node and
JavaScript with people that comes from .Net and Java often I heard things
like:
- "it is not self documented"
- "you dont have intellisense, how do you know how to call this api? "
- "this library uses new Thing() and this other one uses thing(), how do
you know which one"
Having intellisense and code completion is a great thing, but do the
exercise of trying to use [N]Hibernate (which is a big ORM library) without
going to the website to see the usage... Or even better try to use log4net
which is an small logging library without going to the documentation. It is
a plus but it is just not enough, and you have to pay a big price.
> A word about saving debugging time through statical typing: I come from
> java, and i can tell, that the strongly typed environment never reduced the
> debugging effort for me. 'use strict'-pragma, inclusive existence checking
> and unit-test save me from debugging not statical types. in comparison with
> java i save much development time with js.
> plus: maintainability is a two headed beast, and it comes first through a
> clean code und documentation, it don't really matters which language it is.
> Typescript sounds more like a me2 to me, nothing more. i wonder if it will
> be there in 1-3 years or even leave the .net ecosystem.
> Am Montag, 1. Oktober 2012 22:50:01 UTC+2 schrieb Dick Hardt:
>> On Oct 1, 2012, at 1:40 PM, José F. Romaniello <jfroma...@gmail.com>
>> wrote:
>> I was wondering about this... in the video<http://channel9.msdn.com/posts/Anders-Hejlsberg-Introducing-TypeScript> he
>> does a lot of emphasis in the code completion (intellisense). What is the
>> value of this outside Visual Studio? Why you will make your javascript
>> typed? just to compile it into something similar and get compiler errors?
>> Many code editors do code completion -- it is a great productivity tool
>> for developers ramping on using modules they are not intimately familiar
>> with. MS made the code available which makes it easier for other editors /
>> IDEs to do the same.
>> For less sophisticated developers (most people, and most of the VS
>> market), the compiler errors will remove much debugging frustration and
>> allow them to focus on creating rather than debugging.
>> Code completion was a HUGE feature for Perl and Python developers when I
>> built Komodo at ActiveState.
+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.
> +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> wrote:
>> On Mon, Oct 1, 2012 at 6:46 PM, Isaac Schlueter <i...@izs.me> 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.
AFAIK Sublime doesn't look all the files, it just provide code completion
for the words within the current file. I saw a while ago an extension that
did something alike but it was very slow.
*My point is* that *this* code completion is useful and it is cheap;
- I don't have to change to another language (even if is small subset of
javascript)
- I don't need Visual Studio Professional, an expensive IDE in terms of
money and in terms of resources. As my friend Gustavo said visual studio is
an IDE that can be used to handle from databases to manual tests)
- sublime is really fast at doing this
If I choose to pay this price for having a very detailed code completion
feature what's the benefit I get? And one of the things i was explaining is
that people always tell me about self documented code and in my experience
that doesn't work quite well. Try to use hibernate or log4j for the first
time without the documentation just with eclipse code completion.
> > Having intellisense and code completion is a great thing,
> Code completion works quite well in sublime text 2. It just looks at all
> your files and makes very intelligent guesses.
> On Tue, Oct 2, 2012 at 10:43 AM, Stephen Handley <
> stephen.hand...@gmail.com> wrote:
>> +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> wrote:
>>> On Mon, Oct 1, 2012 at 6:46 PM, Isaac Schlueter <i...@izs.me> 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.
On Tue, Oct 2, 2012 at 1:43 PM, Stephen Handley
<stephen.hand...@gmail.com>wrote:
> +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> wrote:
>> On Mon, Oct 1, 2012 at 6:46 PM, Isaac Schlueter <i...@izs.me> 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.
