sobota 5. ledna 2008

Closures: opravdu děkuji, ale nechci

Po přečtení výborného článku Java: Evolutionary Dead End z pera Bruce Eckela a prohlédnutí prezentace Closures controversy Joshuy Blocha ve mě definitivně uzrálo přesvědčení, že closures opravdu, ale opravdu v Jave nechci.

Souhlasím s Blochem v tom, že na komplexnost dané vlastnosti jazyku není možné nahlížet izolovaně, ale musíme na ni nahlížet v kombinaci s všemi dalšími vlastnostmi jazyku. To samozřejmě znamená netriviální zvýšení komplexnosti, kterou sebou každá nová vlastnost přináší.

...that it's not just the complexity of a particular feature in isolation, where it can often seem fairly straightforward. It's the combinatorial complexity that you get when you combine a new feature in every possible way with the other language features. When you shoehorn a feature into an existing language rather than carefully designing it in from the beginning, you cannot control how that feature combines with other existing features. The combinatorial complexity can produce horrifying surprises, typically after the feature is added when it's too late to do anything about it.

Krasným potvrzením výše vyřčeného jsou generické typy (generiky) přidané do Javy 1.5. Dovolím si odcitovat z článku BGGA closures: The end of many Java careers.

It would be a mistake to evaluate the complexity of BGGA in isolation. Indeed, the 427 page generics FAQ, for instance, doesn't talk about generics in isolation. In reality, it is the interaction of generics with other language features that makes generics so hard to master. Its a curious coincidence that Angelika Langer on the generics FAQ thanks 3 of the 4 BGGA authors for patiently answering "countless questions posed" regarding generics. You'd expect that the BGGA authors' first initiative would be to simplify generics and make its behavior & interaction with other language features more predictable, instead of attempting to make changes that further convolute the type system and add cognitive load to the language for little benefit.

Je na místě si položit otázku, co stojí za snahou rozšířit Javu o closures. Eckel nabízí zajímavou paralelu pro generiky.

This was remarkably coincidental with the appearance of generics in C#, which also appeared to produce several other features in Java 5. It seems that the urgency of these features came not from solving true problems in the Java language, but in Sun trying to maintain the perception of competitiveness against Microsoft's C#. This is probably not so far off the mark, because the reason that Java had to be rushed out in rough form in the first place was the belief that there was a market window that must be captured. A programming language designed by following marketing impulses is eventually going to end up chasing its tail.

Z mého osobního pohledu nepřináší BGGA návrh Closures (BGGA je akronym složený z prvních písmen příjmení autorů návrhu, tedy: Gilad Bracha, Neal Gafter, James Gosling, Peter von der Ahé) téměř žádnou výhodu oproti problémům, které nastanou.

Moje problémy s closures:

  • vzroste složitost syntaxe vedoucí ke kódu, který bude těžko čitelný a spravovatelný
  • nejasný problém kolem komplexnosti vzhledem k dalším vlastnostem jazyku
  • zpětně nekompatibilní změna
  • nejasná motivace, komu to prospěje?

Snaha udělat z Javy multiúčelový jazyk, alespoň tak se mi to zdá v případě closures, se ve výsledku obrátí proti Jave samotné - myšleno jazyku. Povede k tomu, že po rysech z funkcionálních jazyků se do syntaxe začnou přidávat rysy například jazyků určených pro konkurenční zpracování jako Erlang. Infrastruktura Javy, tedy JVM, nabízí dostatek možností, abychom mohli speciální požadavky realizovat jazyky, jejichž design byl navržen s ohledem na tyto požadavky.

Bloch ve svojí prezentaci nabízí zjednodušenou formu closures. Ja bých jeho návrh označil za takové syntaktické cukrátko. A to je pro mě osobně asi maximum toho, co jsem schopen akceptovat v dobré víře jako alternativu anonymních vnitřních tříd.

Starší související články