Это на самом деле гораздо более сложный вопрос, чем кажется на первый взгляд.
Основная причина этого заключается в том, что было очень трудно заставить поставщиков браузеров, посредством спецификации, реализовать любимые или любимые функции энтузиастов языка, пользователей, других поставщиков или ученых без очень веских оснований. Вот как мы закончили со спецификацией ES4 на столе, что привело к гораздо менее амбициозной (хотя все еще довольно крутой) ES Harmony. Такой язык, как JavaScript, который имеет такие безумно сложные политические проблемы развертывания и реализации, просто не может быть той удивительной экспериментальной площадкой, которой Ruby занимался большую часть своей жизни. Любой, кто следил за es-обсудить (список рассылки по развитию языка ECMAScript), вероятно, уже заметил, что для того, чтобы просто сформулировать и согласовать общеязыковые функции, такие как в недавней памяти, перегрузке операторов или кратком изложении, требуется много-много месяцев дискуссий и экспериментов. Форма лямбда-нотации.
Может быть, какая-то рабочая группа попросила бы написать слишком много спецификации, предназначенной для каждого устройства на планете? На первый взгляд может показаться, что это очень узкая группа уроков, даже социальных, которые можно легко перенести из Ruby в JavaScript.
Для этого и для облегчения бремени Брендана Эйха и его группы:
Одним из наиболее срочно полезных "уроков" для языка с точки зрения, вдохновленного Ruby (или LISP), будет изменчивость языка . Возможность представить новые функции, синтаксические взломы и специфичные для предметной области языки, не происходящие из внутренней клики авторов спецификаций, была бы невероятно ценной. Позвольте языку быть хорошим местом для создания модульных расширений языка, и чтобы эти расширения были самостоятельно размещенными , чтобы минимизировать риски фрагментации и позволить этим изменениям проникать и затираться вверх и т. д.
Такая гибкость позволила бы сообществу в целом применять уроки по самым разным направлениям и позволить Интернету со временем решить, какие уроки являются полезными для какого языка и т. Д. Мы уже получили высокую оценку Скорость итерации и эволюции происходит на других концах этого сэндвича, то есть в самих браузерах (например, HTML5) и в библиотеках js. Если бы это могло произойти более близко на уровне языка, мы бы увидели, что очень интересные вещи происходят очень быстро.
[добавление / редактирование]:
Язык должен значительно трансформироваться, потому что небольшая группа людей просто неспособна предвидеть все то, для чего она когда-либо будет использоваться. Тема, которая часто обсуждается в рамках es-обсудить, - это основополагающее направление разработки "языка на следующие 10-15 лет". ИМХО, это невероятно нереальная цель. Если вы не создадите его, система будет разрабатывать альтернативу задолго до предполагаемого срока службы спецификации. Благодаря огромному ускорению в Javascript Engine / JIT-технологии в последнее время мы уже видим первые признаки того, что это происходит в виде новых языков, написанных поверх JavaScript или кросс-компиляции на лету в JavaScript. Да, даже Руби: http://hotruby.yukoba.jp/