BGGA замыкания как решение java?

Question

Вчера @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 / Danny Lagrouw:

@headius or could the BGGA prototype be "bolted on" any future version of Java? That might be useful 

Это действительно то, что я тоже хотел бы увидеть. Разве мы не можем иметь какой-то препроцессор байт-кода, чтобы заставить прототип BGGA работать на любой современной версии Java? Я имею в виду scala, Groovy и JRuby имеют замыкания и выдают действительный байт-код!

Я бы даже хотел помочь и приложить усилия. Хотя я не знаю, с чего начать.

(выше приведен отрывок из блога Я писал об этой теме)

Что другие думают об этой идее?

Answer 1

Слово «препроцессор» возвращает меня к C ++, и это пугает меня.

Существует странная дихотомия: я отмечаю разнообразный сад языков на JVM, но я думаю, что «Мама Медведь» (он же Ява) не должна становиться раздробленной вот так Нам нужен прочный фундамент.

Тем не менее, я за закрытие BGGA. Я также считаю, что язык должен обеспечивать все возможности. Если в команде есть люди, которые не могут обрабатывать замыкания (или обобщения, или многопоточность (!!)), то эта команда должна контролировать себя посредством анализа кода и статического анализа.

Возможно, одной из идей было бы иметь переключатель времени компиляции, чтобы «запретить» расширенные функции, подобные этой, но даже это кажется немного резким.

Я думаю, что идея «на болтах» на самом деле пытается справиться с раздробленным лидерством в пространстве Java. Эта проблема представляется скорее политической и дипломатической, чем технической.

Answer 2

Проблема с тем, чтобы сделать все это, заключается в том, что вы создаете фрагментированный язык.

Язык Java - это самая маленькая часть того, что делает Java, Java. Библиотеки и культура составляют большую часть. Создание замыканий и обобщений как болта означает, что либо они не могут использоваться в базовых библиотеках, либо для того, чтобы базовые библиотеки требовали присутствия болта в используемом SDK. В лучшем случае это приведет к фрагментации внутри библиотек (поскольку некоторые разработчики работают с ядром, а некоторые требуют поддержки), а в худшем случае это будет означать, что в поместье java у нас начнутся «распределения» java, каждый из которых будет иметь свой банок и болтов.

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