death to style guidelines

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

  On 02.09.2010 2:44, Mike Samuel wrote:
> 2010/9/1 Irakli Gozalishvili<rfobic at>:
>> 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 would be just an additional place to refer first.


>> On Sat, Aug 28, 2010 at 05:16, Brendan Eich<brendan at>  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
>>> (
>>> Your point, summarized as "Coding Style as a Failure of Language
>>> Design", was made recently by Robert O'Callahan. Perhaps you saw it?
>>> 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:
>>> Address: 29 Rue Saint-Georges, 75009 Paris, France
>>> _______________________________________________
>>> es-discuss mailing list
>>> es-discuss at
>> _______________________________________________
>> es-discuss mailing list
>> es-discuss at
> _______________________________________________
> es-discuss mailing list
> es-discuss at

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <>

More information about the es-discuss mailing list