On 02.09.2010 2:44, Mike Samuel wrote:
2010/9/1 Irakli Gozalishvili<rfo...@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<bren...@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@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
_______________________________________________
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
_______________________________________________
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
_______________________________________________
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
