I do understand that just switching a skin is no go, but having something like:
"use clean"; Could be a very good compromise. Regarding my phrase on coffee: I did not meant to heart anybody's feelings regarding coffee script. I do like the project myself but I don't think it production ready. Here is the quote from the coffee script website: *Disclaimer:* CoffeeScript is just for fun. Until it reaches 1.0, *there are > no guarantees that the syntax won't change between versions.* > * *Regards -- Irakli Gozalishvili Web: http://www.jeditoolkit.com/ Address: 29 Rue Saint-Georges, 75009 Paris, France <http://goo.gl/maps/3CHu> On Thu, Sep 2, 2010 at 10:52, Dmitry A. Soshnikov < [email protected]> wrote: > On 02.09.2010 2:44, Mike Samuel wrote: > > 2010/9/1 Irakli Gozalishvili <[email protected]> <[email protected]>: > > I have not seen the post before, but it perfectly expresses my concerns. > I still do think though that if breaking backwards compatibility is on the > table solving "syntactic noise" issue is not such a bad idea even if it > means changing a skin it makes devs more aware of a change. > > Both skulpt & coffee are good toys, but don't think it's practical to use > them for a real apps. > > > > Actually, CoffeeScript is off-topic here. When I was mentioned it, I didn't > mean "let's make a Coffee from JS", I just noticed how elegantly Coffee > improves some syntactic constructs over JS. However, I'd like to mention > that -- you're kidding me, right (about the "toy without practical usage")? > Coffee is a new language. And the only relationship with JavaScript, is that > it's inspired by JavaScript (but actually by Ruby) and improves some > constructions (syntactically and, as a consequence, increasing and > abstraction). It's good to write a new highly-abstracted language, using > another highly-abstracted language (in this case JavaScript). If will be > needed (if will be talks about performance), it may be rewritten using > less-abstracted languages (e.g. C, Assembler) and then it will be a > completely separated from JavaScript language which is (the same as > JavaScript, Python, Ruby, etc.) just another good general purpose scripting > language -- with its own pros and cons. Moreover, CoffeeScript syntactically > mostly inspired by Ruby (in it's nature, Coffee isn't even prototype-based, > it encapsulates this stuff into the sugar of classes; JavaScript is used > only to implement Coffee. And as you know, the latest version of Coffee is > already written on Coffee itself but not on JavaScript). If it will have a > strong support (by committees, browsers, etc), it may win JavaScript. But I > don't think it will in nearest future (the same useless talks about Python > and Ruby native support in nowadays for browsers). > > However, if not to translate/compile Coffee's code into JS-code at runtime, > but with static preprocessing -- having as an output ready JS-code-generated > files, and then just include these js-files to the project -- it normally > may be used in projects today. There is a lack with debugging in this case, > but I think it may be solved somehow. > > And regarding JS, yeah, backward compats matter and it's really > not-practical to switch the "skin" so radically. However, since ES has "use > strict" feature which is, besides being a helper for "inattentive > programmer", also is used as a deprecated/obsolete stuff notifier (e.g. > with-statement), it may be used in future for the same role -- removing > old-style/deprecated syntactic garbage, and replacing it with alternative > constructs. (Because e.g. when C was creating its "switch-cases" with known > today "non-logical" behavior, its decision was related with *problems and > issues* of code-generation (e.g. in Assembler) -- it was needed that > "break", because it's just a "jmp" from the block. But when other languages > (Java, JavaScript) just repeat this syntax construct completely after C, > they just thought about "to be a new language with already-known syntax". > And attempts to improve some constructs of previous language, would break > this aim). > > P.S.: I'm really sorry for such a big off-topic. > > > BTW blessing one of the coding styles as Dmitry suggested may be a > successful attempt for solving at least half of the issue. > > Might blessing a style guide be better done by a software producing > organization like Mozilla or JQuery than by a standard producing > organization like TC39? > > > > > Yeah, right... But, since there is a (formal?) language named "ECMAScript", > maybe it worth to write at least some *recommendation* for a coding style. > At least with naming convention of properties/methods. The spec itself > prompts a programmer that methods should be named in camelCase, that > constructors should be named in upper CamelCase, etc. If an official site of > the technology will have such a recommendation (I repeat, even Python with > it's "hard-coded" syntax rules has additionally PEP8 -- to (recommend to) > name properties/methods in uderscore_case), then we'll see that many > companies when choosing a coding style will refer to the official > recommendation. > > But however, as I mentioned, in more-less professional JS-coding today I > don't see any "wars". A majority are in use Java-like stylistics, with again > prompts from the spec for naming convention. So, an official document on > ecmascript.org would be just an additional place to refer first. > > Dmitry. > > > On Sat, Aug 28, 2010 at 05:16, Brendan Eich <[email protected]> > <[email protected]> wrote: > > It's not practical to change the "skin" of JS this radically, but OTOH > browser JS VMs are getting so fast that it *is* practical to compile > CoffeeScript and other nearby source languages to JS. Heck, even Python -> > JS in the browser is looking good, ignoring the standard library issue > (http://skulpt.org/). > Your point, summarized as "Coding Style as a Failure of Language > Design", was made recently by Robert O'Callahan. Perhaps you saw > it?http://weblogs.mozillazine.org/roc/archives/2010/07/coding_style_as.html > It is IMHO a good argument for language designers operating without > backward compatibility and installed base constraints to consider. > /be > > On Aug 27, 2010, at 3:15 AM, Irakli Gozalishvili wrote: > > Hi, > > Please don't be too aggressive in replies, I know it's too ambitious & may > not lead to anything, but I still want to give it a try and suggest to: > > Employ some of the decisions that being made with coffee script & python > in order to over all the wars regarding: 2 space vs 4 space vs tabs, where > to put braces, whether or not use optional semicolons. All the style > guidelines, just hurt developers, who have to switch mentally every time > they work on a project with a different style guides. Besides if I follow > correctly it's being agreed to make backwards incompatible syntax changes in > new version of ECMAScript :) > > As a side note, I'd like to also mention that coffee script managed to > reduce verbosity so match, making writing code so much better experience! > > Regards! > -- > Irakli Gozalishvili > Web: http://www.jeditoolkit.com/ > Address: 29 Rue Saint-Georges, 75009 Paris, France > _______________________________________________ > es-discuss mailing > [email protected]https://mail.mozilla.org/listinfo/es-discuss > > _______________________________________________ > es-discuss mailing > [email protected]https://mail.mozilla.org/listinfo/es-discuss > > _______________________________________________ > es-discuss mailing > [email protected]https://mail.mozilla.org/listinfo/es-discuss > > > > _______________________________________________ > 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
