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
On Tue, Oct 4, 2011 at 3:16 PM, David Bruant <[email protected]> wrote:
> 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:
>>
>> http://webreflection.blogspot.**com/2011/10/dear-brendan-here-**
>> was-my-question.html<http://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]
> http://wiki.ecmascript.org/**doku.php?id=strawman:observe<http://wiki.ecmascript.org/doku.php?id=strawman:observe>
>
_______________________________________________
es-discuss mailing list
[email protected]
https://mail.mozilla.org/listinfo/es-discuss
