<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
  <head>
    <meta content="text/html; charset=UTF-8" http-equiv="Content-Type">
  </head>
  <body bgcolor="#ffffff" text="#000000">
    On 02.09.2010 2:44, Mike Samuel wrote:
    <blockquote
      cite="mid:AANLkTikmyZ4MnQSa4kzn8MUuBJtbdOuxUKpCuHZUMa5R@mail.gmail.com"
      type="cite">
      <pre wrap="">2010/9/1 Irakli Gozalishvili <a class="moz-txt-link-rfc2396E" href="mailto:rfobic@gmail.com">&lt;rfobic@gmail.com&gt;</a>:
</pre>
      <blockquote type="cite">
        <pre wrap="">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 &amp; coffee are good toys, but don't think it's practical to use
them for a real apps.

</pre>
      </blockquote>
    </blockquote>
    <br>
    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).<br>
    <br>
    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.<br>
    <br>
    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 <i>problems and issues</i>
    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).<br>
    <br>
    P.S.: I'm really sorry for such a big off-topic.<br>
    <br>
    <blockquote
      cite="mid:AANLkTikmyZ4MnQSa4kzn8MUuBJtbdOuxUKpCuHZUMa5R@mail.gmail.com"
      type="cite">
      <blockquote type="cite">
        <pre wrap="">BTW blessing one of the coding styles as Dmitry suggested may be a
successful attempt for solving at least half of the issue.
</pre>
      </blockquote>
      <pre wrap="">
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?


</pre>
    </blockquote>
    <br>
    Yeah, right... But, since there is a (formal?) language named
    "ECMAScript", maybe it worth to write at least some <i>recommendation</i>
    for a coding style. At least with naming convention of
    properties/methods. The spec itself <span class="ref_result">prompt</span>s
    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.<br>
    <br>
    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.<br>
    <br>
    Dmitry.<br>
    <br>
    <blockquote
      cite="mid:AANLkTikmyZ4MnQSa4kzn8MUuBJtbdOuxUKpCuHZUMa5R@mail.gmail.com"
      type="cite">
      <pre wrap=""></pre>
      <blockquote type="cite">
        <pre wrap="">On Sat, Aug 28, 2010 at 05:16, Brendan Eich <a class="moz-txt-link-rfc2396E" href="mailto:brendan@mozilla.com">&lt;brendan@mozilla.com&gt;</a> wrote:
</pre>
        <blockquote type="cite">
          <pre wrap="">
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 -&gt;
JS in the browser is looking good, ignoring the standard library issue
(<a class="moz-txt-link-freetext" href="http://skulpt.org/">http://skulpt.org/</a>).
Your point, summarized as "Coding Style as a Failure of Language
Design",¬†was made recently by Robert O'Callahan. Perhaps you saw it?
<a class="moz-txt-link-freetext" href="http://weblogs.mozillazine.org/roc/archives/2010/07/coding_style_as.html">http://weblogs.mozillazine.org/roc/archives/2010/07/coding_style_as.html</a>
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 &amp; 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 &amp; 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: <a class="moz-txt-link-freetext" href="http://www.jeditoolkit.com/">http://www.jeditoolkit.com/</a>
Address: 29 Rue Saint-Georges, 75009 Paris, France
_______________________________________________
es-discuss mailing list
<a class="moz-txt-link-abbreviated" href="mailto:es-discuss@mozilla.org">es-discuss@mozilla.org</a>
<a class="moz-txt-link-freetext" href="https://mail.mozilla.org/listinfo/es-discuss">https://mail.mozilla.org/listinfo/es-discuss</a>

</pre>
        </blockquote>
        <pre wrap="">

_______________________________________________
es-discuss mailing list
<a class="moz-txt-link-abbreviated" href="mailto:es-discuss@mozilla.org">es-discuss@mozilla.org</a>
<a class="moz-txt-link-freetext" href="https://mail.mozilla.org/listinfo/es-discuss">https://mail.mozilla.org/listinfo/es-discuss</a>


</pre>
      </blockquote>
      <pre wrap="">_______________________________________________
es-discuss mailing list
<a class="moz-txt-link-abbreviated" href="mailto:es-discuss@mozilla.org">es-discuss@mozilla.org</a>
<a class="moz-txt-link-freetext" href="https://mail.mozilla.org/listinfo/es-discuss">https://mail.mozilla.org/listinfo/es-discuss</a>
</pre>
    </blockquote>
    <br>
  </body>
</html>