Robert C. Martin (Uncle Bob) svolil k překladu svého článku Make the Magic go away (z roku 2015).

Díval jsem se na rxJava. Jde o pěkný malý framework, který pomáhá vytvářet a spravovat obser­very. Zdá se, že filozofií návrhu je, že vše může být pozorováno, vše tudíž může být spravováno callbacky.

To je samozřejmě velmi stará myšlenka, které se datuje už pro data flow jazyky, funkcionální a jiné dekla­ra­tivní jazyky. Tato myšlenka měla dokonze dozvuk v pozdních 90. letech, kdy byla poprvé vydána kniha GOF. Ti z vás, kteří v té době progra­mo­vali, si možná pamatu­jete, že několik měsíců si každý myslel, že návrhový vzor observer je tak úžasný. Viděli jsme mnoho špatných návrhů posta­vených nad obser­ve­rem. Pak se to zasta­vilo, protože takový návrh byl příliš nepřímý. Kód bylo obtížné debugo­vat. (Testoval to někdo?)

Neříkám, že rxJava je špatný nápad. Jak říkám, vypadá celkem pěkně. Jen že to není úplně nová myšlenka. Ostatně co je?

Nekonečný úkol

Autoři rxJava, Spring, JSF, JPA, Struts a [dosaďte svůj oblíbený framework] všichni hledají stejnou věc. Tyto fameworky vznikly kvůli frust­raci z jazyka a jsou pokusem daný jazyk zlepšit.

Každý framework, který jste viděli, je ve skuteč­nosti jen ozvěnou výroku:

Můj jazyk stojí za starou belu!

A tak píšeme frameworky, abychom kompen­zo­vali vlast­nosti, které bychom si přáli mít v našem jazyce. A když to nezafun­guje, tak, jako James Gosling, Bjarne Stroust­rup, Alan Kay, Brad Cox, Dennis Ritchie, Rich Hickey a mnoho mnoho dalších, píšeme nový jazyk.

Nový jazyky! Zlatý! Čistý! Perfektní! Nový jazyk vyřeší všechny nedostatky. Nový jazyk, který nahradí všechny ostatní. Nový jazyk, který odpoví na všechny stížnosti, vyřeší všechny slabiny a urovná veškeré spory. Nový jazyk, kterým se lze snadno vyjádřit, je bezpečný, úsporný, hutný, pružný, discip­li­no­vaný a a a — perfektní!

Bzzz! Špatná odpověď!

Samozřejmě že taková bestie neexi­s­tuje. Není perfekt­ního jazyka. A v neposlední řadě, všechny „nové“ jazyky už tu byly, jsou to jen předělávky té samé staré … té samé staré … té samého staré věci. Upřímně si nemys­lím, že by od pozdních 70. a raných 80. let vznikla nová myšlenka v progra­mo­vacích jazycích.

Myslím tím, že pokud jste jednou progra­mo­vali v Assem­b­ler, FORTRAN, C, Pascal, C++, Small­talk, Lisp, Prolog, Erlang a Forth, tak jste je viděli všechny. Ach, předpok­ládám, že byste mohli nadhodit jazyky jako Snobol, ML, Cobol, and XSLT (chce se mi zvracet). Ale většina jejich myšlenek již byla pokryta předchozím seznamem.

To samé platí pro frameworky. Kdy jste napos­ledy viděli framework s opravdu novou myšlen­kou? Pro mě to byl framework Inside Macintosh napsaný v Pascalu v pozdních 70. a raných 80. letech. A to ve skuteč­nosti bylo jen předělání o pár let staršího Small­talk frameworku.

Co je nového v software?

Za posled­ních třicet let celkem nic.

Santayanova kletba

Tak proč pokrač­u­jeme ve psaní nových jazyků a frameworků? Myslím, že odpověď je velmi snadná:

Ti, kdo si nepama­tují minulost, jsou odsou­zeni k tomu ji opakovat.

Jorge Agustin Nicolas Ruiz de Santayana y Borras

Jinými slovy, každá nová skupina programátorů, která přijde, je předurčena (odsou­ze­na!) k tomu, přepsat ty samé staré jazyky a ty samé staré frameworky. Hm, budou vypadat trochu jinak a budou nepatrně jinak natoč­ené, ale nebudou nové v ničem smysluplném.

Některé z těchto jazyků a frameworků získají jistou nechvalnou proslu­lost a stanou se na chvíli populární, jako kdyby byly něco nového a kouzel­ného, ale to bude jen iluze způso­bená pohledem z krátko­dobého hlediska. Zastánci těchto „nových“ jazyků a frameworků budou hlasitě prohlašo­vat, jak moc rychleji můžete progra­mo­vat, jak snadněji můžete postavit systém a jak lépe jsou ty systémy navržené. Ale nakonec budou programy psány stejnou rychlostí jako předtím, obtížnost bude ohromná jako dřív a návrh bude stále stejně špatný.

Kouzlo!

Proč se to děje? Proč lidé stále pátrají po dalším novém jazyku a dalším novém frameworku? Proč se stále dokola točíme na tomto kolotoči frameworků a jazyků v naději, že při další otočce uvidíme novou scenérii? Proč doufáme v kouzlo?

Doufáme v kouzla, protože věříme na kouzla. Používali jsme jazyky, jejichž chování se zdá magické. Používali jsme frameworky, které dělají magické věci. A v naší naivitě věříme tomu, že prostě můžeme shromáždit o trochu víc takového kouzla a pak při příštím otočení kolotoče se náhle objeví perfektní jazyk nebo perfektní framework.

Žádné kouzlo

Ale žádné kouzlo neexi­s­tuje. Jsou to jen jedničky a nuly manipu­lovány mimořádnou rychlostí absurdně jedno­duchým strojem. Tyto stroje potře­bují diskrétní a detailní instrukce, které jsem povinni pro ně psát.

Myslím, že lidé by se měli co nejdříve naučit assem­b­ler. Nečekám, že budou assem­bler používat dlouhou dobu, protože práce v assem­bleru je pomalá a boles­tivá (a radost­ná!). Cílem mé obhajoby assem­bleru je, ujistit se, že kouzlo je zničeno.

Pokud jste nikdy nepra­co­vali se strojovým kódem, je pro vás téměř nemožné opravdu pocho­pit, co se děje. Když progra­mu­jete v Javě, C#, C++ nebo dokonce v C, tak tam je kouzlo. Ale potom, co jste napsali nějaký strojový kód, kouzlo zmizí. Uvědomíte si, že byste mohli napsat kompilátor C ve strojovém kódu. Uvědomíte si, že byste mohli napsat JVM, kompilátor C++ nebo inter­preter Ruby. Zabralo by to trochu času a úsilí, ale mohli byste to udělat. Kouzlo je pryč.

A když je kouzlo jednou pryč, tak na věc máte jiný pohled. Díváte se na jazyk jako C, Java nebo C# jako na jiné vyjádření strojového kódu. Podíváte se na řádek kódu v C a můžete „vidět“ instrukce, které generuje. Podíváte se na řádek kódu v Java a můžete si vizua­li­zovat instrukce vykonané JVM. Není v tom záhada, tajem­ství ani kouzlo. Víte, že kdybyste museli, mohli byste to vše napsat ve strojovém kódu.

To samé platí pro frameworky. Pokud jste někdy psali jedno­duchý webový server (jedno jak jedno­duchý), pokud jste psali kód, který poslouchá socket, rozba­luje HTTP request packet, generuje HTML a balí ho do HTTP response packetu, ten zapisuje zpět do socketu, tak kouzlo je pryč. Víte, jak napsat webový server. To vrhá úplně jiné světlo na jakýkoliv webový framework, který byste byli v pokušení použít.

Pokud jste někdy psali jedno­duchý depen­dency injec­tor, XML parser, observer generátor nebo query generátor, tak jste kouzlo odehnali. Mohli byste napsat framework, kdybyste potře­bo­vali. Nebo byste mohli napsat kód ve vaší aplikaci, když bude potřeba. Nepotře­bu­jete něčí framework.

To vrhá na framewok úplně jiné světlo. Nepotře­bu­jete ho. A když ho nepotře­bu­jete, tak nad vámi nemůže mít žádnou moc. Můžete se podívat z čeho je: jen obyčejný starý kód a možná o moc víc kódu, než vlastně potřebujete.

Nyní můžete posou­dit, zda náklady všeho toho kódu mají nějaký přínos. Možná existuje jedno­dušší framework, který to zvládne stejně dobře. Možná nepotře­bu­jete vůbec žádný framework. Možná, možná byste měli napsat trochu kódu, který potře­bu­jete, místo impor­tování tisíce a tisíce řádek do vašeho projektu. Řádky, které jste nenapsali. Řádky, které nemáte pod kontro­lou. Řádky, ve které byste nejspíš neměli vkládat tolik důvěry.

Moje rada

Nevěřte kouzlům! Předtím, než se uvážete k nějakému frameworku, se ujistěte, že byste ho mohli napsat. Zkuste napsat něco jedno­duchého, co dělá základní věci, které potře­bu­jete. Ujistěte se, že kouzlo zmizelo. Pak se podívejte na framework znovu. Stojí za to? Dokážete bez něj žít?