Закрытие BGGA как надёжное решение для Java?
Вчера @headius / Чарльз Наттер придумал в твиттере очень интересную идею:
@danny_l Gafter made the same mistake; I don't mean a forked Java any more than Groovy is a fork. I want a "mostly Java" with closures.
или ответ @danny_l / Дэнни Лагроу:
@headius or could the BGGA prototype be "bolted on" any future version of Java? That might be useful
Это действительно то, что я тоже хотел бы видеть. Разве мы не можем иметь какой-то препроцессор байт-кода, чтобы прототип BGGA работал в любой современной версии Java? Я имею в виду, что scala, Groovy и JRuby имеют замыкания и выдают действительный байт-код!
Я бы даже хотел помочь и приложить усилия. Хотя толком не знаю, с чего начать.
(выше - отрывок из Сообщение блога, который я написал по этой теме)
Что другие думают об этой идее?
Ответы 2
Проблема с закреплением этих вещей в том, что вы создаете фрагментированный язык.
Язык java - это наименьшая часть того, что делает java, java. Библиотеки и культура составляют большую часть. Закрепление замыканий и универсальных шаблонов на болтах означает, что они либо не могут использоваться в базовых библиотеках, либо для базовых библиотек потребуется, чтобы они присутствовали в используемом SDK. В лучшем случае это приведет к фрагментации внутри библиотек (поскольку некоторые разработчики работают с ядром, а некоторые требуют крепления на болтах), а в худшем случае будет означать, что мы начнем иметь `` дистрибутивы '' java в поместье java, каждый из которых будет содержать другой набор банок и «болтов».
Я бы сказал, что это начало скользкой дороги, от которой я бы предпочел держаться подальше.
Слово «препроцессор» возвращает меня к C++ и пугает.
Существует странная дихотомия: я приветствую разнообразие языков в JVM, но я думаю, что «Mama Bear» (он же Java) не должен становиться таким фрагментированным. Нам нужен прочный фундамент.
Тем не менее, я поддерживаю закрытие BGGA. Я также считаю, что язык должен обеспечивать все свои возможности. Если в команде есть люди, которые не могут обрабатывать замыкания (или обобщения, или многопоточность (!!)), тогда эта команда должна контролировать себя с помощью обзоров кода и статического анализа.
Возможно, одна из идей состояла бы в том, чтобы во время компиляции переключить такие расширенные функции, как эта, но даже это кажется немного резким.
Я думаю, что эта идея действительно пытается решить проблему раздробленного лидерства в пространстве Java. Эта проблема кажется скорее политической и дипломатической, чем технической.