Filozofia inżynierii: Rich Hickey, proste to nie to samo co łatwe

Najważniejsze wnioski

• Proste to nie to samo co łatwe. Proste znaczy nieposplatane — jedna sprawa na jedną rzecz — i jest obiektywne; łatwe znaczy znajome i będące pod ręką, i jest subiektywne. Nieustannie wybieramy to, co łatwe, a nazywamy to prostym.
• Splatanie jest źródłem złożoności. Złożoność to nie liczba części, lecz stopień ich poplątania. Spleść stan z czasem, tożsamość z zachowaniem albo zasadę z mechanizmem — oto co tworzy system, nad którym można już tylko się modlić.
• Rozplątuj bez ustanku. Wyciągaj posplatane sprawy do niezależnych elementów, które potem świadomie składasz. Prostota to „wybór”, który „wymaga nieustannej czujności” — nigdy nie przychodzi sama, gdy sięga się po znajome narzędzie.
• Stawiaj wartości ponad miejsca, dane ponad obiekty. Uczyń niezmienność stanem domyślnym i pozwól przeszłości gromadzić się jako niezmienne fakty, zamiast nadpisywać stan w miejscu — to dyscyplina, na której wsparte są zarówno Clojure, jak i Datomic.

Zasada

„Korzeniami tego słowa są »sim« i »plex«, co znaczy »jeden zwój lub splot« […] tuż obok, w opozycji do »complex«, co znaczy »spleciony razem« albo »złożony razem«.” — Rich Hickey, Simple Made Easy¹

Niemal każdy spór o jakość oprogramowania to w rzeczywistości dwa spory ukryte pod jednym słowem, a wkładem Richa Hickeya jest ich rozdzielenie. Proste i łatwe nie są synonimami. Nie leżą nawet na tej samej osi: jedno mierzy samą rzecz, drugie mierzy odległość, jaka cię od niej dzieli. Proste pochodzi od łacińskiego simplex — jeden zwój, jeden splot, jeden skręt. Opisuje samą rzecz: ile spraw jest w niej przeplecionych. Jest obiektywne, a jego przeciwieństwem jest złożone — spleciony razem, zwinięty sam na siebie. Łatwe wywodzi się natomiast od rdzenia oznaczającego „leżeć blisko”, tego samego, od którego pochodzi przyległy.² Łatwe opisuje twoją relację z rzeczą: jak blisko jest pod ręką, jak znajome, jak niewiele wysiłku wymaga, by zacząć. Jest subiektywne, a jego przeciwieństwem jest trudne.¹²

Gdy raz dostrzeże się to rozróżnienie, nie da się go już przestać widzieć. Narzędzie, po które sięgasz, bo dzieli cię od niego jedno npm install, jest łatwe. Czy jest proste — czy splata trwałość danych z walidacją, walidację z interfejsem, a interfejs z regułami biznesowymi — to zupełnie osobne pytanie, na które odpowiedź najczęściej brzmi: nie. Wybieramy to, co łatwe, bez przerwy i nazywamy to prostym, a potem toniemy w złożoności, którą sami zaprosiliśmy. Hickey ma na samą czynność plątania swoje słowo — complect (splatać): „przeplatać, zwijać razem lub splatać”.³ Splatanie to grzech pierworodny. To ono zamienia system, o którym można było rozumować, w taki, nad którym można już tylko się modlić, bo gdy dwie sprawy zostają ze sobą splecione, nie da się dotknąć jednej, nie rozumiejąc drugiej i nie ryzykując jej.

Dyscyplina polega więc na rozplątywaniu — na bezustannym wyciąganiu posplatanych spraw do niezależnych elementów — a Hickey nie owija kosztu w bawełnę. „Prostota to wybór”, mówi. „To twoja wina, jeśli nie masz prostego systemu”.⁴ Nie bierze się ona z sięgnięcia po znajome narzędzie; bierze się z „nieustannej czujności” i świadomej dbałości.⁴ Oto cała zasada w czterech słowach: proste to nie łatwe. Prostota jest tą trudniejszą, wybraną, nieposplataną drogą i jako jedyna procentuje. To samo przekonanie leży u podstaw argumentu, że jakość jest jedyną zmienną — do czystego systemu nie wchodzi się tylnymi drzwiami, robiąc za każdym razem wygodny krok; wybiera się go, pod prąd, za każdym razem.

Kontekst

Rich Hickey to niezależny programista, który przez mniej więcej dwie dekady zarabiał na życie pisaniem systemów w C++, Javie i C#, zanim zbudował to, z czego jest znany.⁵ Wiedział, jak tworzyć w tych językach wielkie systemy, a jego wniosek po dwudziestu latach nie był taki, że brakowało im funkcji. Był taki, że są maszynami do splatania — bez wysiłku pozwalają spleść ze sobą sprawy i niemal w niczym nie pomagają je rozdzielić.

Zbudował więc alternatywę sam. Począwszy od mniej więcej 2005 roku Hickey spędził około dwóch i pół roku, rozwijając Clojure — w dużej mierze z własnych środków, pracując bez wynagrodzenia nad Lispem dla Java Virtual Machine, który miał uczynić niezmienność i prostotę ścieżką najmniejszego oporu, a nie aktem heroizmu.⁵ Udostępnił go publicznie w 2007 roku. Nie stała za tym żadna firma, żaden komitet, żaden grant. Był to jeden programista, który zobaczył chorobę z bliska i postanowił poświęcić lata własnej rezerwy na budowę lekarstwa. Później stworzył Datomic, niezmienną bazę danych,⁵ i wygłosił serię prelekcji konferencyjnych — Simple Made Easy, The Value of Values, Hammock-Driven Development, Are We There Yet? — które łącznie tworzą najbardziej wpływowy zbiór filozofii projektowania we współczesnym programowaniu funkcyjnym.⁶

Dzieło

Simple Made Easy: proste kontra łatwe, i splatanie

Wygłoszona na Strange Loop we wrześniu 2011 roku prelekcja Simple Made Easy to wystąpienie, które na nowo uporządkowało sposób, w jaki całe pokolenie programistów mówi o złożoności.¹ Cała jej siła bierze się z odmowy uznania, że proste i łatwe znaczą to samo. Proste dotyczy konstrukcji — czy jest jednym zwojem, czy wieloma splecionymi razem? Łatwe dotyczy ciebie — czy jest pod ręką, znajome, w zasięgu twoich obecnych umiejętności? Można mieć rzeczy proste, lecz nieznajome (trudne do nauczenia, łatwe w codziennym życiu) oraz rzeczy łatwe, lecz złożone (znajome, wygodne i po cichu zgubne). Większość tego, co branża sprzedaje jako produktywność, należy do tej drugiej kategorii.¹

Czasownikiem w samym środku jest complect — splatać, przeplatać, zwijać razem.³ To splatanie czyni system złożonym — nie liczba części, lecz stopień ich poplątania. Stan splata wartość z czasem. Obiekty splatają stan, tożsamość i zachowanie. Dziedziczenie, ORM-y, instrukcje warunkowe rozsiane po metodzie — każde z nich splata sprawy, które mogły stać osobno. A koszt splotu nie jest płacony raz; jest płacony przy każdej przyszłej zmianie, bo nie da się już dotknąć jednej nici, nie naruszając wszystkich pozostałych.

Lekarstwem jest rozplątywanie — rozdzielanie nici na niezależne rzeczy, które można złożyć później, na własnych warunkach. Twierdzenie Hickeya, mocne twierdzenie, brzmi, że rozplątywanie nie jest utratą mocy. „Można napisać tak samo wyrafinowany system, dysponując dramatycznie prostszymi narzędziami”, mówi — te same programy, tyle że takie, o których naprawdę da się rozumować, które da się zmieniać i którym da się ufać.⁴ Prostota nie jest podzbiorem możliwości przeznaczonym dla początkujących. Jest dyscypliną eksperta, który odmawia splatania.

Clojure: Lisp dla JVM, dane ponad obiektami

Clojure to zasada uczyniona wykonywalną: dynamiczny, funkcyjny dialekt Lispa działający na JVM, zaprojektowany przez Hickeya jako „Lisp dla programowania funkcyjnego, działający w symbiozie z ustanowioną platformą zaprojektowaną z myślą o współbieżności”.⁷ Filozofię kodują dwie decyzje. Po pierwsze, niezmienność jest stanem domyślnym, a nie opcją — podstawowe struktury danych Clojure są niezmienne i trwałe, więc to, co najnaturalniej się pisze, jest zarazem tym, czego nie może uszkodzić odległa mutacja.⁷ Po drugie, dane ponad obiektami: zamiast rozrostu szytych na miarę klas, z których każda ma wpleciony prywatny stan i zachowanie, Clojure stawia na „wiele funkcji zdefiniowanych na niewielu podstawowych strukturach danych” — sekwencjach, mapach, wektorach, zbiorach.⁷ Po prostu używaj map. Po prostu używaj danych.

Ten podział to rozplątywanie na poziomie gramatyki języka. Obiekty splatają razem stan, tożsamość i zachowanie w jedną zapieczętowaną rzecz; Clojure je rozdziela — niezmienne wartości dla tego, czym rzecz jest, zwykłe funkcje dla tego, co się z nią robi, jawne typy referencyjne dla zarządzanej zmiany w czasie. Czyniąc JVM platformą, zamiast z nią walczyć, Hickey rozplątał też język od środowiska wykonawczego: Clojure dostaje za darmo dojrzałość, biblioteki i wydajność JVM, a cały budżet swojej nowatorskości wydaje wyłącznie na model stanu i czasu.⁷

The Value of Values: niezmienność i Datomic

The Value of Values podnosi argument o niezmienności o poziom wyżej, do samej bazy danych. Celem Hickeya jest to, co nazywa programowaniem zorientowanym na miejsce (place-oriented programming, PLOP): „za każdym razem, gdy nowa informacja zastępuje starą, uprawiasz programowanie zorientowane na miejsce”.⁸ Aktualizujemy rekord w miejscu, stara wartość znika, a wraz z nią historia. Hickey twierdzi, że to pozostałość po epoce skąpej pamięci i że wyrzuca się w ten sposób dokładnie to, czego firma potrzebuje, by rozumować — przeszłość. Wartość jest natomiast z definicji niezmienna: fakt to „coś, co się wydarzyło, coś, o czym wiadomo, że się wydarzyło”, a faktu nie da się zaktualizować — można go jedynie zastąpić nowszym faktem.⁸ Nowy prezydent nie nadpisuje starego; dopisuje się.

Datomic to ta idea zbudowana jako baza danych. Jest fundamentalnie niezmienna: „Baza danych Datomic to zbiór niezmiennych, atomowych faktów zwanych datomami”, a „transakcje Datomic dodają datomy, nigdy ich nie aktualizując ani nie usuwając, więc masz kompletny ślad audytowy”.⁹ Ponieważ nic nigdy nie jest nadpisywane, bazę można traktować jako wartość na dany moment w czasie — można odpytywać ją „na stan z” dowolnej przeszłej chwili tymi samymi zapytaniami, które uruchamiasz na teraźniejszości, bez żadnej zmiany.⁹ Baza danych przestaje być pojedynczym, zmiennym miejscem, a staje się ciągiem wartości w czasie. Stan, tożsamość i czas — rozplątane, w produkcyjnym magazynie danych.

Hammock-Driven Development: najpierw myśl

Towarzyszem tego wszystkiego jest prelekcja o tym, kiedy wykonuje się prawdziwą pracę, a odpowiedź Hickeya brzmi: zanim dotkniesz klawiatury. W Hammock-Driven Development dowodzi, że „najtańszym miejscem na naprawę błędów jest moment, w którym projektujesz swoje oprogramowanie” i że większość poważnych awarii oprogramowania to awarie błędnego pojmowania — nie zrozumieliśmy problemu, zanim zaczęliśmy go rozwiązywać.¹⁰ Lekarstwem jest jawne sformułowanie problemu, zebranie faktów i ograniczeń, a następnie myślenie — w tym przez oddanie problemu „umysłowi w tle”, który tworzy połączenia, jakich „umysł czuwający”, analityczny, nie zdoła wymusić.¹⁰ Hamak to dosłowny mebel do tego, by nie robić nic poza myśleniem, w spokoju.

Hammock-driven development to praktyka, która w ogóle umożliwia prostotę. Nie da się rozplątać systemu, którego się jeszcze nie rozumie, i nie da się go zrozumieć, ścigając się do kompilacji. Hammock-driven development to nieefektowna pierwsza połowa zasady proste to nie łatwe: świadome, powolne, czujne myślenie, które musi się odbyć, zanim pojawi się nieposplatany projekt.

Metoda

Metoda to jedno rozróżnienie — proste to nie łatwe — stosowane z niezwykłym uporem w obrębie języka, bazy danych i stylu pracy.

Oddziel „proste” od „łatwego” przed każdą decyzją. Pytaj o każde narzędzie lub projekt: czy to jest nieposplatane (proste), czy jedynie znajome i będące pod ręką (łatwe)? To różne osie, a ich mylenie jest sposobem, w jaki złożoność przemyca się w przebraniu produktywności.¹²

Trop splatanie i je rozplątuj. Złożoność to nie liczba części; to stopień ich poplątania. Znajdź, gdzie stan jest spleciony z czasem, tożsamość z zachowaniem, zasada z mechanizmem — i rozdziel nici na niezależne elementy, które świadomie składasz.³

Stawiaj wartości i dane ponad miejsca i obiekty. Uczyń niezmienność stanem domyślnym. Przedstawiaj informację jako zwykłe dane — mapy, wektory — i operuj na nich funkcjami, zamiast pieczętować stan i zachowanie razem wewnątrz obiektów.⁷⁸

Traktuj przeszłość jako wartość, a nie jako nadpisany stan. Nowa informacja powinna się dopisywać, a nie niszczyć. O systemie, który gromadzi niezmienne fakty w czasie, da się rozumować, da się go audytować i odpytywać na stan z dowolnej chwili — czego miejsce nadpisywane in situ nigdy nie potrafi.⁸⁹

Myśl, zanim zaczniesz pisać. Najtańszym miejscem na naprawę usterki jest projekt. Sformułuj problem, podaj go umysłowi w tle i zasłuż na prosty projekt, najpierw rozumiejąc problem.¹⁰

Pogódź się z tym, że prostota jest trudna i wybrana. Nie przychodzi z sięgnięcia po to, co łatwe. „Prostota to wybór”, który wymaga „nieustannej czujności”. Droga wygodna i droga prosta rzadko są tą samą drogą.⁴

Łańcuch wpływów

Kto go ukształtował

Lisp i John McCarthy. Clojure, w ujęciu samego Hickeya, jest „Lispem nieskrępowanym wsteczną zgodnością” — homoikoniczność kodu-jako-danych i moc makr pochodzą wprost z linii McCarthy’ego, rozszerzonej na mapy i wektory, nie tylko listy.⁷ (Wpływ bezpośredni)

John Backus i tradycja programowania funkcyjnego. Wykład Backusa z okazji Nagrody Turinga z 1977 roku, Can Programming Be Liberated from the von Neumann Style?, to kanoniczny argument przeciwko obliczeniom napędzanym przypisaniem i zorientowanym na miejsce. Wojna Hickeya z programowaniem zorientowanym na miejsce i zmiennym stanem to ten argument przeniesiony na produkcję. (Wpływ formujący)

Java Virtual Machine. Zamiast traktować środowisko wykonawcze jak wroga, którego trzeba zabstrahować, Hickey uczynił JVM platformą i zbudował język na jego wierzchu — świadome rozplątanie „języka” od „środowiska wykonawczego”, które dało Clojure dojrzałość i zasięg od pierwszego dnia. (Wpływ bezpośredni)

Myślenie relacyjne i zorientowane na wartości. Spojrzenie Datomic na dane jako niezmienne fakty gromadzone w czasie, odpytywalne na stan z dowolnego punktu, wywodzi się z właściwego tradycji relacyjnej oddzielenia faktów od ich przechowywania — idei, że informacja ma istnienie niezależne od miejsca, które aktualnie ją trzyma.⁸⁹ (Wpływ formujący)

Kogo on ukształtował

Renesans programowania funkcyjnego. Clojure, obok Scali i innych na JVM, pomógł przesunąć programowanie funkcyjne z akademickiej ciekawostki do głównego nurtu produkcji, a prelekcje Hickeya stały się wspólnym słownictwem — „proste”, „łatwe”, „splatać” — którym praktykujący programiści dziś spierają się o projektowanie.

Niezmienność wprowadzona do głównego nurtu. Idea, że dane niezmienne z założenia są rozsądnym stanem domyślnym, a nie egzotycznym ograniczeniem, rozeszła się daleko poza Clojure. To dziś warunek wstępny w projektowaniu języków i bibliotek w całej branży.

React, Redux i świat front-endu. Model zorientowany na wartości — niezmienny stan, czyste przekształcenia na danych, rozdzielone tożsamość i stan — to koncepcyjny kręgosłup Reacta, a zwłaszcza Reduxa. Całe pokolenie inżynierów front-endu wchłonęło myślenie wartościami Hickeya, nie zawsze wiedząc, czyje ono jest.

Nić przewodnia

John Carmack odziera renderer do szybkiego, prostego jądra i odmawia każdej funkcji, która wplotłaby powolność w wewnętrzną pętlę; Hickey odziera system do jego nieposplatanych spraw i odmawia każdej abstrakcji, która by je spleciła. Obaj traktują prostotę jako rzecz trudną i wybraną, a nie domyślną. I tam, gdzie Linus Torvalds ceni „dobry gust”, który sprawia, że przypadek szczególny znika w ogólnym, Hickey ceni rozplątywanie, które sprawia, że dwie poplątane sprawy stoją osobno jako jedno — ten sam instynkt widziany z przeciwnych krańców: właściwa struktura nie jest ozdobą problemu, jest problemem poprawnie rozdzielonym na jego prawdziwe części. Yukihiro Matsumoto zoptymalizował Ruby pod to, jak się go pisze — pod łatwe, w słowniku Hickeya — podczas gdy Hickey zoptymalizował pod to, czym rzecz jest — pod proste; razem wyznaczają dwie osie, których — jak przez całą prelekcję nalegał Hickey — mamy przestać mylić. (Pomost serii)

Co z tego biorę dla siebie

Lekcja, która mi zostaje, brzmi: łatwe to pułapka przebrana za cnotę. Niemal każdy żal w bazie kodu zaczął się od rozsądnego sięgnięcia po to, co pod ręką — wygodna biblioteka, szybka mutacja, jedna dodatkowa odpowiedzialność dołożona do klasy, która już istniała. Nic z tego nie sprawiało wrażenia błędu, bo łatwe nigdy go nie sprawia. Darem Hickeya jest słownictwo, które pozwala złapać to w danej chwili: zatrzymać się i zapytać czy to proste, czy tylko łatwe? oraz wiedzieć, że uczciwa odpowiedź jest zwykle tą niewygodną. To ten sam standard co jakość będąca jedyną zmienną — pytanie nigdy nie brzmi „po co mogę sięgnąć najszybciej?”, lecz „co jest tutaj naprawdę nieposplatane?”.

W świecie, w którym teraz buduję — agenty, pętle narzędzi, kod ram agenta, gdzie stan, prompty, ponowienia i efekty uboczne uwielbiają splatać się w jedną nieokiełznaną rzecz — pokusa maksymalnego łatwego jest największa: nakładaj na siebie frameworki, rozsmaruj stan po całej pętli, spleć logikę decyzyjną z wejściem-wyjściem i z logowaniem, aż nikt nie zdoła zmienić jednej części bez ryzykowania całości. Ruch Hickeya to rozplątywanie: wyciągnij zasadę z mechanizmu, uczyń stan niezmiennym tam, gdzie to możliwe, traktuj każdy przebieg jako wartość, a nie miejsce, które nadpisuję. To przekonanie — że gust jest systemem technicznym, który wybiera się z czujnością, a nie nastrojem dziedziczonym przez sięganie po to, co blisko — jest nicią przewodnią od finansowanego z własnej kieszeni Lispa w 2007 roku do ram agenta w 2026. Proste to nie łatwe. Wybierz je mimo to.

FAQ

Jaka jest różnica między prostym a łatwym?

W ujęciu Richa Hickeya z Simple Made Easy proste i łatwe leżą na zupełnie różnych osiach. Proste pochodzi od łacińskiego simplex — „jeden zwój lub splot” — i opisuje samą rzecz: jak niewiele spraw jest w niej przeplecionych. Jest obiektywne, a jego przeciwieństwem jest złożone („spleciony razem”).¹ Łatwe wywodzi się od rdzenia oznaczającego „leżeć blisko”, tego samego, od którego pochodzi przyległy; opisuje twoją relację z rzeczą — jak znajoma i będąca pod ręką jest.² Jest subiektywne, a jego przeciwieństwem jest trudne. Coś może być proste, lecz nieznajome, albo łatwe, lecz głęboko złożone. Sedno Hickeya jest takie, że nieustannie wybieramy to, co łatwe, i błędnie nazywamy to prostym, a za złożoność płacimy później.¹

Co znaczy „complect” (splatać)?

Complect to czasownik, który Hickey wskrzesił w Simple Made Easy na określenie czynności splatania spraw razem. Definiuje go wprost: „Znaczy przeplatać, zwijać razem lub splatać”.³ Splatanie jest tym, co czyni system złożonym — nie liczba części, lecz stopień ich poplątania. Gdy dwie sprawy są splecione (powiedzmy stan i czas albo tożsamość i zachowanie), nie da się już zmienić jednej, nie rozumiejąc drugiej i nie ryzykując jej. Lekarstwem jest rozplątywanie: wyciągnięcie nici do niezależnych elementów, które można świadomie złożyć. Hickey traktuje rozplątywanie jako podstawową dyscyplinę budowania prostych systemów.³

Co zbudował Rich Hickey?

Rich Hickey to niezależny programista, który stworzył Clojure, dynamiczny, funkcyjny dialekt Lispa działający na Java Virtual Machine. Rozwijał go w dużej mierze samodzielnie przez mniej więcej dwa i pół roku, znaczną część tego czasu z własnych środków, bez wynagrodzenia, i udostępnił w 2007 roku.⁵⁷ Później stworzył Datomic, niezmienną bazę danych, która nigdy nie nadpisuje danych, lecz gromadzi w czasie niezmienne fakty („datomy”), tak że bazę można odpytywać jako wartość na stan z dowolnego przeszłego punktu.⁹ Jest też szeroko znany z serii prelekcji konferencyjnych — Simple Made Easy, The Value of Values, Hammock-Driven Development oraz Are We There Yet? — które ukształtowały sposób, w jaki branża mówi o złożoności, niezmienności i projektowaniu.⁵⁶

Czy Rich Hickey powiedział „programiści znają korzyści ze wszystkiego, a kompromisy z niczego”?

Ten one-liner jest bardzo szeroko przypisywany Hickeyowi i trafnie oddaje jego myślenie, ale nie pojawia się dosłownie w transkrypcjach jego głównych prelekcji; to skrystalizowana parafraza, która rozeszła się przez książki i wystąpienia konferencyjne.¹¹ Najbliższa dosłownej, źródłowej wersja znajduje się w Design, Composition, and Performance, gdzie nawołuje, by rozłożyć rozwiązanie na części „i zobaczyć nie tylko korzyści, prawda? Te są zwykle dość oczywiste. Ale także kompromisy: która część tego nie zadziała?”¹² Sama myśl jest jednoznacznie jego — że inżynierowie przeceniają to, co narzędzie im daje, a niedoceniają tego, co ono kosztuje — ale chwytliwy aforyzm najlepiej traktować jako parafrazę, a nie bezpośredni cytat.

Źródła