s/restructuring/destructuring On Tue, Oct 4, 2011 at 6:52 PM, Mikeal Rogers <[email protected]>wrote:
> Maybe it's time for me to chime in. > > While I find it facilitating that so much meaning is being found in my > tweet I thought it might be productive to say what I actually meant by the > comment. > > JavaScript's current (ECMA5) syntax has never prevented me from building an > application. I find coffeescript, and compile-to-js languages in general, an > attempt to solve the wrong problem, because syntax isn't my problem. > > There are things in the language that actively make it harder for me to > build applications (64bit int & binary support being the biggest). > > I'm now in the odd position of working with a lot of people that are new to > JavaScript, mainly using node.js. > > It's important to note at this time that I don't think there is any > programming language that is easier for people to learn than JavaScript. > I've had to teach people Python. Teaching someone Python lasts for years. > There is a huge amount of additional syntax and semantics that you don't > learn until you're usually years in to programming Python. It's terrible for > not just beginners but novice and intermediate programmers to work with > "experts". > > My main concern with *some* of the proposals is that I feel they add > features and clever syntax for experts at the expense of keeping the > language easy to understand for new programmers. > > This is not that case for all the proposals. From what I've seen of the > restructuring proposal it's actually quite nice and and obvious to read > syntax for someone trying to reason about what it does. Contrast that with > the current practice of new users reading 10 lines of code for handling > default values and an Array.prototype.slice.call(arguments) WTF line of code > at the top. It's a step in the right direction. > > There are things we can do to make JavaScript a better and more easy to > understand language. I think some of the proposals do exactly that. > > But, some of them simply double the semantics and syntax in the language > without a path to deprecate previous syntax. I'm a big fan of let, but if > you don't deprecate var we're going to have to contend with new programmers > keeping two sets of scoping rules in their head. > > Finally, the features that are being added for "experts". > > Generators.... so a function is sometimes a constructor, sometimes a > function, and sometimes it's a generator?!?! Explain that in one paragraph > that new programmers can understand, I dare you. > > Array comprehensions.... very clever syntax that even experienced > programmers can sometimes barely figure out. I dealt with these in Python > all over the place, I wrote them as often as I could cause I wanted to be > clever, and nobody understood what the hell my code was doing and I'm sorry > for that. > > To summarize, I don't think "new syntax === bad" is how we should > characterize opposition to doubling the semantics and syntax in the > language. Some of the proposals go a long way to removing confusion in the > language while others are just far too clever to be understood easily by new > developers. > > Brendan said something very interesting in his talk at JSConf.eu, he said > that because of the way TC39 works any new proposal that doesn't have (and I > hope I'm paraphrasing this right) "sexy syntax to start with doesn't have > much of a chance". I find that very enlightening. Too often in a group of > people who design languages for a living sexy syntax is clever syntax. > > Exactly what excites those who are professional language designers can be > detrimental to this language's continuing success among new programmers, > something it has for the last 10 years continued to outpace all the other > languages you are not taking as inspiration. > > -Mikeal > > > On Tue, Oct 4, 2011 at 5:51 PM, Andrea Giammarchi < > [email protected]> wrote: > >> I am on mobile so it's short one ... subclassing does not need new syntax, >> it needs eventually a fix on Object.create or a similar method. However, >> subclassing will always suffer cross frame issues, isn't it so how a >> triangle can magically solve this specific problems is a mystery to me but >> I'll be happy to show examples you can reuse to simulate new syntax features >> :-) >> >> >> On Tuesday, October 4, 2011, David Bruant <[email protected]> wrote: >> > Le 04/10/2011 17:03, Andrea Giammarchi a écrit : >> > >> > 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 sent a message here explaining the necessity of a syntax construct for >> a reliable bind [1]. There is a need to investingate (one reply was very >> close from a solution) to make sure that such a thing is not possible in >> pure ES5 (without making Function.prototype.bind non-configurable), but that >> would be one such thing that no language compiling to JavaScript could >> emulate (since impossible in the language itself). >> > >> > The prototype operator allows subclassing which was a long awaited >> feature and this is not doable in pure ES5 (without __proto__ which IE has >> never supported). This doesn't require syntax, but the idea of the proto >> operator looks elegant to me (the idea, not necessarily the proposed syntax) >> > >> > Having new syntax for modules is not necessary per se but would be great >> to programatically analyse the module itself. >> > >> > But I agree that most other things may not be necessary for the language >> itself since they could be emulated in another non-syntaxy way (but I'd be >> interested in seeing the non-syntax equivalent to make sure syntax is not >> that helpful). >> > >> > I am not sure, I never needed new syntax, and all I know is that what's >> needed now cannot be obtained via transpiler >> > >> > Subclassing cannot be achieved (or requires to extend built-in which in >> some cases may not be what people want) since it's not possible in >> JavaScript itself. >> > >> > >> > 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. >> > >> > But it's a tool. Mozilla doesn't work on a CoffeeScript emulator. It >> keeps investing (as everyone) in making a JavaScript interpretor. And such >> an interpretor would benefit from language constructs which offers >> invariants since invariants often result in performance improvements. >> > After his JSConf.eu talk on Garbage Collection, I discussed with Erik >> Corry who told me that strict mode helped a bit with performance (things >> related to scopes and eval). I would expect the same things from syntax >> operators: offering invariants which can help out with performance. >> > As long as JavaScript is the only thing that web browsers natively >> understand, we need to improve the language itself, syntax included since >> it's the only element of the language that programmers can't replace. >> > >> > 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, but syntax is one other problem as well. >> > >> > 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. >> > >> > This is extremely true and this is the reason why ES.next will have an >> opt-in. >> > >> > As you mention, JavaScript has the particularity of being the only >> "mobile code on the web" language. Any change to the language will require >> an opt-in. As I said above, there are a couple of things that need a syntax >> construct, so I think that changing the syntax is necessary, and >> consequently so is adding an opt-in. >> > Since any syntax change requires an opt-in, I think we can agree that as >> many as many syntax changes as possible (and as necessary of course) should >> ship with ES.next (10 years from now, I don't want to see thousands of >> opt-ins) >> > >> > As a side note, an opt-in is not necessary for each syntax change. ES5 >> brought getter and setter initialization syntax. There is no opt-in. The >> downside being that no one can use them until IE8 is dead. (I agree that no >> one really care of this one, but you get the point) >> > >> > 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. >> > >> > When then? :-) >> > It seems that there will always be something that we need to do that may >> not require syntax. But modules, for instance is something we need now as >> well. Subclassing has been long awaited too. And for both, providing syntax >> constructs sounds relevant. >> > >> > David >> > >> > [1] >> https://mail.mozilla.org/pipermail/es-discuss/2011-August/016395.html >> > >> > >> > 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 >> > >> > >> > >> >> _______________________________________________ >> es-discuss mailing list >> [email protected] >> https://mail.mozilla.org/listinfo/es-discuss >> >> >
_______________________________________________ es-discuss mailing list [email protected] https://mail.mozilla.org/listinfo/es-discuss
