Re: IDE support?
When you see Microsoft and Apple both spending a lot of time just to get
scrolling a list smooth and at 60fps, I assume there will always be a need
for more performance. That all applications will not require that, I can
understand it. But, again, let the developper free to decide if he need
types or not.
Let me explain something (maybe you all know it, but you just didn't notice
how important it is).
function(x) {
x.data++;
}
This code is slow by nature. Because you don't know what kind of data x
will be, you need to call ToObject before using it. Then you need to seek
throug a Dictionnary(Of String - PropertyDescriptor) to get the revelant
property. When you've found your property in the dictionnary, you can
increment its value. Even with a BTREE and optimized objects, you'll end up
by performing far more operations than just incrementing an INTEGER variable
as in C++.
However, if you had written
function(x : MyType) {
x.data++;
}
the compiler would know that the data property of a MyType instance is
stored 4 bytes after where the instance pointer is located in memory. The
compiler knows it's an integer property and it can issue very few operation
statements in native code :
LOAD *x; LOAD 4; ADD; INCREMENT-REF;
The difference between those two codes are minimal for the developer, but
they can improve the speed a lot. Optimizing RegExps, Dates, and even number
operations, all of that is fine to get a better score in the SunSpider test.
But it will never make ECMAScript a fast language. Just a less slow one.
François
-Message d'origine-
From: John J Barton
Sent: Tuesday, September 13, 2011 2:05 AM
To: François REMY
Cc: es-discuss@mozilla.org
Subject: Re: IDE support?
From: François REMY fremycompany_...@yahoo.fr
To: es-discuss@mozilla.org
Date: Mon, 12 Sep 2011 22:31:17 +0200
Subject: Re: IDE support?
Types are not only desirable to borrow concepts from current IDEs. We
know from DotNET that a language running in a VM can be pretty fast, close
to a native language. But it has to be simple for the computer. JavaScript
is simple for the developer, but sometimes its flexibility makes it
impossible to optimize code properly. And it makes JavaScript slower.
Or, to be exact, it doesn't allow to make 95% of our code faster because
it would break the other 5%. The more a compiler understand what you're
doing, the more it will be confident that optimizing is safe. Types may be
part of the data a compiler may use. It doesn't need to be the only one,
but it can be a very important one.
Ah, but let's be exact then: what proportion of most Web applications
will benefit from type-based performance improvements?
The reason I ask is that the diagrams that Wes posted show two things.
One is obvious: the dramatic improvement in JS. Yay! Congrats to all
involved!
The other is less obvious: further improvements in JS performance are
less and less important. Not unimportant and not insignficant.
Just less important because the total performance depends on many
factors of which JS -- for most pages most of the time -- may no
longer be the critical factor. And even when JS is important,
type-based improvements will only be a small factor really. In the big
picture, such a fundamental change may not be very valuable.
Of course I am guessing, and having real performance analysis numbers
would be excellent information.
jjb
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: IDE support?
On Sep 12, 2011, at 12:22 PM, John J Barton wrote: On Mon, Sep 12, 2011 at 12:00 PM, es-discuss-requ...@mozilla.org wrote: Some of the discussion on this thread amounts to IDEs work great for typed languages so let's make JS typed. What if we started with What would be great for JavaScript developers? Then we would not waste a lot of time talking about static analysis. It's the wrong tool. Why are you assuming that conclusion already? Why not answer your own question What would be great for JavaScript developers? and if the answer includes type inference, great? /be ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: IDE support?
On Sep 12, 2011, at 12:35 PM, Mikeal Rogers wrote: I was super confused as to why good tools and IDEs would require typing. A bunch of typed languages do have great IDEs but I feel like that's mainly because programming in a typed language can be considerably more difficult which puts more emphasis on creating great tools to help deal with it. Could be, although a lot of the IntelliJ fans talk not about types per se, but about knowing what member names mean, e.g., which concrete method implementations might obj.foo() actually call? That uses type declarations, for sure, but it need not. This reminds me of the ES4 discussion around typing being a requirement of making the language more performant, that clearly wasn't true. That was an AS3 claim, not an ES4 discussion. I explicitly disavowed it during ES4 days here: http://brendaneich.com/2007/11/my-media-ajax-keynote/ I'm going to throw out a crazy idea. Maybe the language is fine in this regard and creating better tools is done by *creating better tools*, not by changing the language. Maybe changing the language has a negative effect on creating better tools because it increases the surface area and complexity those tools need have to solve. +1 I'm not saying changing the language is universally bad, only that some problems are better solved outside of ECMA and that there is a big community out here that is working to solve this problem and they don't need anything from ECMA to do it. Tools can do all sorts of amazing things with JS source: semi-static analysis, dynamic inspection of the live object graph and active code, combinations and variations. Tools don't have to run super-fast to avoid regressing benchmarks. We're early in JS tool evolution, we should not hack up the language prematurely -- your point is on target. /be ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: IDE support?
On Sep 12, 2011, at 11:58 PM, François REMY wrote:
Let me explain something (maybe you all know it, but you just didn't notice
how important it is).
function(x) {
x.data++;
}
This code is slow by nature. Because you don't know what kind of data x
will be, you need to call ToObject before using it. Then you need to seek
throug a Dictionnary(Of String - PropertyDescriptor) to get the revelant
property. When you've found your property in the dictionnary, you can
increment its value. Even with a BTREE and optimized objects, you'll end up
by performing far more operations than just incrementing an INTEGER variable
as in C++.
However, if you had written
function(x : MyType) {
x.data++;
}
the compiler would know that the data property of a MyType instance is
stored 4 bytes after where the instance pointer is located in memory. The
compiler knows it's an integer property and it can issue very few operation
statements in native code :
LOAD *x; LOAD 4; ADD; INCREMENT-REF;
The difference between those two codes are minimal for the developer, but
they can improve the speed a lot. Optimizing RegExps, Dates, and even number
operations, all of that is fine to get a better score in the SunSpider test.
But it will never make ECMAScript a fast language. Just a less slow one.
You are simply way out of date on JS optimizing VMs, which (based on work done
with Self and Smalltalk) all now use hidden classes aka shapes and
polymorphic inline caching to optimize to exactly the pseudo-assembly you show,
prefixed by a short (cheap if mispredicted) branch.
What's more, SpiderMonkey bleeding edge does semi-static type inference, which
can eliminate the guard branch.
Please don't keep repeating out of date information about having to seek
through a dictionary. It simply isn't true.
/be
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: IDE support?
Okay, maybe you don't have to seek throug a dictionnary anymore. But still,
the performance overhead is higher than you would want to. Because it's
possible to achieve no overhead, even a small overhead is an overhead to be
deleted. The fastest code is the code you don't have to execute.
A compiler may be very dumb, if I say something is true, he know it's true.
On the other side, a compiler can be as smart as you want, there are things
he'll never be able to guess.
And even if the compiler is able to guess (and makes things faster using
hidden classes and all other stuff modern VM implemented), it will take CPU
time to guess things I already knew at the moment where I started writing my
code. And each time my script will run, the browser will need to figure some
stuff out. What a waste of energy, in a world where power efficiency is key.
-Message d'origine-
From: Brendan Eich
Sent: Tuesday, September 13, 2011 9:33 AM
To: François REMY
Cc: John J Barton ; es-discuss@mozilla.org
Subject: Re: IDE support?
On Sep 12, 2011, at 11:58 PM, François REMY wrote:
Let me explain something (maybe you all know it, but you just didn't
notice how important it is).
function(x) {
x.data++;
}
This code is slow by nature. Because you don't know what kind of data x
will be, you need to call ToObject before using it. Then you need to
seek throug a Dictionnary(Of String - PropertyDescriptor) to get the
revelant property. When you've found your property in the dictionnary, you
can increment its value. Even with a BTREE and optimized objects, you'll
end up by performing far more operations than just incrementing an INTEGER
variable as in C++.
However, if you had written
function(x : MyType) {
x.data++;
}
the compiler would know that the data property of a MyType instance is
stored 4 bytes after where the instance pointer is located in memory. The
compiler knows it's an integer property and it can issue very few
operation statements in native code :
LOAD *x; LOAD 4; ADD; INCREMENT-REF;
The difference between those two codes are minimal for the developer, but
they can improve the speed a lot. Optimizing RegExps, Dates, and even
number operations, all of that is fine to get a better score in the
SunSpider test. But it will never make ECMAScript a fast language. Just
a less slow one.
You are simply way out of date on JS optimizing VMs, which (based on work
done with Self and Smalltalk) all now use hidden classes aka shapes and
polymorphic inline caching to optimize to exactly the pseudo-assembly you
show, prefixed by a short (cheap if mispredicted) branch.
What's more, SpiderMonkey bleeding edge does semi-static type inference,
which can eliminate the guard branch.
Please don't keep repeating out of date information about having to seek
through a dictionary. It simply isn't true.
/be
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: IDE support?
There are some half dozen or more papers on Javascript type inference or static analysis (hmm, is there a central wiki or bibliography where we could record and collect such JS-related references? should I post here what I've found so far?). For as far as you haven't already, I'd love to see more of them. Ok, here are some I've found so far (more than I remembered:-). I've tried to add urls, but haven't checked those: TAJS: Type Analyzer for JavaScript http://www.brics.dk/TAJS/ Modeling the HTML DOM and Browser API in Static Analysis of JavaScript Web Applications Jensen, Madsen, Møller, 2011 http://cs.au.dk/~amoeller/papers/dom/ Interprocedural Analysis with Lazy Propagation Jensen, Møller, Thiemann, 2010 http://users-cs.au.dk/amoeller/papers/lazy/ Type Analysis for JavaScript Jensen, Møller, Thiemann, 2009 http://users-cs.au.dk/amoeller/papers/tajs/ Recency Types for Analyzing Scripting Languages Heidegger, Thiemann, 2010 https://proglang.informatik.uni-freiburg.de/JavaScript/recency.pdf Towards a Type System for Analyzing JavaScript Programs Thiemann, 2005 https://mailserver.di.unipi.it/ricerca/proceedings/ETAPS05/papers/3444/34440408.pdf Type Inference for JavaScript Anderson, 2006 http://pubs.doc.ic.ac.uk/chrisandersonphd/ Towards Type Inference for JavaScript Anderson, Giannini, Drossopoulou, 2005 http://pubs.doc.ic.ac.uk/typeinferenceforjavascript-ecoop/ Staged Information Flow for JavaScript Chugh, Meister, Jhala, Lerner, 2009 http://goto.ucsd.edu/~rjhala/papers/staged_information_flow_for_javascript.html An Empirical Study of Privacy-Violating Information Flows in JavaScript Web Applications Jang, Jhala, Lerner, Shacham, 2010 http://goto.ucsd.edu/~rjhala/papers/an_empirical_study_of_privacy_violating_flows_in_javascript_web_applications.html CFA2: a Context-Free Approach to Control-Flow Analysis Vardoulakis, Shivers, 2010 (used in DoctorJS) http://www.ccs.neu.edu/home/dimvar/papers/cfa2-NU-CCIS-10-01.pdf Gulfstream: Incremental Static Analysis for Streaming JavaScript Applications Livshits, Guarnieri, 2010 http://research.microsoft.com/pubs/118310/paper.pdf GATEKEEPER: Mostly Static Enforcement of Security and Reliability Policies for JavaScript Code Guarnieri, Livshits, 2009 http://research.microsoft.com/en-us/um/people/livshits/papers/pdf/usenixsec09a.pdf JSTrace: Run-time Type Discovery for JavaScript Saftoiu, 2010 http://www.cs.brown.edu/research/pubs/theses/ugrad/2010/saftoiu.pdf Polymorphic Type Inference for Scripting Languages with Object Extensions Zhao, 2011 http://jiangxi.cs.uwm.edu/publication/dls2011.pdf RATA: Rapid Atomic Type Analysis by Abstract Interpretation. Application to JavaScript optimization. Logozzo, Venter, http://research.microsoft.com/pubs/115734/aitypes.pdf An Analytic Framework for JavaScript van Horn, Might, 2011 http://www.ccs.neu.edu/home/dvanhorn/pubs/vanhorn-might-preprint11.pdf Points-to Analysis for JavaScript Dongseok Jang, Kwang-Moo Choe, 2009 http://cseweb.ucsd.edu/~d1jang/papers/sac09.pdf Language-Based Isolation of Untrusted JavaScript Sergio Maffeis, Mitchell, Taly, 2009 http://www.stanford.edu/~jcm/papers/csf09-techrep.pdf An Operational Semantics for JavaScript Maffeis, Mitchell, Taly, 2008 http://www.stanford.edu/~jcm/papers/aplas08-camera-ready.pdf The Essence of JavaScript Guha, Saftoiu, Krishnamurthi, 2010 http://www.cs.brown.edu/research/plt/dl/jssem/v1/gsk-essence-javascript-r5.pdf Using Static Analysis for Ajax Intrusion Detection Guha, Krishnamurthi, Jim, 2009 http://sca2002.cs.brown.edu/people/arjun/public/intrusion-detection.pdf Typing Local Control and State using Flow Analysis Guha, Saftoiu, Krishnamurthi, 2011 http://www.cs.brown.edu/~sk/Publications/Papers/Published/gsk-flow-typing-theory/paper.pdf JavaScript Instrumentation for Browser Security Yu, Chander, Islam, Serikov, 2007 http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.89.183rep=rep1type=pdf Automated Analysis of Security-Critical JavaScript APIs Taly, Erlingsson, Mitchell, Miller, Nagra, 2011 http://theory.stanford.edu/~ataly/Papers/sp11.pdf Trace-based Just-in-Time Type Specialization for Dynamic Languages Gal et. al., 2009 http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.148.349rep=rep1type=pdf Also useful for setting the stage are general studies like: The Eval that Men Do A Large-scale Study of the Use of Eval in JavaScript Applications Richards, Hammer, Burg, Vitek, 2011 http://www.cs.washington.edu/homes/burg/files/eval-ecoop-2011-paper.pdf An Analysis of the Dynamic Behavior of JavaScript Programs Richards, Lebresne, Burg, Vitek, 2010 http://www.cs.washington.edu/homes/burg/files/dynjs-pldi-2010-paper.pdf Not
Re: IDE support?
Improved, statically checkable, types would also help mitigate Javascript's silent failures (silently breaking code when trying to refactor, fixing bugs, or adding features). Unless the type system is fairly advanced, type safety only expresses a thin veneer of invariants, but coverage is total, and automatic. I'm sorry, but as much as I want a type system, the idea of a thin veneer that imposes an ongoing tax at *all* declaration and usage sites is really distasteful. JS should do better than Java and it's ilk have managed. Why are you trying to misinterpret me? My inspiration for a useful type system would be Haskell (certainly not Java), and it is likely that any JS type system will be less advanced. So it will be able to express fewer program properties, hence only replace a weak/thin level of testing. But if done right, that level of testing will still cover the whole program, without coders having to include needless declarations, because type inference will connect the dots. That also answers another common objection: useful type systems do not render testing superfluous, but they allow test suites to focus on more interesting aspects of your code, because the basics are covered by the type system (and that coverage includes source and path coverage). Claus http://clausreinke.github.com/ ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: IDE support?
On Sep/12/2011 22:19, Rick Waldron wrote: On Mon, Sep 12, 2011 at 11:38 AM, Claus Reinke claus.rei...@talk21.com mailto:claus.rei...@talk21.com wrote: I'm hopeful that type inference combined with class syntax and an (eventual) traits system will get us there, so that you can use structural type tests for enforcement and that the IDE can get the benefit of hints through inference. Improved, statically checkable, types would also help mitigate Javascript's silent failures (silently breaking code when trying to refactor, fixing bugs, or adding features). Unit tests with comprehensive and thorough code coverage does this today. Sure. The question is why should we do it if a machine can do it? That would mean we can concentrate on writing business logic tests instead of tests that verify type matches. -- Ionuț G. Stan | http://igstan.ro ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: IDE support?
For features such as expansion help (e.g. when you type a dot after a parameter name inside a function), you still need static analysis. But your point stands: JS IDEs can and should go beyond “edit-compile-debug” (which has become so mainstream that many people forget about languages such as Common Lisp and Smalltalk). On Sep 13, 2011, at 6:44 , Breton Slivka wrote: Forgive me if this has already been talked about, but is it possible that trying to improve static analysis of javascript is barking up the wrong tree? I think a better approach is to write your IDE in javascript and have it running inside a context that has access to the running JS environment. Think about the precedents set by Smalltalk and Self, and even Forth, with hints of this happening in the modern browser debugger environments which now have some rudimentary code completion features. A JS IDE should be a running environment that can reflect on changes to the environment dynamically and save them back out to your source files, via some diff like protocol which can be rather straightforwardly implemented with proxies, akin to how a self program was essentially an in memory image core dump. Having your IDE hooked up to a running JS context gets around a lot of your problems with static analysis, including even dealing with dynamic property access, dynamically constructed objects, prototype chains and inheritences, and function name aliases. -- Dr. Axel Rauschmayer a...@rauschma.de twitter.com/rauschma home: rauschma.de blog: 2ality.com ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: IDE support?
On 13 September 2011 09:33, Brendan Eich bren...@mozilla.com wrote: You are simply way out of date on JS optimizing VMs, which (based on work done with Self and Smalltalk) all now use hidden classes aka shapes and polymorphic inline caching to optimize to exactly the pseudo-assembly you show, prefixed by a short (cheap if mispredicted) branch. What's more, SpiderMonkey bleeding edge does semi-static type inference, which can eliminate the guard branch. Please don't keep repeating out of date information about having to seek through a dictionary. It simply isn't true. True. On the other hand, all the cleverness in today's JS VMs neither comes for free, nor can it ever reach the full performance of a typed language. * There are extra costs in space and time to doing the runtime analysis. * Compile time is runtime, so there are severe limits to how smart you can afford to get in a compiler. * A big problem is predictability, it is a black art to get the best performance out of contemporary JS VMs. * The massive complexity that comes with implementing all this affects stability. * Wrt limits, even in the ideal case, you can only approximate the performance of typed code -- e.g. for property access you have at least two memory accesses (type and slot) plus a comparison and branch, where a typed language would only do 1 memory access. * Type inference might mitigate some more of these cases, but will be limited to fairly local knowledge. * Omnipresent mutability is another big performance problem in itself, because most knowledge is never stable. So despite all the cool technology we use these days, it is safe to assume that we will never play in the performance league of typed languages. Unless we introduce real types into JS, of course. :) /Andreas ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: IDE support?
On Sep 13, 2011, at 5:33 AM, Andreas Rossberg wrote: On 13 September 2011 09:33, Brendan Eich bren...@mozilla.com wrote: You are simply way out of date on JS optimizing VMs, which (based on work done with Self and Smalltalk) all now use hidden classes aka shapes and polymorphic inline caching to optimize to exactly the pseudo-assembly you show, prefixed by a short (cheap if mispredicted) branch. What's more, SpiderMonkey bleeding edge does semi-static type inference, which can eliminate the guard branch. Please don't keep repeating out of date information about having to seek through a dictionary. It simply isn't true. True. On the other hand, all the cleverness in today's JS VMs neither comes for free, nor can it ever reach the full performance of a typed language. The AS3 = ES4 argument for optional types. Been there, done that. * There are extra costs in space and time to doing the runtime analysis. * Compile time is runtime, so there are severe limits to how smart you can afford to get in a compiler. These are bearable apples to trade against the moldy oranges you'd make the world eat by introducing type annotations to JS. Millions of programmers would start annotating for performance, i.e., gratuitously, making a brittle world at high aggregate cost. The costs born in browsers by implementors and (this can hit users, but it's marginal) at runtime when evaluating code are less, I claim. * A big problem is predictability, it is a black art to get the best performance out of contemporary JS VMs. This is the big one in my book. Optimization faults happen. But can we iterate till flat? * The massive complexity that comes with implementing all this affects stability. This one I'm less sympathetic to, since we won't get rid of untyped JS up front. A sunk cost fallacy? If we could make a clean break (ahem), sure. Otherwise this cost must be paid. * Wrt limits, even in the ideal case, you can only approximate the performance of typed code -- e.g. for property access you have at least two memory accesses (type and slot) plus a comparison and branch, where a typed language would only do 1 memory access. That's *not* the ideal case. Brian Hackett's type inference work in SpiderMonkey can eliminate the overhead here. Check it out. * Type inference might mitigate some more of these cases, but will be limited to fairly local knowledge. s/might/does/ -- why did you put type inference in a subjunctive mood? Type inference in SpiderMonkey (Firefox nightlies) is not local. * Omnipresent mutability is another big performance problem in itself, because most knowledge is never stable. Type annotations or (let's say) guards as for-all-time monotonic bounds on mutation are useful to programmers too, for more robust programming-in-the-large. That's a separate (and better IMHO) argument than performance. It's why they are on the Harmony agenda. So despite all the cool technology we use these days, it is safe to assume that we will never play in the performance league of typed languages. Unless we introduce real types into JS, of course. :) Does JS need to be as fast as Java? Would half as fast be enough? /be ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: IDE support?
Speaking pragmatically, for myself and my unusual (server-side) environment: On 13 September 2011 10:48, Brendan Eich bren...@mozilla.com wrote: Does JS need to be as fast as Java? Would half as fast be enough? If it's compute-bound then that's plenty. Provided we develop so that we can scale across cores, I can double my compute this month for about the same dollar cost as 0.1% programmer-time. My estimate is that type annotations would be far more expensive; as we don't generally have type-related bugs in our JS code, spending time annotating only for the sake of execution speed would be a poor decision. Wes -- Wesley W. Garland Director, Product Development PageMail, Inc. +1 613 542 2787 x 102 ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: IDE support?
On Tue, Sep 13, 2011 at 12:26 AM, Brendan Eich bren...@mozilla.com wrote: On Sep 12, 2011, at 12:22 PM, John J Barton wrote: On Mon, Sep 12, 2011 at 12:00 PM, es-discuss-requ...@mozilla.org wrote: Some of the discussion on this thread amounts to IDEs work great for typed languages so let's make JS typed. What if we started with What would be great for JavaScript developers? Then we would not waste a lot of time talking about static analysis. It's the wrong tool. Why are you assuming that conclusion already? Why not answer your own question What would be great for JavaScript developers? and if the answer includes type inference, great? I'm assuming that conclusion already because the current tools for JS development are so incredibly lame that wasting time on static analysis -- which we know does not work without changing the language -- defies common sense. jjb /be ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: IDE support?
On Tue, Sep 13, 2011 at 12:03 PM, John J Barton johnjbar...@johnjbarton.com wrote: On Tue, Sep 13, 2011 at 12:26 AM, Brendan Eich bren...@mozilla.com wrote: On Sep 12, 2011, at 12:22 PM, John J Barton wrote: On Mon, Sep 12, 2011 at 12:00 PM, es-discuss-requ...@mozilla.org wrote: Some of the discussion on this thread amounts to IDEs work great for typed languages so let's make JS typed. What if we started with What would be great for JavaScript developers? Then we would not waste a lot of time talking about static analysis. It's the wrong tool. Why are you assuming that conclusion already? Why not answer your own question What would be great for JavaScript developers? and if the answer includes type inference, great? I'm assuming that conclusion already because the current tools for JS development are so incredibly lame that wasting time on static analysis -- which we know does not work without changing the language -- defies common sense. I think you may be a little confused. Type inference means inferring types without annotations. Thus, it can be done without changing the language and can be useful for vm implementers and tool developers alike. Today. Sounds pretty common-sensical to me. ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: IDE support?
On Sep 13, 2011, at 9:03 AM, John J Barton wrote: On Tue, Sep 13, 2011 at 12:26 AM, Brendan Eich bren...@mozilla.com wrote: On Sep 12, 2011, at 12:22 PM, John J Barton wrote: On Mon, Sep 12, 2011 at 12:00 PM, es-discuss-requ...@mozilla.org wrote: Some of the discussion on this thread amounts to IDEs work great for typed languages so let's make JS typed. What if we started with What would be great for JavaScript developers? Then we would not waste a lot of time talking about static analysis. It's the wrong tool. Why are you assuming that conclusion already? Why not answer your own question What would be great for JavaScript developers? and if the answer includes type inference, great? I'm assuming that conclusion already because the current tools for JS development are so incredibly lame that wasting time on static analysis -- which we know does not work without changing the language Ok, your assumed conclusion rests on a prior assumption: static analysis ... we know does not work without changing the language Evidence? It seems to me you have not studied either http://doctorjs.org, which is nodejs based, the code is on github (it's all JS, essentially a fork of narcissus via Patrick Walton's jsctags): https://github.com/mozilla/doctorjs or Brian Hackett's work in SpiderMonkey (Patrick Walton made a JS version of it, should be easier to study: https://github.com/pcwalton/doctorjsmm Really, asserting an assumption to back up an assumed conclusion? /be ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: IDE support?
I'm assuming that conclusion already because the current tools for JS development are so incredibly lame that wasting time on static analysis -- which we know does not work without changing the language Ok, your assumed conclusion rests on a prior assumption: static analysis ... we know does not work without changing the language Evidence? It seems to me you have not studied either http://doctorjs.org, which is nodejs based, the code is on github (it's all JS, essentially a fork of narcissus via Patrick Walton's jsctags): https://github.com/mozilla/doctorjs Or just do some live coding at http://zeonjs.com - peter ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: IDE support?
On Sep 13, 2011, at 1:02 AM, François REMY wrote: Okay, maybe you don't have to seek throug a dictionnary anymore. But still, the performance overhead is higher than you would want to. Because it's possible to achieve no overhead, even a small overhead is an overhead to be deleted. The fastest code is the code you don't have to execute. You're right, small constant factors and terms matter asymptotically. More apples-to-oranges, but we have to weigh and decide: JS programmer productivity is not clearly helped by adding type annotations. We worked through a number of scenarios for ES4: * Typed code calling untyped code: dynamic barriers required to enforce invariants, this'll cost. * Untyped code calling typed code: spot-checks (remember like) or barriers required, ditto. * The easy one, typed calling typed, but then you've probably harmed productivity by over-annotating. The gravity well is steep. AS3 went far down it and its users over-annotated. Different economics and tooling on the web, so maybe we'll be luckier -- or perhaps an attempt to sell optional type annotations will simply fail to close -- no widespread adoption. This all assumes we have a sound optional type system. We never had one for ES4. It's a research area. TC39 is not doing research, remember? A compiler may be very dumb, if I say something is true, he know it's true. On the other side, a compiler can be as smart as you want, there are things he'll never be able to guess. Yes, but does JS need to run almost as fast as C? BTW, for well-behaved benchmarks using typed arrays, our tracing JIT does run about as fast as C. So really, you have to stipulate workload. For all workloads, must JS run almost as fast as C? No way! /be ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: IDE support?
Great post, Allen! On 13 September 2011 15:01, Allen Wirfs-Brock al...@wirfs-brock.com wrote: We need to do the same thing with our JS tools. All of the great dynamic language IDEs (that, BTW, preceded and largely inspired the modern static language IDEs) were live environments. They didn't just provide a live debugging experience, it was a live authoring experience. You developed code as a dynamic running program. They truly support incremental, interactive development. Developers operate in a continuous write a little/run a little cycle. The tools use information obtained from an actual running program to provide a great developer experience. This reminds of one of my constant modern-day-language laments...no development-time interactivity. I cut my very first programming teeth during the 8-bit microcomputer era, and learned a wide variety of BASICs (Sinclair, Commodore, AppleSoft, Atari, GW-). A few years on and I'd moved to environments like Logo, Quick Basic 4.5 (not Visual Basic), before heading for less dynamic (but faster) pastures. I've spent time with unusual IDEs like Garry Kitchen's Game Maker, Opcode's MAX, and ControllerMate IV. All of these environments -- even if the languages themselves were awful -- had one thing in common which I love: you just type stuff in, and it goes. You can try a hundred solutions as fast as you can google for one. You get to explore the machine. You learn by doing. These are great traits, and one of the reasons I love JS is that I believe I can recapture some of that ... agility ... that has been eroded over the years. When I write shell programs, and JS programs, I keep an extra terminal window open to a spare shell or a JS REPL. I try stuff. Stuff that works, I copy into my program. Then I run my program - which happens quickly, because the compiler is super-fast and the program is a contained entity which probably runs in a dynamically configured environment. I'm a *highly *productive shell programmer, and a very productive JS programmer. I spent more than a decade full time hacking C, and I frequently write JS programs which are superior to equivalent C programs, even when they are both manipulating the same underlying OS calls, because I can test my JS incrementally (not to mention prototypal inheritance, superior flow control,etc). So, even though C is absolutely my forte, I prefer to hack in JS these days because I am so much more productive. That increase in productivity is due in no small part to the dynamic language development experience you mentioned above and I believe we have only barely scratched the surface. I can't wait to see what improvements will be brought to the ECMAScript IDE in the next few years. Wes -- Wesley W. Garland Director, Product Development PageMail, Inc. +1 613 542 2787 x 102 ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: IDE support?
Just to respond to this, JavaScript is one of my favorite language. I like it. I like the fact I’ve a freedom hardly comparable to anything else. But it’s not because we’ll have the possibility to use static types where it’s really useful we’ll lose the hability to continue our work as we do today. It’s just one more tool in your toolbox. Not a complete language change. From: Allen Wirfs-Brock Sent: Tuesday, September 13, 2011 9:01 PM To: Axel Rauschmayer Cc: es-discuss ; Breton Slivka Subject: Re: IDE support? There are key points in Breton's post below that should not be lost in a debate on whether or not dynamic JS performance can or can not asymptotically approach that of a hypothetical class-based statically typed language (something that you might call simply J). Success with a dynamic language languages requires understanding that they are different beasts than statically typed languages. Great performance and great development tools for them is not achieved by trying to treat them like a poorly designed or ill behaved statically typed language. The recently successful JS engine implementors already knew or ultimately learned this and we have really turned the corner on JS performance (now if they can just get their acts together WRT garbage collection...). We need to do the same thing with our JS tools. All of the great dynamic language IDEs (that, BTW, preceded and largely inspired the modern static language IDEs) were live environments. They didn't just provide a live debugging experience, it was a live authoring experience. You developed code as a dynamic running program. They truly support incremental, interactive development. Developers operate in a continuous write a little/run a little cycle. The tools use information obtained from an actual running program to provide a great developer experience. Regarding Axel's case of dot completion. In a real live development experience you would probably be writing that code within the context of a a function call that is suspended because the function doesn't actually exist yet or its body has not been filled in. As you write that code the tools have visibility of the actual arguments that were passed to the suspended call as one of the sources of information for suggesting dot completions. It is probably also worth noting that the language engines the successful live dynamic language environments were built upon were engineered all the way down to their lowest levels to support the dynamic program modification capabilities needed to support their live developer experience. In many cases it makes sense to algorithms around immutable immutable objects but such objects sill need to be mutable by the tools of a live development environment. Another difference is that static language IDEs generally try to provide perfect information. If one provides a dot completion list then the expectation is that the list is contextually exhaustive and accurate. These and only these names can be used after this dot. A dynamic language tools would offer an advisory list. Here are some names that based upon the tools current understanding of the program are likely to be meaningful after this dot. Static tools operate under the illusion that programs are a fixed and closed world that can be perfectly understood. Some people would say that such programs tend to be fragile in the face of change. Dynamic language tools work in a world where programs are malleable and continually evolving. Which is a closer reflection of the actual web? To do great things with a language you have to love the language. The great JS development experiences of the future will be built by a new generation of JS lovers who aren't constrained by static language notions of how development tools need to work. Allen On Sep 13, 2011, at 4:49 AM, Axel Rauschmayer wrote: For features such as expansion help (e.g. when you type a dot after a parameter name inside a function), you still need static analysis. But your point stands: JS IDEs can and should go beyond “edit-compile-debug” (which has become so mainstream that many people forget about languages such as Common Lisp and Smalltalk). On Sep 13, 2011, at 6:44 , Breton Slivka wrote: Forgive me if this has already been talked about, but is it possible that trying to improve static analysis of javascript is barking up the wrong tree? I think a better approach is to write your IDE in javascript and have it running inside a context that has access to the running JS environment. Think about the precedents set by Smalltalk and Self, and even Forth, with hints of this happening in the modern browser debugger environments which now have some rudimentary code completion features. A JS IDE should be a running environment that can reflect on changes to the environment dynamically and save them back out to your source
Re: IDE support?
Well, you're right to point the difficulty encountered while stepping in and out of a typed environment. I know I'm fairly limited in my understanding of JavaScript VMs because they've become both wonderful and very complex tools at the same time, but I've got the chance to understand pretty deeply the .NET CLR. In fact, when you use the Object type for a parameter, you must know that sending an integer or a boolean to the fuction will require something called boxing (I think it's the kind of problem you rose in your mail). It's true that it's rather uncommon in .NET since nearly everything is strongly typed. But it comes at a cost, I understand it. Depending on the cost of boxing and unboxing, it may be a worse overhead than the initial one (the one where nothing would be typed). But, well, this problem has to be taken in account in the current implementation of ECMAScript, right? Since you can call methods on integers or booleans, there must be some kind of Boxing involved somewhere. Anyway, I feel like annotating is needed, somewhere. For exemple, Visual Studio does know that the return value of document.getElementById is a HTMLElement. Since he doesn't have access to the browser own code, it must be hard-coded somewhere. It's the same for framework functions. You don't want your IDE to analyse the whole jQuery framework each time you use it. If it has simple annotation on its functions return values and parameters, this task can be done when needed and very quickly. Almost chirugically. An exemple : in VB.NET, if you have a function taking an Enum as a parameter, the Intellisense will provide you as options the flag names defined in the enum. But in your code, you may want to treat the value as an int and there's no way, from the code, to guess it's coming form an enum if it wasn't stated in the parameter type. So, yes, annotating types can help a lot. Inference can do a lot, too. I almost never specify the types of my variables and my lambda's parameters, to quote a few. From the informations gathered from a small amount of annotation, the compiler can guess those things for me, right when I'm typing the code. If I make changes to my program, it will be able to update the type inference and check incompatibilities. All this was a pain when type inference was not enabled. Static typing, type inferfence and virtual execution are both very useful tools, and each of them solves almost the same problem. But each of them has case it solves pretty well and others it don't. Making them working together is the dream we should have. Actually, working together is the motto of the web as a whole... -Message d'origine- From: Brendan Eich Sent: Tuesday, September 13, 2011 9:11 PM To: François REMY Cc: John J Barton ; es-discuss@mozilla.org Subject: Re: IDE support? On Sep 13, 2011, at 1:02 AM, François REMY wrote: Okay, maybe you don't have to seek throug a dictionnary anymore. But still, the performance overhead is higher than you would want to. Because it's possible to achieve no overhead, even a small overhead is an overhead to be deleted. The fastest code is the code you don't have to execute. You're right, small constant factors and terms matter asymptotically. More apples-to-oranges, but we have to weigh and decide: JS programmer productivity is not clearly helped by adding type annotations. We worked through a number of scenarios for ES4: * Typed code calling untyped code: dynamic barriers required to enforce invariants, this'll cost. * Untyped code calling typed code: spot-checks (remember like) or barriers required, ditto. * The easy one, typed calling typed, but then you've probably harmed productivity by over-annotating. The gravity well is steep. AS3 went far down it and its users over-annotated. Different economics and tooling on the web, so maybe we'll be luckier -- or perhaps an attempt to sell optional type annotations will simply fail to close -- no widespread adoption. This all assumes we have a sound optional type system. We never had one for ES4. It's a research area. TC39 is not doing research, remember? A compiler may be very dumb, if I say something is true, he know it's true. On the other side, a compiler can be as smart as you want, there are things he'll never be able to guess. Yes, but does JS need to run almost as fast as C? BTW, for well-behaved benchmarks using typed arrays, our tracing JIT does run about as fast as C. So really, you have to stipulate workload. For all workloads, must JS run almost as fast as C? No way! /be= ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: IDE support?
Just to point out that Web Inspector in the Chrome browser has run time dot completions (as does Firebug) and it has live JS and CSS editing with save to file. I won't defend the user experience, that needs work. I tried and failed to convince one IDE team that starting from the runtime tools was the short path to better Web dev. jjb On Tue, Sep 13, 2011 at 12:01 PM, Allen Wirfs-Brock al...@wirfs-brock.com wrote: There are key points in Breton's post below that should not be lost in a debate on whether or not dynamic JS performance can or can not asymptotically approach that of a hypothetical class-based statically typed language (something that you might call simply J). Success with a dynamic language languages requires understanding that they are different beasts than statically typed languages. Great performance and great development tools for them is not achieved by trying to treat them like a poorly designed or ill behaved statically typed language. The recently successful JS engine implementors already knew or ultimately learned this and we have really turned the corner on JS performance (now if they can just get their acts together WRT garbage collection...). We need to do the same thing with our JS tools. All of the great dynamic language IDEs (that, BTW, preceded and largely inspired the modern static language IDEs) were live environments. They didn't just provide a live debugging experience, it was a live authoring experience. You developed code as a dynamic running program. They truly support incremental, interactive development. Developers operate in a continuous write a little/run a little cycle. The tools use information obtained from an actual running program to provide a great developer experience. Regarding Axel's case of dot completion. In a real live development experience you would probably be writing that code within the context of a a function call that is suspended because the function doesn't actually exist yet or its body has not been filled in. As you write that code the tools have visibility of the actual arguments that were passed to the suspended call as one of the sources of information for suggesting dot completions. It is probably also worth noting that the language engines the successful live dynamic language environments were built upon were engineered all the way down to their lowest levels to support the dynamic program modification capabilities needed to support their live developer experience. In many cases it makes sense to algorithms around immutable immutable objects but such objects sill need to be mutable by the tools of a live development environment. Another difference is that static language IDEs generally try to provide perfect information. If one provides a dot completion list then the expectation is that the list is contextually exhaustive and accurate. These and only these names can be used after this dot. A dynamic language tools would offer an advisory list. Here are some names that based upon the tools current understanding of the program are likely to be meaningful after this dot. Static tools operate under the illusion that programs are a fixed and closed world that can be perfectly understood. Some people would say that such programs tend to be fragile in the face of change. Dynamic language tools work in a world where programs are malleable and continually evolving. Which is a closer reflection of the actual web? To do great things with a language you have to love the language. The great JS development experiences of the future will be built by a new generation of JS lovers who aren't constrained by static language notions of how development tools need to work. Allen On Sep 13, 2011, at 4:49 AM, Axel Rauschmayer wrote: For features such as expansion help (e.g. when you type a dot after a parameter name inside a function), you still need static analysis. But your point stands: JS IDEs can and should go beyond “edit-compile-debug” (which has become so mainstream that many people forget about languages such as Common Lisp and Smalltalk). On Sep 13, 2011, at 6:44 , Breton Slivka wrote: Forgive me if this has already been talked about, but is it possible that trying to improve static analysis of javascript is barking up the wrong tree? I think a better approach is to write your IDE in javascript and have it running inside a context that has access to the running JS environment. Think about the precedents set by Smalltalk and Self, and even Forth, with hints of this happening in the modern browser debugger environments which now have some rudimentary code completion features. A JS IDE should be a running environment that can reflect on changes to the environment dynamically and save them back out to your source files, via some diff like protocol which can be rather straightforwardly implemented with proxies, akin to how a self program was essentially
Re: IDE support?
On Sep 13, 2011, at 12:26 AM, Brendan Eich wrote: On Sep 12, 2011, at 12:22 PM, John J Barton wrote: On Mon, Sep 12, 2011 at 12:00 PM, es-discuss-requ...@mozilla.org wrote: Some of the discussion on this thread amounts to IDEs work great for typed languages so let's make JS typed. What if we started with What would be great for JavaScript developers? Then we would not waste a lot of time talking about static analysis. It's the wrong tool. Why are you assuming that conclusion already? Why not answer your own question What would be great for JavaScript developers? and if the answer includes type inference, great? John and I corresponded privately and we agreed that static is less than static+dynamic. That is something I tend to ass-ume, being an implementor (SpiderMonkey does analysis when compiling, and of course lots of runtime feedback-based code generation). So, static+dynamic. The static side has some powerful algorithms to bring to bear. Dynamic is necessary due to eval and kin, and gives strictly more information (and more relevant information!). /be ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: IDE support?
I am always amused by the continuing demands for more performance. The only real advantage of performance as a major metric is that it is relatively easy to measure. If performance is your number one goal, then the only languages you should consider are assembler and machine language. :-) On the other hand, if you like safety, security, maintainability, understandability etc., then recognize that these features have associated costs. On 9/13/11 at 7:48, bren...@mozilla.com (Brendan Eich) wrote: On Sep 13, 2011, at 5:33 AM, Andreas Rossberg wrote: * A big problem is predictability, it is a black art to get the best performance out of contemporary JS VMs. This is the big one in my book. Optimization faults happen. But can we iterate till flat? A set of rules a developer interested in performance can use would be helpful. Particularly if they applied to more than one implementation. :-) * The massive complexity that comes with implementing all this affects stability. This one I'm less sympathetic to, since we won't get rid of untyped JS up front. A sunk cost fallacy? If we could make a clean break (ahem), sure. Otherwise this cost must be paid. We could get better stability with simpler, less performant VMs. Some users might prefer the increased stability and security such a VM would offer. Cheers - Bill --- Bill Frantz| Privacy is dead, get over| Periwinkle (408)356-8506 | it. | 16345 Englewood Ave www.pwpconsult.com | - Scott McNealy | Los Gatos, CA 95032 ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: IDE support?
On Sep 13, 2011, at 3:49 PM, Bill Frantz wrote: I am always amused by the continuing demands for more performance. The only real advantage of performance as a major metric is that it is relatively easy to measure. If performance is your number one goal, then the only languages you should consider are assembler and machine language. :-) On the other hand, if you like safety, security, maintainability, understandability etc., then recognize that these features have associated costs. I agree, of course. Still, it's surprising that JS, which is quite fast, is still considered the performance bottleneck. Profiles I see, ignoring JS-heavy benchmarks that don't match much real-world code, show we have work cut out elsewhere: DOM, layout, rendering... Sure, putting game logic and physics engine in JS will hurt. Indeed we should be using the short-vector units and massively parallel GPUs (safely) from JS. More on this very soon. On 9/13/11 at 7:48, bren...@mozilla.com (Brendan Eich) wrote: On Sep 13, 2011, at 5:33 AM, Andreas Rossberg wrote: * A big problem is predictability, it is a black art to get the best performance out of contemporary JS VMs. This is the big one in my book. Optimization faults happen. But can we iterate till flat? A set of rules a developer interested in performance can use would be helpful. Particularly if they applied to more than one implementation. :-) That will require iteration too, just to get VMs into alignment (assuming their maintainers are willing to do the work, which may mean converging on optimization hierarchy). * The massive complexity that comes with implementing all this affects stability. This one I'm less sympathetic to, since we won't get rid of untyped JS up front. A sunk cost fallacy? If we could make a clean break (ahem), sure. Otherwise this cost must be paid. We could get better stability with simpler, less performant VMs. Some users might prefer the increased stability and security such a VM would offer. Not in the large in today's browser market. A niche market, perhaps. Very niche. /be ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Response to ECMAScript Proposal
A few additional comments below. Best regards, Norbert 4. Comments show the desire for a Globalization namespace, what is the reason for this? Why not hang the services off objects that have the desired functoin, such as String.collator (or 'new String.Collator()'), Date.format, Number.format etc? These are the results of a number of discussions and compromises over time in the working group. There are couple reasons: 1. Decouple our work from main EcmaScript body and make API more like a library or ES6 module. 2. Limit conflicts with existing code 3. Future expandability - would you hang message/plural formatting on string class? What about Calendar? It seems that this makes i18n a feature, not an architecture, which is unfortunate. It is somewhat unfortunate. One way to improve this situation might be, once the internationalization API is in good shape, to propose changes in the ECMAScript Language Specification that align with and take advantage of the internationalization API. For example, we could specify that string1.localeCompare(string2) has to return the same value as (new Globalization.Collator(new Globalization.LocaleList()).compare(string1, string2), and string1.localeCompare(string2, locale) the same value as (new Globalization.Collator(new Globalization.LocaleList([locale])).compare(string1, string2). Such a spec would give the existing locale-sensitive functionality in the Language Specification some meaning, and at the same time make clear where to look for enhanced functionality. 5. Using special objects is not JavaScript-like. Why isn't LocaleList a simple array, with functions which manipulate it? The reason is that it does have specific semantics, and allows for the validation of the list one time, instead of repeating it. In the August 17, we did discuss as a goal that LocaleList functions should be able to work on generic array-like objects. It's not clear yet whether we can accomplish that. And, as Nebojša indicated, we'd have to validate array elements in every function, while the language tags in a LocaleList would be validated once. 6. Why isn't there any discovery of the default locale? Suggestion, expose HTTP accept-language as a LocaleList. A target is for web applications that need to be able to set the locale independently of the AL. (I thought we did have a way to get the AL as a LocaleList, Cira. Did that disappear, or am I misremembering.) There were problems with defining default locale: 1. Not all platforms are browser based (client apps, servers) This is true, however those platforms would still have some notion of a default locale (such as a system control panel or environment setting), or the standard could define 'None' as the 'no locale set' case. 2. Application developer should detect user language and pass it to the API (see http://stackoverflow.com/questions/1043339/javascript-for-detecting-browser-language-preference - JavaScript can't access acceptLanguage list) - but we could potentially get navigator.language at some point. But.. as you said, JavaScript can't access acceptLanguage, and it also can't access the OS locale setting in a portable way. Therefore, you are leaving the users of your proposal with no guidance or resources as to what to provide as the locale argument - they will need to use the platform specific options referred to in that link, including making an HTTP request (!) to find out the value of accept-language. How much better off are we, than where we are today? What are you referring to with regards to navigator.language? Actually, we agreed in the August 17 meeting that new LocaleList() would create a locale list with the default locale (the host environment’s current locale in ECMAScript parlance), and the way I wrote this up in subclause 7.2.2 results in a LocaleList whose property 0 contains the language tag of the default locale. This hasn't been reviewed yet, so it may still change, but I think it addresses your comment at least to some extent (you get one locale, not a priority list). A no locale set case wouldn't be useful because applications still need to be able to format numbers and compare strings. We did discuss a factory method that would convert a string in Accept-Language syntax to a LocaleList; I don't recall a decision to include it in this version of the spec. 7. Does not specify what behavior is where no locale is given. As I recall, there are vendors that do not want to be required to provide particular behavior if no locale is set. It would seem that this should then be specified to have undefined results. Tolerance for undefined results seems very low in TC39. A better solution would be to direct implementers towards something like the CLDR root locale as the lowest common denominator. 8. We are concerned about a client environment simulating a different locale than
