death to style guidelines

Irakli Gozalishvili rfobic at gmail.com
Wed Sep 8 01:11:22 PDT 2010


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 <
dmitry.soshnikov at gmail.com> wrote:

>  On 02.09.2010 2:44, Mike Samuel wrote:
>
> 2010/9/1 Irakli Gozalishvili <rfobic at gmail.com> <rfobic at gmail.com>:
>
>  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 <brendan at mozilla.com> <brendan at mozilla.com> 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 listes-discuss at mozilla.orghttps://mail.mozilla.org/listinfo/es-discuss
>
>  _______________________________________________
> es-discuss mailing listes-discuss at mozilla.orghttps://mail.mozilla.org/listinfo/es-discuss
>
>  _______________________________________________
> es-discuss mailing listes-discuss at mozilla.orghttps://mail.mozilla.org/listinfo/es-discuss
>
>
>
> _______________________________________________
> es-discuss mailing list
> es-discuss at mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20100908/c858f1b4/attachment-0001.html>


More information about the es-discuss mailing list