Discuss
  • On "I got 99 problems and JavaScript syntax ain't one" (was: On Incremental Updates)

On "I got 99 problems and JavaScript syntax ain't one" (was: On Incremental Updates)

# David Bruant (14 years ago)

Le 03/10/2011 22:49, Andrea Giammarchi a écrit :

Dear All, while I had the opportunity to ask directly to Brendan Eich this question, I would like to ask you 5 minutes of your precious time to understand common concerns from the JS community, summarized under my point of view in this post:

webreflection.blogspot.com/2011/10/dear-brendan-here-was-my-question.html

I would like to thank you in advance for your time and all possible answers/considerations/questions you may come up with.

I have seen the sentence "I got 99 problems and JavaScript syntax ain't one" on twitter (by @mikeal), reused in Brendan's slide of CapitolJS and at JSConf.eu. Plenty of people seem to agree with this and I would like to take one minute to justify why syntax is important in my opinion.

Currently, I can cite only one IDE that has decent JavaScript support: WebStorm. And they have a very good completion suggestion engine. I have seen JavaScript IDEs stopping to analyse when coming across the (function(){...})(); pattern.

Why aren't there that many good JavaScript IDEs? Because JavaScript is ridiculously hard to analyse. It is weakly typed, and highly dynamic. For the last months, I have given myself the challenge to come up with a program which analyse jQuery and is able to retrieve the API. This is really hard. Most of the API is added with calls to jQuery.extend. Basically, a program would have to understand the semantics of jQuery.extend. But also understand that the output of $('a') has such prototype object with such properties. This is doable (since the WebStorm people do it), but very hard.

If people have a syntax operator to perform an extend operation, well, that makes things infinitely easy to analyse, because it becomes part of the language.

Another example:

var o = Object.create(null);

What is the o? If Object.create has not been redefined, it's an object. But it may be anything if Object.create has been redefined. Consequently, a JavaScript engine can never optimize this line (or may, but have to guard that Object.create hasn't been redefined which costs a little something)

var o = null <| {};

Here, the semantics of this line is guaranteed by the language since this is syntax and not a function. Consequently, optimizations can be performed without risking to be compromised.

Syntax additions make the language easier to analyse (allowing better tooling) and more stable so easier to optimize. Syntax may not be the concern of a part of the community, but is of another. Also, I'd like to mention that I'm pro-syntax addition when it covers things that would benefit from syntax (an extend operator, object literal additions...), but i won't feed discussions on syntax which do not bring anything else than readability, namely shorter function syntax. I have a preference, but do not care of the exact final syntax. I also do not really care of what the exact final syntax will be, but I do care that JavaScript contains more syntax for common patterns, especially the ones that helps analysis and optimizations.

The JavaScript community is not one voice and doesn't have one unique set of needs. We use the language for different purposes. Some need crazy performance for awesome graphics/sound experience. Some need more stability to build tools (linters, IDE plugins, etc.). At JSconf.eu, Lea Verou mentionned during her talk that she loved Object.prototype.watch and that she wishes every browsers had this because it's helpful to write polyfills. Maybe it is time to restart the discussion on "observe" [1]. I wrote this paragraph because of the sentence "the only thing truly needed by this community now" in your (Andrea) post. "the only thing truly needed" does not exist. Maybe several people, maybe the majority of people want this. But other want other things and as long as it's justified, TC39 should address all of them.

David

[1] strawman:observe

# Kyle Simpson (14 years ago)

I'm sorry David, I just have to express a dissenting opinion here. While I could see that "better tooling!" would be a positive side-effect of some syntax suggestions, I think it's a overreaching idea to consider such a main argument for adding new syntax.

You make a compelling argument of how tooling could benefit from the new syntax, sure. But it misses a few things:

  1. The readability of the language in environments where such tooling doesn't or can't really exist.
  2. Syntax highlighting of 1-2 char operators is far less visually helpful than syntax highlighting of method names, etc.
  3. Not all developers use a unified toolset for JavaScript (compared to say .NET where the vast majority use VS)

For #1, I personally think |> looks awful. I hate it. I wouldn't use it. And

I'm less than entranced by the idea that I might have to read others' code with such confusing looking operators in it. Only if all the tools I was using to read & write JS were capable of somehow making that syntax useful/beautiful instead of ugly would your argument hold much water for me. But that's just opinion and preference.

For #2, which kinda goes with #1, I'm concerned that the readability (even with syntax highlighting) of the language as a whole will take a dip for several years as developers re-adjust to the new syntax. Syntax highlighting is often seen as a way to help the readability of a language, but syntax highlighting for new weird unfamiliar operators isn't going to help much at all.

Will it eventually get better? Sure, if we don't keep adding new syntax every edition, it'll eventually stabilize. But I don't look forward to the dip in readability for the short-term, for my own code and for everyone else's code that I read.

For #3, I don't use fancy IDE's at all. I use text editors at best. I use notepad, PSPad, and Sublime on windows. And on linux I use vi. I doubt any of those text editors are ever going to care to pick up on the syntactic nuances you suggest. Which is my bigger point. Just because tooling CAN benefit from new syntax, doesn't mean all (or even most) tooling WILL benefit. What we'll end up with is a broad range of support from none all the way up to super-awesome-happy-unicorns. So both the good and bad side of this is YMMV.

Factoring all those things in, I can't see how "new syntax==better tooling" is anything more than an auxiliary supporting argument.

And yeah, I concur with the "99 problems..." statement. Working with JavaScript every day for the better part of a decade, I can't say that JavaScript's syntax issues have ever really tripped me up. Poor API's trip me up all the time. Poor handling of async (which can be considered a syntax issue!) definitely trips me up regularly. But raw operator syntax for common tasks is rarely something that shows up on my radar. There are SO MANY other things I wish JavaScript would address first.

Just my 2 cents.

# Kyle Simpson (14 years ago)

I'm sorry David, I just have to express a dissenting opinion here. While I could see that "better tooling!" would be a positive side-effect of some syntax suggestions, I think it's a overreaching idea to consider such a main argument for adding new syntax.

You make a compelling argument of how tooling could benefit from the new syntax, sure. But it misses a few things:

  1. The readability of the language in environments where such tooling doesn't or can't really exist.
  2. Syntax highlighting of 1-2 char operators is far less visually helpful than syntax highlighting of method names, etc.
  3. Not all developers use a unified toolset for JavaScript (compared to say .NET where the vast majority use VS)

For #1, I personally think |> looks awful. I hate it. I wouldn't use it. And

I'm less than entranced by the idea that I might have to read others' code with such confusing looking operators in it. Only if all the tools I was using to read & write JS were capable of somehow making that syntax useful/beautiful instead of ugly would your argument hold much water for me. But that's just opinion and preference.

For #2, which kinda goes with #1, I'm concerned that the readability (even with syntax highlighting) of the language as a whole will take a dip for several years as developers re-adjust to the new syntax. Syntax highlighting is often seen as a way to help the readability of a language, but syntax highlighting for new weird unfamiliar operators isn't going to help much at all.

Will it eventually get better? Sure, if we don't keep adding new syntax every edition, it'll eventually stabilize. But I don't look forward to the dip in readability for the short-term, for my own code and for everyone else's code that I read.

For #3, I don't use fancy IDE's at all. I use text editors at best. I use notepad, PSPad, and Sublime on windows. And on linux I use vi. I doubt any of those text editors are ever going to care to pick up on the syntactic nuances you suggest. Which is my bigger point. Just because tooling CAN benefit from new syntax, doesn't mean all (or even most) tooling WILL benefit. What we'll end up with is a broad range of support from none all the way up to super-awesome-happy-unicorns. So both the good and bad side of this is YMMV.

Factoring all those things in, I can't see how "new syntax==better tooling" is anything more than an auxiliary supporting argument.

And yeah, I concur with the "99 problems..." statement. Working with JavaScript every day for the better part of a decade, I can't say that JavaScript's syntax issues have ever really tripped me up. Poor API's trip me up all the time. Poor handling of async (which can be considered a syntax issue!) definitely trips me up regularly. But raw operator syntax for common tasks is rarely something that shows up on my radar. There are SO MANY other things I wish JavaScript would address first.

Just my 2 cents.

# Juan Ignacio Dopazo (14 years ago)

Yes, tools should be better, but they need to start becoming better by themselves as previous discussions here have noted.

However, there are problems in the language that need to be addressed by both syntax and APIs. We need:

  • A sane way of dealing with equality, identity and basically a lot of what's in wtfjs.com
  • Ways of isolating code from the global scope
  • Tools for avoiding XSS

And there are many other features that would help a lot.

There was talk about an "is" or "eq" operator to fix equality, but it seems it got demoted or interest was lost. I'd love to hear more about what ES.next will do about ==, === and value wrappers like new Boolean(false). Replacing == with ~= and === with == crossed my mind once. Modules from ES.next and the "sandbox" attribute for iframes in HTML5 cover pretty much everything we need for avoiding the problems of the global scope. Quasis should help with XSS, but as as Nicholas Zakas saidwww.nczonline.net/blog/2011/10/03/when-web-standards-fail-us,

an API String.htmlEscape() would be implemented faster and contribute more in the short run.

So we need syntax as much as we need new APIs.

Juan

# Andrea Giammarchi (14 years ago)

David, as I have tweeted before, syntax is a non problem, surely is not a problem now because you already have alternatives such CoffeeScript, GWT, Traceeur or any sort of transpiler you want ... do all these new syntax bring real benefits to JavaScript ?

I am not sure, I never needed new syntax, and all I know is that what's needed now cannot be obtained via transpiler, at least not the performances problem you may face one day when things become a bit more complex ( just think about games )

A transpiler, CoffeeScript like stuff, can bring you already a simulation of block scope without problems and Mozilla is already working on Firefox tools able to debug CoffeeScript directly, rather than it's equivalent in JavaScript.

This achievement is possible today, what's truly needed for performances, common patterns as String#format and all other things that could help us in shorter therms is not.

Last, but not least, I asked Brendan a question, and I better reasoned it in my blog. I have not showed any community petition about this topic, but unless you learned JavaScript this year I do believe there are so many things you need that syntax, if you got, cannot have same priority ... am I wrong ?

I agree with you it's not one voice, I don't agree when you talk about syntax changes in other programming languages because 100% of them are not in the web, at least not in users browsers.

If a language is on the server side nobody cares much about these syntax changes because they can chose the version they want.

There are still services entirely based on PHP4, do they care about PHP 5.3 or 6 ? They will when necessary, when they can update their code.

Python 3000 has still poor support ... and even if server side only, you need a valid reason to choose Python 3 over 2.X because 80% of libraries out there are in Python 2 and these break in Python 3

JavaScript is the exception that confirms the rule about programming languages since is unique option for everybody.

We have done so well until now updating and enreaching it that we should understand that non breaking features are most likely the best way to go and the transition between JavaScript and SomethingDifferentOutOfES6 should be as smooth as possible, and possibly focused on what's truly needed now - not the syntax, not today, please.

Hope you got my point but feel free to ask more, if necesary, thanks.

br, WebReflection

# John J Barton (14 years ago)

On Tue, Oct 4, 2011 at 6:16 AM, David Bruant <david.bruant at labri.fr> wrote:

Why aren't there that many good JavaScript IDEs? Because JavaScript is ridiculously hard to analyse. It is weakly typed, and highly dynamic.

As we have discussed here before, good IDEs have be created for weakly typed dynamic languages.

If we have some venue to discuss JavaScript analysis I would be interested in challenging your assertion that it is hard to analyze.

In my opinion, the lack of IDEs derives from the scope of the engineering investment needed to support IDE development versus the return on investment. Only browsers have intrinsic interest in JS dev tools and ironically the browser teams rarely have JS dev expertise. Outside of browsers, business types push IDEs to diversify across languages, so we get second rate JS support in IDEs with first rate Java or C++ support. Open source efforts suffer from natural underinvestment coupled with browsers active efforts to prevent standard tools APIs that would encourage contributors to IDEs.

jjb

# Mike Samuel (14 years ago)

2011/10/4 David Bruant <david.bruant at labri.fr>:

Le 03/10/2011 22:49, Andrea Giammarchi a écrit :

Dear All,    while I had the opportunity to ask directly to Brendan Eich this question, I would like to ask you 5 minutes of your precious time to understand common concerns from the JS community, summarized under my point of view in this post:

webreflection.blogspot.com/2011/10/dear-brendan-here-was-my-question.html

I would like to thank you in advance for your time and all possible answers/considerations/questions you may come up with.

I have seen the sentence "I got 99 problems and JavaScript syntax ain't one" on twitter (by @mikeal), reused in Brendan's slide of CapitolJS and at JSConf.eu. Plenty of people seem to agree with this and I would like to take one minute to justify why syntax is important in my opinion.

Currently, I can cite only one IDE that has decent JavaScript support: WebStorm. And they have a very good completion suggestion engine. I have seen JavaScript IDEs stopping to analyse when coming across the (function(){...})(); pattern.

Why aren't there that many good JavaScript IDEs? Because JavaScript is ridiculously hard to analyse. It is weakly typed, and highly dynamic. For the last months, I have given myself the challenge to come up with a program which analyse jQuery and is able to retrieve the API. This is really hard. Most of the API is added with calls to jQuery.extend. Basically, a program would have to understand the semantics of jQuery.extend. But also understand that the output of $('a') has such prototype object with such properties. This is doable (since the WebStorm people do it), but very hard.

No it doesn't.

Just walk the object graph starting from the root object and let the set of all reachable symbols be A. Load jQuery Walk the object graph again letting the set of all reachable symbols be B.

The public API of jQuery is then (B - A).

# Russell Leggett (14 years ago)

On Tue, Oct 4, 2011 at 12:51 PM, Mike Samuel <mikesamuel at gmail.com> wrote:

No it doesn't.

Just walk the object graph starting from the root object and let the set of all reachable symbols be A. Load jQuery Walk the object graph again letting the set of all reachable symbols be B.

The public API of jQuery is then (B - A).

That's works fine under 2 conditions:

  1. You're willing to execute code instead of statically analyze it
  2. You're capable of executing that code in isolation.

On larger projects, to understand how a single file will be executed may require understanding many other files in configuration. Modules will help this a great deal - but its a syntax update, and part of the point being made here.

I would say that now that Microsoft is embracing JavaScript for Windows 8, and Adobe is accepting that HTML5 will replace a great deal of flash, the toolmakers will be going to work. Even without syntax improvements, we should see a lot of tooling improvements - however, until there's more to grasp onto, I think there will always be a ceiling on feasible tooling for an arbitrary codebase.

# Mike Samuel (14 years ago)

2011/10/4 Russell Leggett <russell.leggett at gmail.com>:

On Tue, Oct 4, 2011 at 12:51 PM, Mike Samuel <mikesamuel at gmail.com> wrote:

No it doesn't.

Just walk the object graph starting from the root object and let the set of all reachable symbols be A. Load jQuery Walk the object graph again letting the set of all reachable symbols be B.

The public API of jQuery is then (B - A).

That's works fine under 2 conditions:

  1. You're willing to execute code instead of statically analyze it
  2. You're capable of executing that code in isolation.

This should be true for most libraries out there. It obviously doesn't hold for user code and definitely not for all code in an IDE since IDE's have to deal with code during editing.

# Claus Reinke (14 years ago)

Just walk the object graph starting from the root object and let the set of all reachable symbols be A. Load jQuery Walk the object graph again letting the set of all reachable symbols be B. The public API of jQuery is then (B - A).

That's works fine under 2 conditions:

  1. You're willing to execute code instead of statically analyze it
  2. You're capable of executing that code in isolation.

This should be true for most libraries out there. It obviously doesn't hold for user code and definitely not for all code in an IDE since IDE's have to deal with code during editing.

One standard way around this dilemma is to execute such code abstractly (known as "abstract interpretation"). What that means is that the code is run through an alternative engine that does not execute the code in full detail, but only as far as necessary in order to infer some interesting properties.

In particular, one wants the abstract interpretation not to have side-effects (like network or file system operations) and one wants it to terminate (quickly; so branches and recursion tend to be approximated).

Unfortunately, interesting properties tend to be undecidable, ie, they cannot be extracted from arbitrary code while guaranteeing termination (oversimplifying: you have to run such code in full to find out what it does..).

There is no magic cure for this, but it is possible to design languages and programs in such a way that a practically relevant subset of the properties of interest becomes decidable. Doing that requires thought and a lot of work (and open minds to begin with), but the benefits tend to be worth it.

Without support from language and program designers, it does not matter how many companies throw how much money at tool development (no magic bullets). Unless you want to find out how much money they are willing or able to throw before they start throwing towels.

Support is not so much about syntax as it is about statically recognizable programming patterns (so that one can distinguish code with arbitrary effects from code that just adds properties to a class of objects, or export items to a module; and so that one can extract useful program properties without having to run the code in full).

The reason syntax tends to be mentioned is because syntax frozen in the language spec tends to be less flexible than general code implementing the same feature in the language. So it looks easier to analyze, and cannot be re-defined (in current JS).

But adding this kind of special-case syntax makes a language more complex, by adding lots of constructs that -by design- do not support the full expressiveness of the language. Other languages have demonstrated that one can fix programming patterns sufficiently to permit analysis, without fixing syntax (added bonus: less syntax, less complexity -easier for coders and tools to read/analyze- and more general usage patterns through homogeneous syntax with few special cases).

For this particular problem (improving analysis support), syntax is the wrong level to work at, but in order to see that, one would have to make an effort to work with modern type systems - why they work, and how that interacts with language and program design. To begin with, one can think of a type system as an abstract interpretation engine with enhanced information flow, and of types as program properties.

Also, if coders can express their intentions (do they really mean an object, or a record, or a map, or an array, ..?), it tends to be easier to check whether an implementation matches those intentions (within the limits of decidability, so one is usually looking at guaranteeing invariants) than to guess what those intentions were in the first place (is this a function or a method and should we give it dynamic super or not? are objects from this constructor expected to retain a certain set of properties or can they change arbitrarily? is this function going to spider the web, or will it just add a few methods to an object? can we rely on function F to be the one in the spec, or could it have been overwritten?).

It would be great if vocal JS coders with strongly expressed opinions ("often in error, never in doubt") could try a language like Haskell for a mini project. Don't worry about advanced features, just convince yourself that a static type system does not have to get in the way as often as one might expect.

Then, for your second project, start thinking about what you and the language have to do to make better use of types, rather than just get your code to compile: where do you have to change your coding patterns, compared to what you would do in JS, and how does that help the type system?

After taking these two steps (*), you will be ready to think about the pros and cons of syntax or types for helping JS tools with code analysis. And then about how this should affect JS language design. The basics don't require a big effort, but one should allow that type/analysis research has not been idle in the last 30 years - there are reasons why languages and type systems need to evolve together.

Similar real-code experiments might help with discussions of "short syntax", where the point is not to save n characters when defining a handful of functions, but to make functional abstraction so lightweight that it can be used as pervasively as one uses strings and numbers now. And another such experiment might help to convince that language-level threads and event loops are not mutually exclusive (though that information could also be found on the ecmascript wiki) and that such threads can be made so cheap that they can be used pervasively. And so on..

Sorry about this side-line. I'm not picking on anyone in particular, but I find it distressing how strongly expressed opinions do not always match with good information. And since those with good information tend to be silent while considering ramifications or writing code, JS discussions (outside this list) are all too often driven by strong opinions. The more JS coders have their own practical experience with these topics, the fewer of them will be tempted easily. Readers of this list tend to make an effort to be informed, so can set good examples in other forums.

(if there wasn't so much JS activity to cover, some JS events might consider guest talks, to borrow experience from users of "nearby" languages)

Claus clausreinke.github.com

(*) Coming from a group of dynamically typed coders that used to collect code examples that could not be typed statically, I found it enlightening to actually develop some project in Haskell and find types much less of a problem than I expected (making good use of types takes a little longer). I also found as many static type zealots as dynamic type ones, and a depressing amount of misinformation on both sides.

# John J Barton (14 years ago)

On Tue, Oct 4, 2011 at 10:26 AM, Mike Samuel <mikesamuel at gmail.com> wrote:

2011/10/4 Russell Leggett <russell.leggett at gmail.com>:

On Tue, Oct 4, 2011 at 12:51 PM, Mike Samuel <mikesamuel at gmail.com> wrote:

No it doesn't.

Just walk the object graph starting from the root object and let the set of all reachable symbols be A. Load jQuery Walk the object graph again letting the set of all reachable symbols be B.

The public API of jQuery is then (B - A).

That's works fine under 2 conditions:

  1. You're willing to execute code instead of statically analyze it
  2. You're capable of executing that code in isolation.

This should be true for most libraries out there. It obviously doesn't hold for user code and definitely not for all code in an IDE since IDE's have to deal with code during editing.

I'm not a jQuery person, but as far as I can tell jQuery introduces only one global value so the jQuery API is just the properties of that object at the point in the program where the developer needs to use jQuery. You don't have to execute code and the only graph you need to walk is the properties of one object.

jjb

# Russell Leggett (14 years ago)

On Wed, Oct 5, 2011 at 10:32 AM, John J Barton <johnjbarton at johnjbarton.com> wrote:

On Tue, Oct 4, 2011 at 10:26 AM, Mike Samuel <mikesamuel at gmail.com> wrote:

2011/10/4 Russell Leggett <russell.leggett at gmail.com>:

On Tue, Oct 4, 2011 at 12:51 PM, Mike Samuel <mikesamuel at gmail.com> wrote:

No it doesn't.

Just walk the object graph starting from the root object and let the set of all reachable symbols be A. Load jQuery Walk the object graph again letting the set of all reachable symbols be B.

The public API of jQuery is then (B - A).

That's works fine under 2 conditions:

  1. You're willing to execute code instead of statically analyze it
  2. You're capable of executing that code in isolation.

This should be true for most libraries out there. It obviously doesn't hold for user code and definitely not for all code in an IDE since IDE's have to deal with code during editing.

I'm not a jQuery person, but as far as I can tell jQuery introduces only one global value so the jQuery API is just the properties of that object at the point in the program where the developer needs to use jQuery.  You don't have to execute code and the only graph you need to walk is the properties of one object.

If you looked at the code for more than 5 minutes, you'd see that the jQuery codebase, while interesting to look at, would be ridiculously hard to statically analyze without understanding jQuery conventions. The bulk of the methods are added through calls to 'jQuery.extend(...' and 'jQuery.fn.extend(...'

# John J Barton (14 years ago)

On Wed, Oct 5, 2011 at 7:49 AM, Russell Leggett <russell.leggett at gmail.com>wrote:

On Wed, Oct 5, 2011 at 10:32 AM, John J Barton <johnjbarton at johnjbarton.com> wrote:

On Tue, Oct 4, 2011 at 10:26 AM, Mike Samuel <mikesamuel at gmail.com> wrote:

2011/10/4 Russell Leggett <russell.leggett at gmail.com>:

On Tue, Oct 4, 2011 at 12:51 PM, Mike Samuel <mikesamuel at gmail.com> wrote:

No it doesn't.

Just walk the object graph starting from the root object and let the set of all reachable symbols be A. Load jQuery Walk the object graph again letting the set of all reachable symbols be

B.

The public API of jQuery is then (B - A).

That's works fine under 2 conditions:

  1. You're willing to execute code instead of statically analyze it
  2. You're capable of executing that code in isolation.

This should be true for most libraries out there. It obviously doesn't hold for user code and definitely not for all code in an IDE since IDE's have to deal with code during editing.

I'm not a jQuery person, but as far as I can tell jQuery introduces only one global value so the jQuery API is just the properties of that object at the point in the program where the developer needs to use jQuery. You don't have to execute code and the only graph you need to walk is the properties of one object.

If you looked at the code for more than 5 minutes, you'd see that the jQuery codebase, while interesting to look at, would be ridiculously hard to statically analyze without understanding jQuery conventions. The bulk of the methods are added through calls to 'jQuery.extend(...' and 'jQuery.fn.extend(...'

Sure, that's the way lots of JS code works, which is why I think IDEs based on static analysis are doomed.

jjb

# Russell Leggett (14 years ago)

On Wed, Oct 5, 2011 at 10:52 AM, John J Barton <johnjbarton at johnjbarton.com> wrote:

On Wed, Oct 5, 2011 at 7:49 AM, Russell Leggett <russell.leggett at gmail.com> wrote:

On Wed, Oct 5, 2011 at 10:32 AM, John J Barton <johnjbarton at johnjbarton.com> wrote:

On Tue, Oct 4, 2011 at 10:26 AM, Mike Samuel <mikesamuel at gmail.com> wrote:

2011/10/4 Russell Leggett <russell.leggett at gmail.com>:

On Tue, Oct 4, 2011 at 12:51 PM, Mike Samuel <mikesamuel at gmail.com> wrote:

No it doesn't.

Just walk the object graph starting from the root object and let the set of all reachable symbols be A. Load jQuery Walk the object graph again letting the set of all reachable symbols be B.

The public API of jQuery is then (B - A).

That's works fine under 2 conditions:

  1. You're willing to execute code instead of statically analyze it
  2. You're capable of executing that code in isolation.

This should be true for most libraries out there. It obviously doesn't hold for user code and definitely not for all code in an IDE since IDE's have to deal with code during editing.

I'm not a jQuery person, but as far as I can tell jQuery introduces only one global value so the jQuery API is just the properties of that object at the point in the program where the developer needs to use jQuery.  You don't have to execute code and the only graph you need to walk is the properties of one object.

If you looked at the code for more than 5 minutes, you'd see that the jQuery codebase, while interesting to look at, would be ridiculously hard to statically analyze without understanding jQuery conventions. The bulk of the methods are added through calls to 'jQuery.extend(...' and 'jQuery.fn.extend(...'

Sure, that's the way lots of JS code works, which is why I think IDEs based on static analysis are doomed.

I was responding to:

You don't have to execute code and the only graph you need to walk is the properties of one object.

If you don't execute code, that's what static analysis is. I'm sorry, I must be missing something. And the way that jQuery (and any JS code that use a function of some kind to make classes) builds up its api is to use some helper methods, beyond which, static analysis has a really rough time. You don't seem to be disagreeing with me.

# Andrea Giammarchi (14 years ago)

Here again I am not sure how we ended up with this conversation but you can find a function able to extract properties and methods out of a generic object:

gist.github.com/1264775

It works with jQuery too, as well as arrays, etc etc

, Andrea Giammarchi

# John J Barton (14 years ago)

On Wed, Oct 5, 2011 at 8:05 AM, Russell Leggett <russell.leggett at gmail.com>wrote:

On Wed, Oct 5, 2011 at 10:52 AM, John J Barton <johnjbarton at johnjbarton.com> wrote:

On Wed, Oct 5, 2011 at 7:49 AM, Russell Leggett < russell.leggett at gmail.com> wrote:

On Wed, Oct 5, 2011 at 10:32 AM, John J Barton <johnjbarton at johnjbarton.com> wrote:

On Tue, Oct 4, 2011 at 10:26 AM, Mike Samuel <mikesamuel at gmail.com> wrote:

2011/10/4 Russell Leggett <russell.leggett at gmail.com>:

On Tue, Oct 4, 2011 at 12:51 PM, Mike Samuel <mikesamuel at gmail.com

wrote:

No it doesn't.

Just walk the object graph starting from the root object and let the

set of all reachable symbols be A. Load jQuery Walk the object graph again letting the set of all reachable symbols

be B.

The public API of jQuery is then (B - A).

That's works fine under 2 conditions:

  1. You're willing to execute code instead of statically analyze it
  2. You're capable of executing that code in isolation.

This should be true for most libraries out there. It obviously doesn't hold for user code and definitely not for all code in an IDE since IDE's have to deal with code during editing.

I'm not a jQuery person, but as far as I can tell jQuery introduces only

one global value so the jQuery API is just the properties of that object at

the point in the program where the developer needs to use jQuery. You don't

have to execute code and the only graph you need to walk is the properties of one object.

If you looked at the code for more than 5 minutes, you'd see that the jQuery codebase, while interesting to look at, would be ridiculously hard to statically analyze without understanding jQuery conventions. The bulk of the methods are added through calls to 'jQuery.extend(...' and 'jQuery.fn.extend(...'

Sure, that's the way lots of JS code works, which is why I think IDEs based on static analysis are doomed.

I was responding to:

You don't have to execute code and the only graph you need to walk is the

properties of one object.

If you don't execute code, that's what static analysis is. I'm sorry, I must be missing something. And the way that jQuery (and any JS code that use a function of some kind to make classes) builds up its api is to use some helper methods, beyond which, static analysis has a really rough time. You don't seem to be disagreeing with me.

Oh I got burnt by "static analysis" before, I should know better. I keep thinking that static analysis means "analysis of a single compilation unit outside of the runtime" as most IDEs for statically typed languages use.

I meant: if your tool is embedded in the run time then it knows the exact jQuery API because it can scan the exact jQuery object. No code on this jQuery object needs to run (though that issue is not a show stopper in practice, witness breakpoint debugging).

I don't know what to call runtime analysis that does not run extraneous code.

jjb

# Russell Leggett (14 years ago)

On Wed, Oct 5, 2011 at 11:48 AM, Andrea Giammarchi <andrea.giammarchi at gmail.com> wrote:

Here again I am not sure how we ended up with this conversation but you can find a function able to extract properties and methods out of a generic object: gist.github.com/1264775 It works with jQuery too, as well as arrays, etc etc ,   Andrea Giammarchi

Its a nice snippet, but it does require executing the code. It clearly operates on an object in running code, not an AST. Sorry, I guess I just don't understand where this thread is going.. :)

# John J Barton (14 years ago)

On Wed, Oct 5, 2011 at 8:57 AM, Russell Leggett <russell.leggett at gmail.com>wrote:

On Wed, Oct 5, 2011 at 11:48 AM, Andrea Giammarchi <andrea.giammarchi at gmail.com> wrote:

Here again I am not sure how we ended up with this conversation but you can find a function able to extract properties and methods out of a generic object: gist.github.com/1264775 It works with jQuery too, as well as arrays, etc etc , Andrea Giammarchi

Its a nice snippet, but it does require executing the code. It clearly operates on an object in running code, not an AST. Sorry, I guess I just don't understand where this thread is going.. :)

We are trying to convince you that limiting your analysis to ASTs will limit the scope of your tools ;-).

jjb

# Andrea Giammarchi (14 years ago)

with such dynamic language I would never trust much AST

This is for realtime, inline, methods and properties suggestion and it's kinda fast as macro/inspector

I don't know where the thread is going either :-)

# Russell Leggett (14 years ago)

On Wed, Oct 5, 2011 at 11:49 AM, John J Barton <johnjbarton at johnjbarton.com> wrote:

On Wed, Oct 5, 2011 at 8:05 AM, Russell Leggett <russell.leggett at gmail.com> wrote:

On Wed, Oct 5, 2011 at 10:52 AM, John J Barton <johnjbarton at johnjbarton.com> wrote:

On Wed, Oct 5, 2011 at 7:49 AM, Russell Leggett <russell.leggett at gmail.com> wrote:

On Wed, Oct 5, 2011 at 10:32 AM, John J Barton <johnjbarton at johnjbarton.com> wrote:

On Tue, Oct 4, 2011 at 10:26 AM, Mike Samuel <mikesamuel at gmail.com> wrote:

2011/10/4 Russell Leggett <russell.leggett at gmail.com>:

On Tue, Oct 4, 2011 at 12:51 PM, Mike Samuel <mikesamuel at gmail.com> wrote:

No it doesn't.

Just walk the object graph starting from the root object and let the set of all reachable symbols be A. Load jQuery Walk the object graph again letting the set of all reachable symbols be B.

The public API of jQuery is then (B - A).

That's works fine under 2 conditions:

  1. You're willing to execute code instead of statically analyze it
  2. You're capable of executing that code in isolation.

This should be true for most libraries out there. It obviously doesn't hold for user code and definitely not for all code in an IDE since IDE's have to deal with code during editing.

I'm not a jQuery person, but as far as I can tell jQuery introduces only one global value so the jQuery API is just the properties of that object at the point in the program where the developer needs to use jQuery.  You don't have to execute code and the only graph you need to walk is the properties of one object.

If you looked at the code for more than 5 minutes, you'd see that the jQuery codebase, while interesting to look at, would be ridiculously hard to statically analyze without understanding jQuery conventions. The bulk of the methods are added through calls to 'jQuery.extend(...' and 'jQuery.fn.extend(...'

Sure, that's the way lots of JS code works, which is why I think IDEs based on static analysis are doomed.

I was responding to:

You don't have to execute code and the only graph you need to walk is the properties of one object.

If you don't execute code, that's what static analysis is. I'm sorry, I must be missing something. And the way that jQuery (and any JS code that use a function of some kind to make classes) builds up its api is to use some helper methods, beyond which, static analysis has a really rough time. You don't seem to be disagreeing with me.

Oh I got burnt by "static analysis" before, I should know better. I keep thinking that static analysis means "analysis of a single compilation unit outside of the runtime" as most IDEs for statically typed languages use.

I meant: if your tool is embedded in the run time then it knows the exact jQuery API because it can scan the exact jQuery object. No code on this jQuery object needs to run (though that issue is not a show stopper in practice, witness breakpoint debugging).

I don't know what to call runtime analysis that does not run extraneous code.

I see, yes. Yeah, I mean if I run the JavaScript console in chrome I get nice autocompletion because its using the running environment to know what properties an object has. I believe this is what a lot of smalltalk IDEs used to do.

There are still a lot of limitations, though. I mean, what is the purpose of the analysis in the long run. Modern Java IDEs can do a lot of things with static analysis that are very helpful like refactoring and autocompletion. Look, I'm not trying to turn this into a static vs. dynamic debate, my point is that there are a lot of limitations - and useful tooling that is impossible with dynamic code. I think we got here because someone was trying to make the point that the ability to add statically analyzable constraints would be useful to tooling. In JavaScript, the way to do that may have to be through syntactic additions such as extends or <|. I'm certainly not opposed to analysis that goes beyond ASTs. I say, any way you can get it!

# Russell Leggett (14 years ago)

On Wed, Oct 5, 2011 at 12:04 PM, Andrea Giammarchi <andrea.giammarchi at gmail.com> wrote:

with such dynamic language I would never trust much AST This is for realtime, inline, methods and properties suggestion and it's kinda fast as macro/inspector I don't know where the thread is going either :-)

It would also break as soon as you hit your first function call until that function got executed. :)

# Russell Leggett (14 years ago)

On Wed, Oct 5, 2011 at 10:03 AM, Claus Reinke <claus.reinke at talk21.com> wrote:

Just walk the object graph starting from the root object and let the set of all reachable symbols be A. Load jQuery Walk the object graph again letting the set of all reachable symbols be B. The public API of jQuery is then (B - A).

That's works fine under 2 conditions:

  1. You're willing to execute code instead of statically analyze it
  2. You're capable of executing that code in isolation.

This should be true for most libraries out there. It obviously doesn't hold for user code and definitely not for all code in an IDE since IDE's have to deal with code during editing.

One standard way around this dilemma is to execute such code abstractly (known as "abstract interpretation"). What that means is that the code is run through an alternative engine that does not execute the code in full detail, but only as far as necessary in order to infer some interesting properties.

In particular, one wants the abstract interpretation not to have side-effects (like network or file system operations) and one wants it to terminate (quickly; so branches and recursion tend to be approximated).

Unfortunately, interesting properties tend to be undecidable, ie, they cannot be extracted from arbitrary code while guaranteeing termination (oversimplifying: you have to run such code in full to find out what it does..).

There is no magic cure for this, but it is possible to design languages and programs in such a way that a practically relevant subset of the properties of interest becomes decidable. Doing that requires thought and a lot of work (and open minds to begin with), but the benefits tend to be worth it.

Without support from language and program designers, it does not matter how many companies throw how much money at tool development (no magic bullets). Unless you want to find out how much money they are willing or able to throw before they start throwing towels.

Support is not so much about syntax as it is about statically recognizable programming patterns (so that one can distinguish code with arbitrary effects from code that just adds properties to a class of objects, or export items to a module; and so that one can extract useful program properties without having to run the code in full).

The reason syntax tends to be mentioned is because syntax frozen in the language spec tends to be less flexible than general code implementing the same feature in the language. So it looks easier to analyze, and cannot be re-defined (in current JS).

But adding this kind of special-case syntax makes a language more complex, by adding lots of constructs that -by design- do not support the full expressiveness of the language. Other languages have demonstrated that one can fix programming patterns sufficiently to permit analysis, without fixing syntax (added bonus: less syntax, less complexity -easier for coders and tools to read/analyze- and more general usage patterns through homogeneous syntax with few special cases).

For this particular problem (improving analysis support), syntax is the wrong level to work at, but in order to see that, one would have to make an effort to work with modern type systems - why they work, and how that interacts with language and program design. To begin with, one can think of a type system as an abstract interpretation engine with enhanced information flow, and of types as program properties.

Also, if coders can express their intentions (do they really mean an object, or a record, or a map, or an array, ..?), it tends to be easier to check whether an implementation matches those intentions (within the limits of decidability, so one is usually looking at guaranteeing invariants) than to guess what those intentions were in the first place (is this a function or a method and should we give it dynamic super or not? are objects from this constructor expected to retain a certain set of properties or can they change arbitrarily? is this function going to spider the web, or will it just add a few methods to an object? can we rely on function F to be the one in the spec, or could it have been overwritten?).

I agree with this 100%. Languages as dynamic as JavaScript and Ruby are interesting, because as much as the freedoms can allow for more concise code and a level of expression that can often be difficult to achieve in more statically typed languages, it can also lead to a place with almost no constraints or guarantees. Sometimes these guarantees can be remarkably useful for the coder, the compiler, and the tooling.

It would be great if vocal JS coders with strongly expressed opinions ("often in error, never in doubt") could try a language like Haskell for a mini project. Don't worry about advanced features, just convince yourself that a static type system does not have to get in the way as often as one might expect.

I don't think I qualify as a vocal JS coder, though I write a lot of it, and I have learned a fair amount of Haskell. I'm pretty sure I even understand monads ;) I find that even though you don't write a lot of types because of inference, you do think about it a lot more, especially when they get complicated. Sometimes this can be a good thing, and sometimes not as much, though I would argue even a JS coder should be thinking about types - structurally speaking. Types exist static or not.

Then, for your second project, start thinking about what you and the language have to do to make better use of types, rather than just get your code to compile: where do you have to change your coding patterns, compared to what you would do in JS, and how does that help the type system?

I think a lot of common patterns, especially in library code that does a lot of meta-programming would be a lot harder to do with static types. Good or bad, I think a lot of code would have to change if that bar got bumped very far. However, seeing as anything added would still have to backwards compatible for the most part, I think anything done to the type system which isn't just sugar would have to be optional for sure, and then that would have to still mix well with the dynamically typed code.

After taking these two steps (*), you will be ready to think about the pros and cons of syntax or types for helping JS tools with code analysis. And then about how this should affect JS language design. The basics don't require a big effort, but one should allow that type/analysis research has not been idle in the last 30 years - there are reasons why languages and type systems need to evolve together.

If I had my way, I would probably try to get JavaScript to allow structural typing as much as possibile. Optional structural types I guess - with as much type inference as possible. Runtime checks for guards when not possible statically.

With the notion of freezing and sealing in ES5, we're starting to approach the ability to make these types of constraints, but because of the way they are being done imperatively, a lot of those constraints are a lot harder to use, and certainly much harder to analyze for tooling, and I imagine the compiler? I guess that is where I would want things to go - things like the updates to object literal syntax are a great start.

# Andrea Giammarchi (14 years ago)

Sorry Russ, I am not sure I got it

# John J Barton (14 years ago)

On Wed, Oct 5, 2011 at 9:11 AM, Russell Leggett <russell.leggett at gmail.com>wrote:

On Wed, Oct 5, 2011 at 11:49 AM, John J Barton <johnjbarton at johnjbarton.com> wrote:

On Wed, Oct 5, 2011 at 8:05 AM, Russell Leggett < russell.leggett at gmail.com> wrote:

On Wed, Oct 5, 2011 at 10:52 AM, John J Barton <johnjbarton at johnjbarton.com> wrote:

On Wed, Oct 5, 2011 at 7:49 AM, Russell Leggett <russell.leggett at gmail.com> wrote:

On Wed, Oct 5, 2011 at 10:32 AM, John J Barton <johnjbarton at johnjbarton.com> wrote:

On Tue, Oct 4, 2011 at 10:26 AM, Mike Samuel <mikesamuel at gmail.com

wrote:

2011/10/4 Russell Leggett <russell.leggett at gmail.com>:

On Tue, Oct 4, 2011 at 12:51 PM, Mike Samuel <mikesamuel at gmail.com> wrote:

No it doesn't.

Just walk the object graph starting from the root object and let

the set of all reachable symbols be A. Load jQuery Walk the object graph again letting the set of all reachable symbols be B.

The public API of jQuery is then (B - A).

That's works fine under 2 conditions:

  1. You're willing to execute code instead of statically analyze it
  1. You're capable of executing that code in isolation.

This should be true for most libraries out there. It obviously doesn't hold for user code and definitely not for all code in an IDE since IDE's have to deal with code during editing.

I'm not a jQuery person, but as far as I can tell jQuery introduces only one global value so the jQuery API is just the properties of that object

at the point in the program where the developer needs to use jQuery. You don't have to execute code and the only graph you need to walk is the properties of one object.

If you looked at the code for more than 5 minutes, you'd see that the jQuery codebase, while interesting to look at, would be ridiculously hard to statically analyze without understanding jQuery conventions. The bulk of the methods are added through calls to 'jQuery.extend(...'

and 'jQuery.fn.extend(...'

Sure, that's the way lots of JS code works, which is why I think IDEs based on static analysis are doomed.

I was responding to:

You don't have to execute code and the only graph you need to walk is

the properties of one object.

If you don't execute code, that's what static analysis is. I'm sorry, I must be missing something. And the way that jQuery (and any JS code that use a function of some kind to make classes) builds up its api is to use some helper methods, beyond which, static analysis has a really rough time. You don't seem to be disagreeing with me.

Oh I got burnt by "static analysis" before, I should know better. I keep thinking that static analysis means "analysis of a single compilation unit outside of the runtime" as most IDEs for statically typed languages use.

I meant: if your tool is embedded in the run time then it knows the exact jQuery API because it can scan the exact jQuery object. No code on this jQuery object needs to run (though that issue is not a show stopper in practice, witness breakpoint debugging).

I don't know what to call runtime analysis that does not run extraneous code.

I see, yes. Yeah, I mean if I run the JavaScript console in chrome I get nice autocompletion because its using the running environment to know what properties an object has. I believe this is what a lot of smalltalk IDEs used to do.

There are still a lot of limitations, though. I mean, what is the purpose of the analysis in the long run. Modern Java IDEs can do a lot of things with static analysis that are very helpful like refactoring and autocompletion. Look, I'm not trying to turn this into a static vs. dynamic debate, my point is that there are a lot of limitations - and useful tooling that is impossible with dynamic code. I think we got here because someone was trying to make the point that the ability to add statically analyzable constraints would be useful to tooling.

And it is on this exact point that we disagree....

In JavaScript, the way to do that may have to be through syntactic additions such as extends or <|. I'm certainly not opposed to analysis that goes beyond ASTs. I say, any way you can get it!

... because once we go beyond ASTs much of the value of changing the language for tools goes away.

Of course if you make developers do more work for tools, tools can be better. But we should first ensure that tools do their best, then decide what to force on devs.

jjb

# Russell Leggett (14 years ago)

On Wed, Oct 5, 2011 at 1:18 PM, John J Barton <johnjbarton at johnjbarton.com> wrote:

On Wed, Oct 5, 2011 at 9:11 AM, Russell Leggett <russell.leggett at gmail.com> wrote:

On Wed, Oct 5, 2011 at 11:49 AM, John J Barton <johnjbarton at johnjbarton.com> wrote:

On Wed, Oct 5, 2011 at 8:05 AM, Russell Leggett <russell.leggett at gmail.com> wrote:

On Wed, Oct 5, 2011 at 10:52 AM, John J Barton <johnjbarton at johnjbarton.com> wrote:

On Wed, Oct 5, 2011 at 7:49 AM, Russell Leggett <russell.leggett at gmail.com> wrote:

On Wed, Oct 5, 2011 at 10:32 AM, John J Barton <johnjbarton at johnjbarton.com> wrote:

On Tue, Oct 4, 2011 at 10:26 AM, Mike Samuel <mikesamuel at gmail.com> wrote:

2011/10/4 Russell Leggett <russell.leggett at gmail.com>:

On Tue, Oct 4, 2011 at 12:51 PM, Mike Samuel <mikesamuel at gmail.com> wrote:

No it doesn't.

Just walk the object graph starting from the root object and let the set of all reachable symbols be A. Load jQuery Walk the object graph again letting the set of all reachable symbols be B.

The public API of jQuery is then (B - A).

That's works fine under 2 conditions:

  1. You're willing to execute code instead of statically analyze it
  2. You're capable of executing that code in isolation.

This should be true for most libraries out there. It obviously doesn't hold for user code and definitely not for all code in an IDE since IDE's have to deal with code during editing.

I'm not a jQuery person, but as far as I can tell jQuery introduces only one global value so the jQuery API is just the properties of that object at the point in the program where the developer needs to use jQuery.  You don't have to execute code and the only graph you need to walk is the properties of one object.

If you looked at the code for more than 5 minutes, you'd see that the jQuery codebase, while interesting to look at, would be ridiculously hard to statically analyze without understanding jQuery conventions. The bulk of the methods are added through calls to 'jQuery.extend(...' and 'jQuery.fn.extend(...'

Sure, that's the way lots of JS code works, which is why I think IDEs based on static analysis are doomed.

I was responding to:

You don't have to execute code and the only graph you need to walk is the properties of one object.

If you don't execute code, that's what static analysis is. I'm sorry, I must be missing something. And the way that jQuery (and any JS code that use a function of some kind to make classes) builds up its api is to use some helper methods, beyond which, static analysis has a really rough time. You don't seem to be disagreeing with me.

Oh I got burnt by "static analysis" before, I should know better. I keep thinking that static analysis means "analysis of a single compilation unit outside of the runtime" as most IDEs for statically typed languages use.

I meant: if your tool is embedded in the run time then it knows the exact jQuery API because it can scan the exact jQuery object. No code on this jQuery object needs to run (though that issue is not a show stopper in practice, witness breakpoint debugging).

I don't know what to call runtime analysis that does not run extraneous code.

I see, yes. Yeah, I mean if I run the JavaScript console in chrome I get nice autocompletion because its using the running environment to know what properties an object has. I believe this is what a lot of smalltalk IDEs used to do.

There are still a lot of limitations, though. I mean, what is the purpose of the analysis in the long run. Modern Java IDEs can do a lot of things with static analysis that are very helpful like refactoring and autocompletion. Look, I'm not trying to turn this into a static vs. dynamic debate, my point is that there are a lot of limitations - and useful tooling that is impossible with dynamic code. I think we got here because someone was trying to make the point that the ability to add statically analyzable constraints would be useful to tooling.

And it is on this exact point that we disagree....

In JavaScript, the way to do that may have to be through syntactic additions such as extends or <|. I'm certainly not opposed to analysis that goes beyond ASTs. I say, any way you can get it!

... because once we go beyond ASTs much of the value of changing the language for tools goes away.

Of course if you make developers do more work for tools, tools can be better. But we should first ensure that tools do their best, then decide what to force on devs.

Sometimes going beyond ASTs is extremely challenging - but OK, let's just say we reach a point where we have tools good enough that they can read in code that has been run through a build tool so that they can actually evaluate an entire code base as it would be delivered to the browser. Now what? Do you think that any tool will do a better job of runtime analysis than the tracing JITs that browsers have now? The whole goal for advanced JavaScript compilers is to be able to take a JavaScript program which is incredibly mutable and unconstrained, and pin down what the constraints actually are to generate better code. These constraints are what we're talking about, the ability to make certain guarantees. In the case of JavaScript, some of those guarantees are hard to make, whether statically, or at runtime. Additional syntax is a way of adding certain guarantees and I am not entirely opposed to that. That doesn't mean I want to throw everything including the kitchen sink in.

# John J Barton (14 years ago)

On Wed, Oct 5, 2011 at 2:25 PM, Russell Leggett <russell.leggett at gmail.com>wrote:

On Wed, Oct 5, 2011 at 1:18 PM, John J Barton <johnjbarton at johnjbarton.com> wrote:

On Wed, Oct 5, 2011 at 9:11 AM, Russell Leggett < russell.leggett at gmail.com> wrote:

On Wed, Oct 5, 2011 at 11:49 AM, John J Barton <johnjbarton at johnjbarton.com> wrote:

On Wed, Oct 5, 2011 at 8:05 AM, Russell Leggett <russell.leggett at gmail.com> wrote:

On Wed, Oct 5, 2011 at 10:52 AM, John J Barton <johnjbarton at johnjbarton.com> wrote:

On Wed, Oct 5, 2011 at 7:49 AM, Russell Leggett <russell.leggett at gmail.com> wrote:

On Wed, Oct 5, 2011 at 10:32 AM, John J Barton <johnjbarton at johnjbarton.com> wrote:

On Tue, Oct 4, 2011 at 10:26 AM, Mike Samuel <mikesamuel at gmail.com> wrote:

2011/10/4 Russell Leggett <russell.leggett at gmail.com>:

On Tue, Oct 4, 2011 at 12:51 PM, Mike Samuel <mikesamuel at gmail.com> wrote:

No it doesn't.

Just walk the object graph starting from the root object and let the set of all reachable symbols be A. Load jQuery Walk the object graph again letting the set of all reachable symbols be B.

The public API of jQuery is then (B - A).

That's works fine under 2 conditions:

  1. You're willing to execute code instead of statically analyze

it 2. You're capable of executing that code in isolation.

This should be true for most libraries out there. It obviously doesn't hold for user code and definitely not for all code in an IDE since IDE's have to deal with code during editing.

I'm not a jQuery person, but as far as I can tell jQuery introduces only one global value so the jQuery API is just the properties of that object at the point in the program where the developer needs to use jQuery. You

don't have to execute code and the only graph you need to walk is the properties of one object.

If you looked at the code for more than 5 minutes, you'd see that the jQuery codebase, while interesting to look at, would be ridiculously

hard to statically analyze without understanding jQuery conventions.

The bulk of the methods are added through calls to 'jQuery.extend(...' and 'jQuery.fn.extend(...'

Sure, that's the way lots of JS code works, which is why I think IDEs

based on static analysis are doomed.

I was responding to:

You don't have to execute code and the only graph you need to walk

is the properties of one object.

If you don't execute code, that's what static analysis is. I'm sorry, I must be missing something. And the way that jQuery (and any JS code that use a function of some kind to make classes) builds up its api is

to use some helper methods, beyond which, static analysis has a really

rough time. You don't seem to be disagreeing with me.

Oh I got burnt by "static analysis" before, I should know better. I keep

thinking that static analysis means "analysis of a single compilation unit outside of the runtime" as most IDEs for statically typed languages use.

I meant: if your tool is embedded in the run time then it knows the exact jQuery API because it can scan the exact jQuery object. No code on this

jQuery object needs to run (though that issue is not a show stopper in practice, witness breakpoint debugging).

I don't know what to call runtime analysis that does not run extraneous

code.

I see, yes. Yeah, I mean if I run the JavaScript console in chrome I get nice autocompletion because its using the running environment to know what properties an object has. I believe this is what a lot of smalltalk IDEs used to do.

There are still a lot of limitations, though. I mean, what is the purpose of the analysis in the long run. Modern Java IDEs can do a lot of things with static analysis that are very helpful like refactoring and autocompletion. Look, I'm not trying to turn this into a static vs. dynamic debate, my point is that there are a lot of limitations - and useful tooling that is impossible with dynamic code. I think we got here because someone was trying to make the point that the ability to add statically analyzable constraints would be useful to tooling.

And it is on this exact point that we disagree....

In JavaScript, the way to do that may have to be through syntactic additions such as extends or <|. I'm certainly not opposed to analysis that goes beyond ASTs. I say, any way you can get it!

... because once we go beyond ASTs much of the value of changing the language for tools goes away.

Of course if you make developers do more work for tools, tools can be better. But we should first ensure that tools do their best, then decide what to force on devs.

Sometimes going beyond ASTs is extremely challenging - but OK, let's just say we reach a point where we have tools good enough that they can read in code that has been run through a build tool so that they can actually evaluate an entire code base as it would be delivered to the browser. Now what? Do you think that any tool will do a better job of runtime analysis than the tracing JITs that browsers have now?

Yes, because the analysis that aids development is not the same as the analysis needed for JIT.

The

whole goal for advanced JavaScript compilers is to be able to take a JavaScript program which is incredibly mutable and unconstrained, and pin down what the constraints actually are to generate better code. These constraints are what we're talking about, the ability to make certain guarantees. In the case of JavaScript, some of those guarantees are hard to make, whether statically, or at runtime. Additional syntax is a way of adding certain guarantees and I am not entirely opposed to that. That doesn't mean I want to throw everything including the kitchen sink in.

And I think we should keep the pressure on the JIT geniuses to continue to deliver ever better performance without making developers add syntax, esp when the additions are based on incomplete or version specific information.

jjb

# Brendan Eich (14 years ago)

On Oct 4, 2011, at 7:19 AM, Juan Ignacio Dopazo wrote:

Yes, tools should be better, but they need to start becoming better by themselves as previous discussions here have noted.

However, there are problems in the language that need to be addressed by both syntax and APIs. We need:

  • A sane way of dealing with equality, identity and basically a lot of what's in wtfjs.com

Some of that is due to implicit conversions, not any equality-ish operator.

  • Ways of isolating code from the global scope

Covered by modules and module loaders.

  • Tools for avoiding XSS

That's a cross-cutting problem, not just core language. So, yes, tools but no silver bullets. ES5 has some tools, ES6 has more.

There was talk about an "is" or "eq" operator to fix equality, but it seems it got demoted or interest was lost.

Wrong: wiki.ecmascript.org/doku.php?id=harmony:egal

# Andrea Giammarchi (14 years ago)

as Zend Certified Engineer I can say == and === have never been a problem ... also there are cases when I want coercion!

var False = new Boolean(false); if (False) alert("You may say WTF"); if (False == false) alert("I may say feature");

Best , Andrea Giammarchi

# Brendan Eich (14 years ago)

You are a gmail user, I surmise. So are others. Gmail collapses cited text, so you don't trim it. Those of us using other mail user agents then have to wade through pages of cited text to find your replies, which generally only apply to the last paragraph or two of the cited text.

Any googlers among you, please write a letter, or something. Gmail is training everyone to overcite massively.

# John J Barton (14 years ago)

repeated with less quotation

# John J Barton (14 years ago)

On Thu, Oct 6, 2011 at 6:40 PM, Brendan Eich <brendan at mozilla.com> wrote:

You are a gmail user, I surmise. So are others. Gmail collapses cited text, so you don't trim it. Those of us using other mail user agents then have to wade through pages of cited text to find your replies, which generally only apply to the last paragraph or two of the cited text.

I'll try to avoid over citing. I'll request you avoid being quite so obscure.

Any googlers among you, please write a letter, or something. Gmail is

training everyone to overcite massively.

While doing extra work for back level mail agents may not appeal, quoting just the relevant text (usually) makes the arguments clearer no matter the agent.

jjb

# Brendan Eich (14 years ago)

On Oct 6, 2011, at 8:35 PM, John J Barton <johnjbarton at johnjbarton.com> wrote:

On Thu, Oct 6, 2011 at 6:40 PM, Brendan Eich <brendan at mozilla.com> wrote: You are a gmail user, I surmise. So are others. Gmail collapses cited text, so you don't trim it. Those of us using other mail user agents then have to wade through pages of cited text to find your replies, which generally only apply to the last paragraph or two of the cited text.

I'll try to avoid over citing. I'll request you avoid being quite so obscure.

When was I obscure? Did I stutter?

Any googlers among you, please write a letter, or something. Gmail is training everyone to overcite massively.

While doing extra work for back level mail agents

What does "back level" mean? Gmail is not the last word in MUAs, and anyway, the Postel's Law blowback it creates by collapsing cited text without auto-trimming is predictable, and a bug.

may not appeal, quoting just the relevant text (usually) makes the arguments clearer no matter the agent.

Yes indeed. Thanks,