, 2011 7:15 PM
To: Andreas Rossberg
Cc: es-discuss@mozilla.org
Subject: Re: IDE support?
On Sep 15, 2011, at 11:57 AM, Andreas Rossberg wrote:
On 13 September 2011 16:48, Brendan Eich bren...@mozilla.com wrote:
On Sep 13, 2011, at 5:33 AM, Andreas Rossberg wrote:
* There are extra costs in space
On Sep 17, 2011, at 2:57 PM, François REMY wrote:
The best way to avoid the over-annotation of codes is probably to teach
users about WHEN or WHY they should add types guards. If you add the feature
and don't explain what's her purpose and what specific scenarii it can solve,
you'll get in
On Fri, Sep 16, 2011 at 1:55 AM, Andreas Rossberg rossb...@google.com wrote:
Being able to detect when a condition is violated is not equivalent to
knowing that it always holds.
You're right, of course. Thanks for slicing that more finely for me.
Mike
On the subjects of code navigation and DoctorJS as a basis for tools:
- Jump to the definition of a method/function.
..
- Find all invocations of a method/function.
..
I'm in the process of adding scoped tags support to DoctorJS, so that
in Vim you can also navigate to local definitions and
On 16 September 2011 02:12, Mike Shaver mike.sha...@gmail.com wrote:
On Thu, Sep 15, 2011 at 9:02 AM, Andreas Rossberg rossb...@google.com wrote:
On 14 September 2011 00:00, Brendan Eich bren...@mozilla.com wrote:
So, static+dynamic. The static side has some powerful algorithms to bring
to
On Sep 16, 2011, at 1:55 AM, Andreas Rossberg wrote:
Being able to detect when a condition is violated is not equivalent to
knowing that it always holds.
Yes, this is the point I mangled in that dynamic is necessary [in JS] ... and
gives strictly more information (and more relevant
On Fri, Sep 16, 2011 at 7:04 AM, Brendan Eich bren...@mozilla.com wrote:
On Sep 16, 2011, at 1:55 AM, Andreas Rossberg wrote:
Being able to detect when a condition is violated is not equivalent to
knowing that it always holds.
Yes, this is the point I mangled in that dynamic is necessary [in
On 13 September 2011 16:48, Brendan Eich bren...@mozilla.com wrote:
On Sep 13, 2011, at 5:33 AM, Andreas Rossberg wrote:
* 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
On 13 September 2011 21:32, Wes Garland w...@page.ca wrote:
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
On 14 September 2011 00:00, Brendan Eich bren...@mozilla.com wrote:
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!).
Nitpick: I believe you are
On Thu, Sep 15, 2011 at 9:02 AM, Andreas Rossberg rossb...@google.com wrote:
On 14 September 2011 00:00, Brendan Eich bren...@mozilla.com wrote:
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
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
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
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
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
-
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
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
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,
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
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
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
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
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
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
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:
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
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
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
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
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
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
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
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
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 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
On Mon, Sep 12, 2011 at 1:04 AM, Brendan Eich bren...@mozilla.com wrote:
Type Inference can do a lot. See http://doctorjs.org/.
We do not want people adding guards all over their code, IMHO. Anyway, we
don't know have guards ES6.
While true, I've found that you can't really overcome the
Sorry, that was garbled -- but you can always consult the strawman:strawman
and harmony:proposals pages to confirm that guards did not make ES6.
Right. Those tell me that guards are not *currently* scheduled for ES6. Have
all decisions in this regard already been made?
--
Dr. Axel
On Sep 12, 2011, at 12:51 AM, Peter van der Zee wrote:
On Mon, Sep 12, 2011 at 1:04 AM, Brendan Eich bren...@mozilla.com wrote:
Type Inference can do a lot. See http://doctorjs.org/.
We do not want people adding guards all over their code, IMHO. Anyway, we
don't know have guards ES6.
On Sep 12, 2011, at 12:58 AM, Axel Rauschmayer wrote:
Sorry, that was garbled -- but you can always consult the strawman:strawman
and harmony:proposals pages to confirm that guards did not make ES6.
Right. Those tell me that guards are not *currently* scheduled for ES6. Have
all decisions
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
On Sep 12, 2011, at 8:38 AM, Claus Reinke 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.
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
On Mon, Sep 12, 2011 at 11:38 AM, Claus Reinke claus.rei...@talk21.comwrote:
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
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
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.
Right. Those tell me that guards are not *currently* scheduled for ES6. Have
all decisions in this regard already been made?
Pretty much -- the guards and trademarking proposals came in at the May
meeting, kind of last minute. We could start worrying about Dart and try to
revive them.
: Monday, September 12, 2011 9:22 PM
To: es-discuss@mozilla.org
Subject: Re: IDE support?
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
On 12 September 2011 16:31, François REMY fremycompany_...@yahoo.fr wrote:
JavaScript is simple for the developer, but sometimes its flexibility makes
it impossible to optimize code properly. And it makes JavaScript slower.
I made this graph earlier this year, coincident with the Firefox 4
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
On Mon, Sep 12, 2011 at 5:17 PM, Axel Rauschmayer a...@rauschma.de wrote:
Regarding tool support, adding type annotations in comments (JSDoc-style)
should be enough, mid-term.
For IDEs, it would really help if there weren’t so many competing standards
for even the most basic things in the JS
One thing I liked about the Dash/Dart email was that it explicitly stated the
goal of tool/IDE support (this is the only area where I miss Java when
programming JavaScript). Is there something corresponding among the Harmony
goals [1]? (5) Support a statically verifiable, object-capability
Language's don't need direct support for IDE's to have good IDEs (most of the
good Java IDEs worked through reflection and manual parsing of the source
files and parsing of defacto standard comment formatting).
I mostly agree. However, I have yet to find an IDE that makes source code
the Dash/Dart email was that it explicitly stated the
goal of tool/IDE support (this is the only area where I miss Java when
programming JavaScript). Is there something corresponding among the Harmony
goals [1]? (5) Support a statically verifiable, object-capability secure
subset
.
/be
On Sep 11, 2011, at 3:10 PM, Axel Rauschmayer wrote:
One thing I liked about the Dash/Dart email was that it explicitly stated
the goal of tool/IDE support (this is the only area where I miss Java when
programming JavaScript). Is there something corresponding among the Harmony
goals
We do not want people adding guards all over their code, IMHO.
In many cases, adding type information to my code helps me to think more
clearly about it (e.g.: signature of a function-valued parameter and arrays
whose elements all have the same type). In other cases, not having to do it is
a
On Sep 11, 2011, at 5:35 PM, Axel Rauschmayer wrote:
Anyway, we don't know have guards ES6.
Guards definitely won’t be in ES6? Or will be?
Sorry, that was garbled -- but you can always consult the strawman:strawman and
harmony:proposals pages to confirm that guards did not make ES6.
/be
56 matches
Mail list logo
