Fermetures BGGA comme une solution de java?

Question

Yesterday/Charles Nutter est venu avec une idée très intéressante sur twitter:

@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. 

ou la réponse @danny_l/Danny Lagrouw:

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

qui est vraiment ce que je voudrais voir aussi. Ne pouvons-nous pas avoir une sorte de préprocesseur bytecode pour faire fonctionner le prototype BGGA sur n'importe quelle version Java moderne? Je veux dire scala, Groovy et JRuby ont des fermetures et produisent un bytecode valide! Je voudrais même aider et mettre de l'effort dedans. Bien que je ne sache pas vraiment par où commencer.

(ci-dessus est un extrait du blogpost je l'ai écrit sur ce sujet)

Que les autres pensent de cette idée?

Answer 1

Le mot «préprocesseur» me ramène en C++ et me fait peur.

Il y a une étrange dichotomie: je célèbre le jardin des langues sur la JVM, mais je pense que "Mama Bear" (alias Java) ne devrait pas devenir fragmenté comme ça. Nous avons besoin de bases solides. Cela dit, je suis en faveur des fermetures BGGA. Je pense aussi qu'un langage devrait fournir toutes ses capacités. Si une équipe a des gens qui ne peuvent pas gérer les fermetures (ou les génériques, ou le threading (!!)), alors cette équipe devrait se contrôler par des critiques de code et une analyse statique. Peut-être une idée serait d'avoir un changement à la compilation pour 'interdire' les fonctionnalités avancées comme celle-ci, mais même cela semble un peu dur.

Je pense que l'idée du 'boulon' tente vraiment de résoudre le problème du leadership fracturé dans l'espace Java. Ce problème semble plus politique et diplomatique que technique.

Answer 2

Le problème avec ces éléments est que vous créez un langage fragmenté.

Le langage java est la plus petite partie de ce qui fait java, java. Les bibliothèques et la culture constituent la plus grande partie. Faire des fermetures et des génériques un verrou signifie qu'ils ne peuvent pas être utilisés dans les bibliothèques de base ou que les bibliothèques de base nécessiteraient que le verrou soit présent dans le SDK utilisé. Cela créerait au mieux une fragmentation au sein des bibliothèques (car certains développeurs travaillent au noyau et d'autres exigent le boulonnage) et au pire signifierait que nous commencerons à avoir des 'distributions' de Java dans le manoir de Java contenant chacune un ensemble différent de bocaux et de 'bolt-ons'.

Je dirais que c'est le début d'une pente glissante que je préfère rester hors de.