Зря его не хватит на то, чтобы изучить внутренности OpenJDK до того уровня, чтобы не написать туда ещё своих багов.
Но в одном вы правы, здесь время можно только потратить.
Не понял вашу агрессию на ровном месте. Я вообще задался вопросом как же так получилось и ваш ответ никак не пролил на него свет. И тот факт, что я бы пофиксил пару багов также никак не приблизил бы лямбды.
У Одерски тоже есть такой пример qsort. Но он там обращает внимание читателя на накладные расходы. Возможно при относительно небольшом количестве данных подобный подход допустим с целью минимизировать количество ошибок.
А вообще это первое, в чем упрекают функциональный подход.
Со скалой трудно разобраться с наскоку, особенно после java. Там нужно очень много примеров и время подумать над каждым. Конечно однодневный формат такой возможности не дает.
Идея конечно хорошая. Но как можно заставить провайдера ей следовать? Ведь если он что-то действительно неугодное вывесит, то некие люди могут к нему и в офис прийти поговорить об этом, о разных внеплановых проверках и о лицензии на крайний случай. А конкуренция в этой сфере сейчас большая.
На счет многословности могу сказать только одно. Она предотвращает огромное количество ошибок. И как я сказал уже, если добавить выведение типов по Хиндли-Милнеру, то останется только самое необходимое. Но даже без него оверхед по сравнению с текущим синтаксисом процентов на 50%, что прямо скажем не кошмар.
На счет комментариев и минификаторов только добавлю, что выход есть и тут. Либо все аннотации начинать со спец. символа (как например в java @), чтобы минификаторы понимали, что их не нужно вырезать. Либо же аннотации были бы все описаны в стандарте и минификаторы опять же могли смотреть, что вырезать, а что нет.
Не то чтобы совсем исключает. Просто нужну было бы подключать библиотеку с функциями заглушками и это бы особо не тормозило браузеры без поддержки asm.js.
А вариант с аннотациями точно был бы немного быстрее (опять же без поддержки asm), т.к. не приходилось бы интерпритировать/оптимизировать кучу странных конструкций. Плюс к этому не нужно было бы вспоминать, что (1|0) — это int, т.к. можно было бы написать
/*int*/ var i = 1 или
var i = /*int*/ 1
Если добавить сюда вывод типов (не знаю, реализованно ли это сейчас), то избыточность была бы минимальной.
Я бы сказал, что синтаксис простого ассемблера более читабелен. И здесь не было никаких проблем сделать синтаксис основанный, например, на неком наборе функций, который был бы понятен и людям.
А ещё один вариант — аннотации.
В общем, тут есть свобода для более красивой реализации.
В этой статье мы видели пример того, как пришлось напрямую писать на asm.js. Кроме того есть куча библиотек, которые захотят улучшить производительность в критических местах. Им же не переходить ради этого на другие языки. Поэтому в результате получится, что очень многим программистам придется напрямую копаться в таком коде.
На самом деле я предполагаю, что не всем захочется заморачиваться с продажей. К тому же даже продукция apple иногда надоедает её пользователям и они могут захотеть попробовать что-то другое.
Можно сказать, что износ не грозит двигателю после 50000 км. Но как новый вы его не продадите. Я именно про это сейчас говорю, а не про то, что он должен сгореть с искрами.
Но в одном вы правы, здесь время можно только потратить.
А вообще это первое, в чем упрекают функциональный подход.
А вариант с аннотациями точно был бы немного быстрее (опять же без поддержки asm), т.к. не приходилось бы интерпритировать/оптимизировать кучу странных конструкций. Плюс к этому не нужно было бы вспоминать, что (1|0) — это int, т.к. можно было бы написать
/*int*/ var i = 1 или
var i = /*int*/ 1
Если добавить сюда вывод типов (не знаю, реализованно ли это сейчас), то избыточность была бы минимальной.
А ещё один вариант — аннотации.
В общем, тут есть свобода для более красивой реализации.