Слайды "ECMAScript 6"

[Dmitry A. Soshnikov]

Слайды с DevConf "ECMAScript > Будущее"

http://www.slideshare.net/dmitrysosh...ript-6-8211902

[x-yuri]

Положительное будущее Хотя не могу сказать, что мне его не хватает. Меня, например, больше интересует, как планируется его воплощать в жизнь. Может быть, предусматривается что-то на подобие feature detection? И ожидается ли статическая типизация и классы?

[monolithed]

Слайды с DevConf "ECMAScript > Будущее"

на прошлой неделе как раз наткнулся на эти слайды, интересно только про Proxy хотелось бы по больше узнать в частности о расширении синтаксических конструкций.
Эта тема меня просто покорила, как я понял Brendan Eich хочет реализовать часть парадигмы из CoffeeScript и Python, за что ему нужно отдать должное т.к. расширение в сторону функционального программирования это большой прогресс для языка.

Хотя не могу сказать, что мне его не хватает

если уж Brendan Eich считает синтаксис JavaScript морально устаревшим, то нововведения не будут лишними и их не нужно боятся))

Меня, например, больше интересует, как планируется его воплощать в жизнь.

Печально, но похоже так же как и сейчас, в этой ветке Brendan Eich говорил, что старый синтаксис тоже сохранится (к примеру если появится arrow syntax, то function никуда не денется, вроде как невозможно избавится, по крайней мере пока).

И ожидается ли статическая типизация и классы?

Тут где-то поднимался этот вопрос, и мне почему-то помнится, что это запланировано в ES7 (Strawman)
Есть такая штука как Traceur для тестирования будущих фишек.
Вообще у меня есть желание написать плагин для браузеров, который бы реализовывал возможности будущих версий. Не с кем проконсультироваться на эту тему((

Кстати вот очень интересный доклад на эту же тему от Brendan Eich'a

PS: константы из ES6 уже сейчас поддерживают все браузеры кроме IE!

const foo = function(a) {
     return a;
};

alert(foo(10));

PS: Дмитрий, какие требования к участникам комитета TC-39?

[x-yuri]

Эта тема меня просто покорила, как я понял Brendan Eich хочет реализовать часть парадигмы из CoffeeScript и Python, за что ему нужно отдать должное т.к. расширение в сторону функционального и императивного программирования это большой прогресс для языка.

императивного? Ты не ошибся?

если уж Brendan Eich считает синтаксис JavaScript морально устаревшим, то нововведения не будут лишними и их не нужно боятся))

я их не боюсь, я их не жду

Печально, но похоже так же как и сейчас, в этой ветке Brendan Eich говорил, что старый синтаксис тоже сохранится (к примеру если появится arrow syntax, то function никуда не денется, вроде как невозможно избавится, по крайней мере пока).

а я думал, это должно печалить только разработчиков реализаций

PS: константы из ES6 уже сейчас поддерживают все браузеры кроме IE!

вот и я о том же. Если это какой-нибудь новый метод, можно проверить есть ли он и воспользоваться своей реализацией, если нету. Или еще что-нибудь сделать. Если же это синтаксис... надо ждать пока браузеры начнут это поддерживать. Но "начнут это поддерживать" - довольно расплывчатое условие. А так как не очень-то и хотелось, можно расслабиться

[monolithed]

императивного? Ты не ошибся?

многие языки поддерживают эту парадигму, но на мой взгляд в JS она как-то "вяло" проявляется. То что мы имеем сейчас в отличии от того же Python, мало похоже на это

[Dmitry A. Soshnikov]

Меня, например, больше интересует, как планируется его воплощать в жизнь. Может быть, предусматривается что-то на подобие feature detection?

Вообще, основная идея звучит как "не ломать Web". В идеале это означает, что старый код должен работать на новых движках.

В реальности же, естественно будут появляться какие-то несовместимые синтаксические конструкции, которые повлекут за собой эту самую "поломку" старого кода. Однако, это то, что Brendan Eich называет "a migration tax" (т.е. амортизация, накладные расходы) -- то, ради чего все-таки можно пожертвовать старым кодом. Это, как правило, очень важные конструкции, которые заслуживают, чтобы "ими можно было поломать web" (какие именно -- можно посмотреть здесь -- http://wiki.ecmascript.org/doku.php?...mony:proposals).

Для этого скорей всего будет введено версионирование (например, не type="text/javascript", а type="application/ecmascript;v=6").

И ожидается ли статическая типизация и классы?

Классы как раз сейчас активно обсуждаются в es-discuss, очень велика вероятность, что они будут -- как сахар над делегацией (такие же классы, как Python и CoffeeScript, которые оба являются прототипными языками).

Насчет статической типизации -- нет, нет активных обсуждений. Но будут типизированные массивы (уже есть) и структурированные типы -- для эффективного использования памяти и быстрого к ней обращения. Типы так же фигурируют в предложении value_proxies, но это тоже пока только обсуждается и не окончательно утверждено. Самих же статических типов на уровне языка -- нет, нет активного обсуждения по этому поводу.

как я понял Brendan Eich хочет реализовать часть парадигмы из CoffeeScript и Python

Да, но JS и так уже (еще в ES3) многое взял из Python (оба языка писались в одно время -- в 1995 году). CoffeeScript -- да, очень классный язык, и Brendan (спустя год, после того, как я упомянул его на es-discuss и предложил -> функции) сам увлекся Coffee и уже сам, через год, заговорил о них.

В целом же, -> не новация Coffee, стрелка тесно связана с функциями еще с математики, стрелка -- это тип функции в типизированном лямбда-исчислении, стрелки-функции использутся во многих других языках, которые появились задолго до JavaScript и CoffeeScript -- например, Erlang -- 1986 год, -- кстати, это язык на котором я программирую сейчас на моей основной работе; Haskell тоже стрелки использует для функций. Так что, не нужно бояться стрелок -- они вполне себе ассоциированы с функциями (просто я слышал на Twitter высказывания вроде "как эти символы связаны с функцией вообще?" -- самое интересное -- самым прямым способом ).

нововведения не будут лишними и их не нужно боятся

Абсолютно.

PS: константы из ES6 уже сейчас поддерживают все браузеры кроме IE!

В Opera они просто синоним var.

многие языки поддерживают эту парадигму, но на мой взгляд в JS она как-то "вяло" проявляется

В JS императивное программирование проявлено достаточно полно (изменяемое состояние, последовательные инструкции и т.д.). Как, впрочем, и часть функционального.

[x-yuri]

Эта тема меня просто покорила, как я понял Brendan Eich хочет реализовать часть парадигмы из CoffeeScript и Python, за что ему нужно отдать должное т.к. расширение в сторону функционального и императивного программирования это большой прогресс для языка.

Я просто не понял, где там расширение в сторону фукционального/императивного программирования. Просто синтаксис упростили

А по поводу императивного программирования, по-моему как раз только оно и проявляется. Императивное программирование - это когда ты указываешь последовательность действий и есть состояние. Функциональное программирование - это совсем другой подход к проблеме: ты описываешь как решить задачу, но не указываешь последовательность действий. Я бы сказал, что это императивный язык, заимствующий идеи из функциональных языков.

[x-yuri]

...

Классы как раз сейчас активно обсуждаются в es-discuss, очень велика вероятность, что они будут -- как сахар над делегацией (такие же классы, как Python и CoffeeScript, которые оба являются прототипными языками).

а python разве прототипный?

хм, а coffeescript используется в реальных проектах?

и я тут не так давно натыкался на на письмо Брендана Айка

...
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.
...

в котором он говорит о чем-то близком. Но непонятно, о каком раннем связывании идет речь, почему оно не возможно и как это влияет на классы (а может и на статическую типизацию). И кстати, о "замораживании" объектов сейчас речь не идет в контексте классов?

[FINoM]

Вообще у меня есть желание написать плагин для браузеров, который бы реализовывал возможности будущих версий. Не с кем проконсультироваться на эту тему

Эм, а в чем сложность? Компилятор ведь имеется.

[monolithed]

Эм, а в чем сложность?

на первый взгляд ничего, но есть моменты, которые для меня пока не понятны...

Компилятор ведь имеется.

в каком смысле?