death to style guidelines
On 27.08.2010 14:15, 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.
What exactly are you suggesting to "stop wars"? Though, I think today there are no such wars in more-less professional JS scripting (usually is used combination of Java's style guide with some local changes), majority in general is in agreement of how /current/ JS code should looks like.
The priority of applying some coding conventions and style guides are:
- A local style guide used in company (the highest priority; it may shadow an official style guide of a technology if there is useful arrangement);
- The official style guide provided by the main official resource of the technology (in this case -- ecmascript.org; is a /recommendation/ for a professionally formed code);
- Local habit (the lowest priority; should be avoided. Used by beginners as a habit from previous technologies, e.g. underscore_case from C vs. camelCase used in JS).
And the only way to stop "some" mystic "wars" is to specify point (2), i.e. the official style guide suggested by the official resource of the technology. Many technologies have such recommendations, e.g. Python's "PEP 8" (www.python.org/dev/peps/pep-0008), Java's official style guide (developers.sun.com/sunstudio/products/archive/whitepapers/java-style.pdf), etc. Only having this done and /exactly on the official resource/ may be a good reference in arguments when choosing a convention style guide.
And since ECMAScript has no such an official style guide, yeah, it would be good to write one. It is even good from a solid position -- other mainstream technologies have their recommendations for professionally written code. Some of them even suggest general structure of file system folders, e.g. Erlang for building their OTP applications, or Ruby (on Rails) which uses "convention over configuration" principle for decreasing a code syntactically and to have general, well-known to everyone, structure.
Currently, as a variant, the style guide of Mozilla may be treated as an "official", because JavaScript (and its inventor) are directly related with Mozilla. So, in arguments for choosing a convention style guide you may refer to their style guide too (developer.mozilla.org/en/JavaScript_style_guide, but this is mostly for scripting XUL as I see, and there are doubtful underscores, e.g. "UI_init").
Not bad (based on Java's style guide and, actually, is its complete "clone"/port) Crockford's description: javascript.crockford.com/code.html -- this one may be used in official document on ecmascript.org (2 or 4 spaces -- is needed to be decided though).
Besides if I follow correctly it's being agreed to make backwards incompatible syntax changes in new version of ECMAScript :)
No, only very-very needed incompatible changes (a "migrate tax"?). Here was a thread when I was confused regarding short notation of "funargs" (which is #) and why "fun" cannot be used -- I thought that "fun" will be a new keyword, but no, it's not worth about new keyword.
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!
Yeah, as I mentioned, the good ways of removing all obsolete
"syntactic/logical noise/garbage" and "bad parts" of previous versions
is either to invent a new language (that is CoffeeScript does regarding
JavaScript), or to plan some version which will be completely
incomparable with previous code (let the Web crash with this new
version!, if this new version will bring new highly-abstracted, modern
and useful things). ES has such version -- it's the ES6 (aka Harmony),
but it approves only very-very needed (and well-founded) changes (e.g.
mentioned above "fun" won't be accepted because will "break the Web" as
many scripts use "fun" as a name of simple "funargs"). Current approach
with "use strict" (used now in ES5) is also a good way of, not so
radical, but gradual removing of obsolete things (with, etc).
P.S.: explicit semicolon is also a "syntactic noise". It's just a consequence of some current well-known JS's ASI pitfalls (and minimizaton's issues) that an implicit semicolon was named as a bad practice. In general, it's a "noise" which (if needed) should be done by the machine, but not the human. If implemented well, ASI -- is a good idea. So, all that Ruby, Coffee, etc decrease this noise nicely. Though, I myself (as a habit) use always now explicit semicolon.
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 (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?
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.
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.
BTW blessing one of the coding styles as Dmitry suggested may be a successful attempt for solving at least half of the issue.
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.
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?
I'm not a fan of coffee script; however, I think calling it a toy that couldn't be used for a real app with no justification for such a point is a cheap shot. There are plenty of legit reasons to complain about coffee script. I don't see why it could not be used for a real app though.
On Sep 1, 2010, at 3:22 PM, Irakli Gozalishvili wrote:
I have not seen the post before, but it perfectly expresses my concerns.
Here is an older one, from Ken Arnold in 2004, along the very same lines:
www.artima.com/weblogs/viewpost.jsp?thread=74230
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.
Backward compatibility won't be broken except around the edges, where browsers differ anyway, or there's a big gain in breaking.
What you proposed is way too big a break. Apart from the costs to implementors, users would have to hassle with two completely different syntaxes. It's not worth it.
Both skulpt & coffee are good toys, but don't think it's practical to use them for a real apps.
Browser-based translation or "re-skinning" is increasingly practical, if you really want different syntax.
BTW blessing one of the coding styles as Dmitry suggested may be a successful attempt for solving at least half of the issue.
Blessing or cursing won't change divergent styles in use today. The point of Rob's blog post and Ken Arnold's before it is to make the language parse style. That is a good idea for new languages, IMHO. But it's kind of off topic here.
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.
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.*
-- Irakli Gozalishvili Web: www.jeditoolkit.com Address: 29 Rue Saint-Georges, 75009 Paris, France goo.gl/maps/3CHu
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!
!
Irakli Gozalishvili Web: www.jeditoolkit.com Address: 29 Rue Saint-Georges, 75009 Paris, France goo.gl/maps/3CHu