death to style guidelines

Dmitry A. Soshnikov dmitry.soshnikov at gmail.com
Thu Sep 2 01:52:07 PDT 2010


  On 02.09.2010 2:44, Mike Samuel wrote:
> 2010/9/1 Irakli Gozalishvili<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>  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 list
>>> es-discuss at mozilla.org
>>> https://mail.mozilla.org/listinfo/es-discuss
>>>
>>
>> _______________________________________________
>> es-discuss mailing list
>> es-discuss at mozilla.org
>> https://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/20100902/3bb3548f/attachment-0001.html>


More information about the es-discuss mailing list