s/"not taking as inspiration"/"now taking as inspiration"
sorry for the typos, it's been a long hot day on this side of the world. On Tue, Oct 4, 2011 at 6:56 PM, Mikeal Rogers <[email protected]>wrote: > 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
