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