Re: On I got 99 problems and JavaScript syntax ain't one (was: OnIncremental Updates)
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 Regards, Andrea Giammarchi ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: On I got 99 problems and JavaScript syntax ain't one (was: OnIncremental Updates)
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
Re: On I got 99 problems and JavaScript syntax ain't one (was: OnIncremental Updates)
On Wed, Oct 5, 2011 at 10:03 AM, Claus Reinke claus.rei...@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
Re: On I got 99 problems and JavaScript syntax ain't one (was: OnIncremental Updates)
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 http://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 /be ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: On I got 99 problems and JavaScript syntax ain't one (was: OnIncremental Updates)
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 ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: On I got 99 problems and JavaScript syntax ain't one (was: OnIncremental Updates)
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 ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: On I got 99 problems and JavaScript syntax ain't one (was: OnIncremental Updates)
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 http://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 saidhttp://www.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 ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
