Я нашел скрытый бонус JavaScript

[x-yuri]

добавить все возможно, AS тоже на ES построен, но там такого не городили

добавить все возможно кому? Я о том, что Khronos не может изменять сам язык, или я не прав?

то что ошибок/непредсказуемых ситуаций для новичков меньше будет и то что скорость выполнения программы увеличится? так вроде только это))

мне кажется, что ты говорил про actionscript 2.0 как неудачную попытку добавить статическую типизацию в динамический язык

так драфт с типизацией массивов уже в Geko имплементирован.

ну, я себе статическую типизацию по-другому представлял, это просто какое-то добавление встроенных обьектов

ниче, скоро стрелочки еще имплементируют

вот как это должно выглядеть (мне кстати очень нравится; Haskel напоминает)

а как, кстати, предполагается "не поломать web" при этом?

[monolithed]

добавить все возможно кому?

предполагаю, что ECMA

Я о том, что Khronos не может изменять сам язык, или я не прав?

ну так WebGL же не на пустом месте появился))
Вообще я считаю, что во все современные браузеры доложен быть встроен какой-то плагин, который отвечает за имеплементацию к.л. стандарта, т.е. к примеру нет в Opera поддержки ES6, а код на странице такой есть, так брузер должен делать запрос к репозитарию для загрузки этого стандарта и т.д. (они весят килобайты)

мне кажется, что ты говорил про actionscript 2.0 как неудачную попытку добавить статическую типизацию в динамический язык

что-то я такого не припомню... видимо я не так выразился. В AS3.0 до сих пор есть возможность выбора типизации (режим компиляции).

ну, я себе статическую типизацию по-другому представлял, это просто какое-то добавление встроенных обьектов

ага((

а как, кстати, предполагается "не поломать web" при этом?

ну почему же, CoffeeScript по моему очень удачная попытка сломать эти стереотипы.

[x-yuri]

ну так WebGL же не на пустом месте появился))

но у них же есть какие-то границы ответственности? В ECMA добавить статическую типизацию не решились. Но это же не может сделать Khronos?

Вообще я считаю, что во все современные браузеры доложен быть встроен какой-то плагин, который отвечает за имеплементацию к.л. стандарта, т.е. к примеру нет в Opera поддержки ES6, а код на странице такой есть, так брузер должен делать запрос к репозитарию для загрузки этого стандарта и т.д. (они весят килобайты)

т.е. это как получается, я создаю приложение которое умеет скачивать имплементации, запускаю... и оно магическим образом превращается в браузер?

что-то я такого не припомню... видимо я не так выразился. В AS3.0 до сих пор есть возможность выбора типизации (режим компиляции).

да, это я неправильно запомнил

ага((

вообще, ответ похоже где-то здесь, только я его не вполне осознаю:

One of the use-cases for namespaces in ES4 was early binding (use
namespace intrinsic), both for performance and for programmer
comprehension -- no chance of runtime name binding disagreeing with
any earlier binding. But early binding in any dynamic code loading
scenario like the web requires a prioritization or reservation
mechanism to avoid early versus late binding conflicts.

Plus, as some JS implementors have noted with concern, multiple open
namespaces impose runtime cost unless an implementation works
significantly harder.

For these reasons, namespaces and early binding (like packages before
them, this past April) must go. This is final, they are not even a
future possibility. To achieve harmony, we have to focus not only on
nearer term improvements -- on "what's in" or what could be in -- we
must also strive to agree on what's out.

Once namespaces and early binding are out, classes can desugar to
lambda-coding + Object.freeze and friends from ES3.1. There's no need
for new runtime semantics to model what we talked about in Oslo as a
harmonized class proposal (I will publish wiki pages shortly to show
what was discussed).

We talked about desugaring classes in some detail in Oslo. During
these exchanges, we discussed several separable issues, including
classes, inheritance, like patterns, and type annotations. I'll avoid
writing more here, except to note that there were clear axes of
disagreement and agreement, grounds for hope that the committee could
reach consensus on some of these ideas, and general preference for
starting with the simplest proposals and keeping consensus as we go.

https://mail.mozilla.org/pipermail/e...st/006837.html

ну почему же, CoffeeScript по моему очень удачная попытка сломать эти стереотипы.

не, я имею в виду, если изменится синтаксис javascript, как старые браузеры на это отреагируют?

[monolithed]

но у них же есть какие-то границы ответственности?

их зона ответственности графика и звук. что хотят то и реализуют по результатам голосования участников входящих в этот консорциум (Apple, Opera, Mozilla и др.). Причем стать участником рабочей группы может абсолютно каждый

В ECMA добавить статическую типизацию не решились

видимо есть на то причины или сложности в реализации этой части в ядро.

т.е. это как получается, я создаю приложение которое умеет скачивать имплементации, запускаю... и оно магическим образом превращается в браузер?

Не совсем, пользователь использует браузер к которому он привык, просто в этот браузер заранее портрирован модуль импелементации к.л. плагина, интерфейса и пр., чего нет изначально в коробке.

к примере в FF нет поддержки ES6; пишем в коде '#include <ES6>' и тем самым добавляем эту поддержку из репозитория.
И это вполне реально сделать уже сейчас, в виде отдельных плагинов для браузеров.
Если бы у меня был вагон свободного времени я бы этим с большим удовольствием занялся))

не, я имею в виду, если изменится синтаксис javascript, как старые браузеры на это отреагируют?

молча))
Кстати о CoffeeScript, его можно использовать не только в связке с библиотеками типа jQuery, но и с тем же Node

[FINoM]

Вот вы как думаете, в чем причина такого "нетрезвого" взгляда и какой взгляд трезвый?

Если вопрос ко мне, то я не говорил что являюсь специалистом мирового класса. Просто не понимаю некоторых вещей, которые надеюсь понять.

Вот, например, в strict mode убрали arguments.callee. Спрашивается, почему? Это ведь так удобно при создании рекурсивных функций.

[FINoM]

А для чего тебе нужны классы и статическая типизация, м?

monolithed ответил за меня

-----
А зачем вообще этот CoffeeScript?
И почему нет компилятора новых версий ES для JS? По крайней мере я не нашел.

[monolithed]

А зачем вообще этот CoffeeScript?

Для того же что и все эти реализации.
Если уж речь зашла о CoffeeScript, то B. Eich уже давненько в ES6 решил реализовать некоторые идеи. А вот и его презентация на эту тему

[Kolyaj]

И почему нет компилятора новых версий ES для JS?

http://habrahabr.ru/blogs/javascript/118669/

[FINoM]

Для того же что и все эти реализации.

Всегда считал эдакой шуткой, ведь практического смысла в этом нет. А вокруг КофеСкрипта слишком много шума, чего мне не понять. Кстати, там Пролога почему-то нет.


Kolyaj, спасибо, гляну.

[Kolyaj]

А вокруг КофеСкрипта слишком много шума, чего мне не понять.

Это писали рубисты для рубистов. Ты, видимо, не рубист.