Filozofia inżynierska: Guido van Rossum, czytelność się liczy

Najważniejsze wnioski

• Kod jest czytany znacznie częściej, niż jest pisany, dlatego van Rossum zoptymalizował Pythona pod kątem człowieka, który przeczyta daną linię później, a nie maszyny czy autora w chwili pisania.
• Znaczące wcięcia czynią czytanie uczciwym – wcięcie, które widać, jest strukturą bloku, która faktycznie się wykonuje, więc wygląd programu w Pythonie nie może kłamać o tym, co program robi.
• „Powinien istnieć jeden oczywisty sposób, aby coś zrobić” oznacza, że kod napisany przez obcych ludzi wciąż czyta się tak, jakby wyszedł spod jednej ręki – zbieżność wokół jednego idiomu to dar dla każdego przyszłego czytelnika.
• Zen of Python jest autorstwa Tima Petersa, nie van Rossuma – to częste błędne przypisanie. Peters wydestylował wartości, które były już wbudowane w język.

Zasada

„Jedną z kluczowych intuicji Guida jest to, że kod jest czytany znacznie częściej, niż jest pisany.” – PEP 8, przypisując tę myśl Guidowi van Rossumowi¹

To najcichszy rewolucyjny postulat w projektowaniu języków, a niemal każdy kiwa nad nim głową i zaraz potem o nim zapomina. Proszę przeczytać to zdanie powoli. Kod jest czytany znacznie częściej, niż jest pisany. Linia, którą napisze się raz, zostanie przeczytana dziesiątki razy – przez recenzenta, który ją zatwierdza, przez kolegę, który ją rozbudowuje, przez obcego człowieka, który ją dziedziczy, a najczęściej przez samego siebie, pół roku później, gdy próbuje się przypomnieć, o co chodziło. Jeśli to prawda, to odbiorcą kodu źródłowego nie jest maszyna ani autor w chwili pisania. Jest nim człowiek, który przeczyta go później. A język powinien być zoptymalizowany pod kątem swojego prawdziwego odbiorcy.

Niemal żaden język taki nie był. Języki systemowe lat 80. optymalizowano pod kątem kompilatora i maszyny; języki skryptowe optymalizowano pod wygodę autora w danej chwili, dlatego tak wiele z nich stawało się nieczytelnych już nazajutrz po napisaniu. Guido van Rossum postawił na to, że można zamiast tego optymalizować pod kątem czytelnika – że klarowność, uczyniona domyślną i wymuszana przez samą gramatykę, będzie procentować w całej społeczności przez dziesięciolecia. Miał rację z marginesem, którego niemal nikt nie przewidział. Zen of Python destyluje tę samą wartość w trzy słowa, które przeczytał każdy programista Pythona: „Readability counts” (czytelność się liczy).²

To przekonanie jest tym samym, które leży u podstaw tezy, że smak jest systemem technicznym, a nie wyczuciem, które się deklaruje. Czytelność nie jest miękką preferencją, którą dokleja się przewodnikiem stylu po fakcie. W Pythonie jest strukturalna – wpisana w składnię tak, że język nie pozwala napisać nieczytelnej wersji równie łatwo jak czytelnej. Zakład van Rossuma polegał na tym, że jeśli uczyni się rzecz klarowną drogą najmniejszego oporu, cały ekosystem zacznie dryfować w stronę klarowności, choć nikt mu tego nie nakaże.

Kontekst

Guido van Rossum urodził się 31 stycznia 1956 roku w Hadze, w Holandii, i w 1982 roku uzyskał magisterium z matematyki i informatyki na Uniwersytecie Amsterdamskim.³ Podjął pracę w Centrum Wiskunde & Informatica (CWI), holenderskim narodowym instytucie badawczym matematyki i informatyki w Amsterdamie, gdzie czekało go formujące doświadczenie kariery: język programowania ABC.

ABC, zaprojektowany w CWI przez Leo Geurtsa, Lamberta Meertensa i Stevena Pembertona, był językiem dydaktycznym stworzonym z myślą o łatwości nauki i czytelności, a van Rossum przez kilka lat w połowie lat 80. pracował nad jego implementacją.⁴ ABC dokonał dwóch wyborów, które miały odbić się echem we wszystkim, co zrobił później: używał wcięć do oznaczania struktury bloków – „reguła off-side”, żadnych klamer, żadnych begin/end – i traktował czytelność jako nadrzędny cel projektowy, przy czym programy były zwykle czterokrotnie krótsze od odpowiedników w Pascalu czy C.⁴ Van Rossum pokochał pomysł z wcięciami; powiedział później, że pozbył się on bezsensownych wojen religijnych o to, gdzie umieszczać klamry.⁵ Ale ABC miał też wady krytyczne – monolityczną implementację, zamknięty projekt trudny do rozszerzania, akademicką hermetyczność, która trzymała go z dala od prawdziwych programistów Uniksa. Posłużył się czytelnym językiem i zobaczył obie połowy lekcji: które pomysły były naprawdę dobre, a które były błędami, które go zabiły.

Potem nadeszła słynna historia o początkach – i naprawdę wydarzyła się tak, jak głosi legenda. „Ponad sześć lat temu, w grudniu 1989 roku”, pisał van Rossum, „szukałem »hobbystycznego« projektu programistycznego, który zająłby mnie w tygodniu w okolicach Bożego Narodzenia.”⁶ Jego biuro w CWI było zamknięte na święta. Postanowił zbudować język skryptowy, który zachowałby najlepsze pomysły ABC – czytelność, wcięcia – i naprawiłby jego błędy, tym razem celując w hakerów Unix/C, do których ABC nigdy nie dotarł. Na nazwę, „będąc w nieco nonszalanckim nastroju (i jako wielki fan Latającego cyrku Monty Pythona)”, wybrał Python.⁶ Nie wąż. Grupa komediowa. Pierwszą wersję udostępnił publicznie w 1991 roku.³

Dzieło

Czytelność i znaczące wcięcia

Najbardziej brzemienną w skutki decyzją projektową, którą van Rossum przeniósł z ABC, jest ta, o którą spierają się nowicjusze, a której weterani przestają zauważać: wcięcie jest składnią. W większości języków strukturę bloków oznaczają klamry lub słowa kluczowe, a wcięcie jest tylko ozdobą, z której korzysta ludzkie oko, a którą kompilator ignoruje. To znaczy, że oba mogą się ze sobą nie zgadzać. Klamry mogą mówić jedno, podczas gdy wcięcie mówi co innego, i kod może wyglądać, jakby robił jedno, a wykonywać co innego – klasyczny błąd mylącego wcięcia, rodzina pomyłek, która wyprodukowała niesławną dziurę SSL goto fail Apple’a, gdzie zabłąkana druga wcięta linia znajdowała się poza instrukcją if, którą wizualnie zdawała się zawierać.

Python czyni tę klasę błędów strukturalnie niemożliwą. Wcięcie, które widać, jest strukturą bloku, która się wykonuje. Nie ma żadnej drugiej, ukrytej prawdy, od której mogłoby się rozejść. Van Rossum odziedziczył to po ABC, bo kończyło to debaty o rozmieszczeniu klamer, ale głębszą korzyścią jest właśnie jego zasada: czyni to czytanie uczciwym. To, co oko czytelnika postrzega jako kształt programu, jest – z definicji – kształtem, który wykonuje interpreter.⁴⁵

Uczciwa struktura jest również powodem, dla którego Python wygląda dla nie-programisty tak, jak wygląda: jak ustrukturyzowany pseudokod, który akurat się wykonuje. O to właśnie chodziło. Van Rossum, według własnych słów osoba bardzo wzrokowa, zaprojektował powierzchnię tak, by była przystępna, a strukturę tak, by była widoczna, aby przepaść między „czytaniem kodu” a „rozumieniem programu” była tak mała, jak tylko gramatyka może ją uczynić.

Zen of Python i „jeden oczywisty sposób”

W 1999 roku wieloletni główny deweloper Tim Peters spisał wartości projektowe, które ożywiały Pythona, w dwudziestu aforyzmach. Ostatecznie zostały uświęcone jako PEP 20, Zen of Python, i są dostarczane wewnątrz samego języka: wystarczy wpisać import this w wierszu poleceń Pythona, a się wypiszą. Autorstwo ma znaczenie i często bywa mylone: tekst napisał Tim Peters, nie van Rossum.² Ale Zen jest destylacją wrażliwości projektowej Guida – Peters wyartykułował wartości, które były już w języku, tak jak dobry krytyk artykułuje intencję artysty lepiej, niż potrafi to sam artysta.

Dwie linie niosą całą filozofię. „Readability counts” (czytelność się liczy). Oraz: „Powinien istnieć jeden – i najlepiej tylko jeden – oczywisty sposób, aby coś zrobić.”² Ta druga linia to celowe odwrócenie sławnego motta Perla: „Jest więcej niż jeden sposób, aby to zrobić.” Python van Rossuma stawia w przeciwnym kierunku: język, który oferuje jeden oczywisty sposób, to język, którego kod wygląda tak samo niezależnie od tego, kto go napisał, co oznacza, że każdy może przeczytać kod każdego innego. Zbieżność wokół jednego idiomu nie jest ograniczeniem nałożonym na autora; jest darem dla każdego przyszłego czytelnika. (Nawet interpunkcja samego aforyzmu – pauzy obejmujące „i najlepiej tylko jeden” – to przebiegły żart o tym, że reguła zostaje nieco naruszona już w jej formułowaniu.)

BDFL i zarządzanie: ustąpienie w 2018 roku

Przez większość życia Pythona van Rossum dzierżył ostatnie słowo w kwestii projektu języka, pod tytułem ukutym na poły żartem podczas zlotu Pythona w 1995 roku i utrwalonym przez Barry’ego Warsawa: BDFL, Benevolent Dictator For Life (Życzliwy Dyktator Dożywotni).⁷ Był to realny model zarządzania. Zmiany w języku przepływały przez proces PEP – Python Enhancement Proposals, otwarty, pisemny, archiwizowany mechanizm, którym każdą zmianę się proponuje, omawia i rozstrzyga – ale gdy konsensus zawodził, decydował BDFL. Przez dziesięciolecia to działało, bo to właśnie smakowi van Rossuma społeczność ufała.

Skończyło się na jednym operatorze. PEP 572 wprowadził wyrażenie przypisania „morsa”, :=, a debata była wyjątkowo zacięta – van Rossum przeforsował je wbrew głośnemu, nieustępliwemu sprzeciwowi. 12 lipca 2018 roku, kilka dni po jego przyjęciu, opublikował na liście python-committers e-mail zatytułowany „Transfer of power” (Przekazanie władzy). „Teraz, gdy PEP 572 jest gotowy”, napisał, „nigdy więcej nie chcę musieć walczyć tak zaciekle o PEP i przekonywać się, że tak wielu ludzi gardzi moimi decyzjami.” Dał sobie „stały urlop od bycia BDFL” i – co najważniejsze – stanowczo odmówił wskazania następcy („Nie zamierzam wyznaczać następcy”), pozostawiając społeczności wymyślenie własnego rządu.⁸ Tak też zrobiła: pięcioosobową, wybieraną Radą Sterującą (Steering Council), ratyfikowaną przez PEP 8016, która dziś zarządza Pythonem. Życzliwy dyktator celowo zniósł dyktaturę.

Zasięg Pythona

Zakład o czytelność złożył się na jeden z największych rezultatów w historii oprogramowania. Ponieważ Python był językiem, który ludzie potrafili przeczytać, stał się językiem, którego ludzie potrafili nauczać – jest dziś dominującym językiem wprowadzającym na uczelniach na całym świecie. Ponieważ był czytelny i rozszerzalny, stał się spoiwem obliczeń naukowych: NumPy, SciPy, pandas, cały stos data science. A ponieważ stos data science był już w Pythonie, rewolucja głębokiego uczenia również została zbudowana w Pythonie – PyTorch, TensorFlow, JAX i niemal każdy model, o którym Pan/Pani słyszał/a, są napędzane z języka, który holenderski programista zaprojektował podczas świątecznej przerwy tak, by był przyjazny dla ludzkiego oka. Sam van Rossum wyszedł z emerytury w 2020 roku, by dołączyć do Microsoftu i pracować nad projektem Faster CPython, przedsięwzięciem mającym uczynić interpreter mniej więcej dwukrotnie szybszym – wracając, jak to ujął, do swoich korzeni.⁹

Metoda

Metoda to jedno przekonanie – optymalizuj pod kątem czytelnika – realizowane z niezwykłą konsekwencją przez trzydzieści pięć lat.

Optymalizuj pod kątem człowieka, który czyta kod. Nie maszyny, nie autora w danej chwili. Każda decyzja powierzchniowa – wcięcia, niewielki słownik słów kluczowych, naleganie na klarowność – służy osobie, która przeczyta daną linię później, bo to ona jest prawdziwym odbiorcą i jest jej znacznie więcej.¹

Uczyń strukturę widoczną, a czytanie uczciwym. Wcięcie jest strukturą bloku, więc to, co postrzega oko, jest tym, co wykonuje interpreter. Język odmawia rozejścia się wyglądu kodu z jego zachowaniem.⁴

Preferuj jeden oczywisty sposób. Opieraj się pokusie oferowania pięciu idiomów do tego samego zadania. Zbieżność wokół jednego klarownego idiomu oznacza, że kod napisany przez obcych ludzi wciąż czyta się tak, jakby wyszedł spod jednej ręki.²

Bierz dobre pomysły i naprawiaj błędy. Python to czytelność i wcięcia ABC, minus monolityczny, zamknięty, nierozszerzalny projekt ABC. Van Rossum nie wynalazł z niczego; był wybrednym redaktorem tego, co było przed nim.⁴⁵

Zarządzaj otwarcie i wiedz, kiedy odpuścić. Proces PEP uczynił decyzje projektowe publicznymi i pisemnymi. A gdy bycie ostateczną instancją stało się kosztem dla społeczności, a nie przysługą dla niej, usunął się – i odmówił namaszczenia następcy, zmuszając do uformowania się w jego miejsce trwałej instytucji.⁸

Łańcuch wpływów

Kto go ukształtował

ABC oraz Lambert Meertens, Leo Geurts i Steven Pemberton z CWI. ABC wręczył van Rossumowi jego dwa definiujące pomysły – wcięcie jako składnię i czytelność jako nadrzędny cel – i, przez swoją porażkę, nauczył go lekcji negatywnych: nie buduj monolitu, nie zamykaj projektu, nie ignoruj pracującego programisty. Python to dobra połowa ABC, ocalona. (Bezpośredni, formujący wpływ)

Modula-3. Jej czysty projekt modułów i wyjątków wpłynął na ten w Pythonie – przypomnienie, że van Rossum celowo zapożyczał z języków, które podziwiał, zamiast wynajdywać każde koło od nowa. (Bezpośredni wpływ)

C i kultura Uniksa. C dał Pythonowi jego język implementacji (CPython jest napisany w C) i jego grupę docelową – hakerów Unix/C, do których ABC nigdy nie dotarł. Python został pomyślany jako czytelna warstwa skryptowa ponad C, rozszerzalna w C, spoiwo dla świata C. (Formujący wpływ)

Kogo ukształtował

Największą społeczność programistyczną na ziemi. Python jest, według większości miar, najszerzej używanym językiem programowania na świecie i domyślnym pierwszym językiem, którego naucza się początkujących. Całe pokolenie nauczyło się myśleć o programach w składni zaprojektowanej do czytania.

Data science, AI i obliczenia naukowe. NumPy, pandas, PyTorch, TensorFlow – całe oprzyrządowanie współczesnej ery AI spoczywa na Pythonie, bo Python był językiem, który badacze potrafili czytać i rozszerzać. Zakład o czytelność jest, pośrednio, nośnym elementem dziedziny, w której pracuję.

Zarządzanie open source. Model BDFL i jego celowe rozwiązanie w wybieraną Radę Sterującą stały się studiowanym wzorcem tego, jak projekt prowadzony smakiem jednej osoby może przeżyć autorytet tej osoby.

Nić przewodnia

Yukihiro Matsumoto zaprojektował Ruby dla szczęścia programisty i zasady najmniejszego zaskoczenia; van Rossum zaprojektował Pythona dla czytelnika. To dwa wielkie języki „radości” i ten sam instynkt wymierzony w nieco inne cele – Matz optymalizuje to, jak się pisze, van Rossum to, jak się czyta – dlatego tak często się zbiegają i dlatego ich społeczności się rozpoznają. Donald Knuth dotarł do tego samego celu z poziomu akademii dzięki literate programming: radykalnej tezie, że program jest dziełem literackim pisanym dla ludzi, a zdolność maszyny do jego wykonania jest niemal efektem ubocznym. Van Rossum wbudował to przekonanie w gramatykę języka zamiast w metodologię. A tam, gdzie Bjarne Stroustrup postawił na pierwszym miejscu wydajność bez narzutu i pozwolił C++ rozrosnąć się w język, którego płynne czytanie zajmuje lata, van Rossum postawił na pierwszym miejscu czytelność i przyjął powolność interpretera jako cenę – dwóch projektantów, przeciwne priorytety, każdy płacący w walucie, której drugi odmawiał wydania. (Most serii)

Co z tego biorę

Lekcja, którą zachowuję, brzmi: czytelność nie jest grzecznością; jest właściwym produktem. Kod jest czytany znacznie częściej, niż jest pisany, więc wersja klarowna w czytaniu jest wersją wartą więcej – a „posprzątam to później” to obietnica złożona czytelnikowi, którego po cichu zdradzam już teraz. Ruch van Rossuma polega na uczynieniu klarownej wersji domyślną, tak by robienie właściwej rzeczy było drogą najmniejszego oporu, a nie aktem dyscypliny. To ten sam standard, co jakość jako jedyna zmienna: pytanie nigdy nie brzmi „czy to działa?”, lecz „czy następna osoba, która to przeczyta, zrozumie to tak szybko, jak potrzebuje?”.

W świecie, w którym teraz buduję – agenci, pętle narzędzi, prompty, kod ram agenta, który inni agenci i ja-z-przyszłości będziemy czytać o drugiej w nocy – pokusa jest przeciwieństwem „czytelność się liczy”: sprytne jednolinijkowce, niejawny stan, pięć sposobów na zrobienie tego samego rozsianych po bazie kodu, której nikt nie jest w stanie objąć głową. Ruch van Rossuma to wybrać jeden oczywisty sposób i uczynić strukturę uczciwą, tak by to, co się czyta, było tym, co się wykonuje. To przekonanie – że klarowność, uczyniona strukturalną i wymuszana przez gramatykę systemu, a nie pozostawiona sile woli, procentuje u wszystkich, którzy później to czytają – jest nicią przewodnią od świątecznego hobbystycznego projektu z 1989 roku po ramy agenta z 2026 roku. To czytelnik jest odbiorcą. Buduj dla niego.

FAQ

Jaka jest filozofia inżynierska Guida van Rossuma?

Kluczowe przekonanie van Rossuma brzmi: kod jest czytany znacznie częściej, niż jest pisany, więc język powinien być zoptymalizowany pod kątem człowieka, który go czyta.¹ Zbudował Pythona wokół czytelności jako nadrzędnego, strukturalnego celu – nie wytycznej stylu doklejonej po fakcie, lecz wpisanej w gramatykę poprzez znaczące wcięcia, niewielki słownik słów kluczowych i zasadę, że powinien istnieć „jeden oczywisty sposób, aby coś zrobić”.² Połączył to z otwartym zarządzaniem językiem poprzez proces PEP oraz, w 2018 roku, celowym ustąpieniem z funkcji ostatecznej instancji.⁸

Dlaczego Python używa wcięć zamiast klamer?

Van Rossum przejął opartą na wcięciach strukturę bloków („regułę off-side”) z języka ABC, nad którym pracował w CWI w latach 80.; podobało mu się, że kończyła ona niekończące się spory o to, gdzie umieszczać klamry.⁴⁵ Głębszym powodem, dla którego się utrzymuje, jest to, że czyni czytanie uczciwym: w językach klamrowych wcięcie jest ozdobne i może nie zgadzać się z klamrami, więc kod może wyglądać, jakby robił jedno, a wykonywać co innego (błąd mylącego wcięcia). W Pythonie wcięcie, które widać, jest strukturą bloku, która się wykonuje – nie ma żadnej drugiej, ukrytej prawdy, od której mogłoby się rozejść.

Kto napisał Zen of Python?

Tim Peters, wieloletni główny deweloper Pythona, napisał Zen of Python – dwadzieścia aforyzmów uświęconych jako PEP 20 i wypisywanych po uruchomieniu import this. Nie napisał ich Guido van Rossum – to częste błędne przypisanie.² Tym, co robią, jest destylacja własnych wartości projektowych van Rossuma w zapadającą w pamięć formę – linie takie jak „Readability counts” (czytelność się liczy) oraz „Powinien istnieć jeden – i najlepiej tylko jeden – oczywisty sposób, aby coś zrobić” artykułują wrażliwość, która była już wbudowana w język.

Dlaczego Guido van Rossum ustąpił z funkcji BDFL Pythona?

Van Rossum prowadził Pythona przez dziesięciolecia jako jego BDFL – Benevolent Dictator For Life (Życzliwy Dyktator Dożywotni), tytuł ukuty na poły żartem podczas zlotu Pythona w 1995 roku.⁷ Zrezygnował 12 lipca 2018 roku, kilka dni po kontrowersyjnym przyjęciu PEP 572 (operatora morsa :=), który przeforsował wbrew silnemu sprzeciwowi. W e-mailu zatytułowanym „Transfer of power” (Przekazanie władzy) napisał: „Teraz, gdy PEP 572 jest gotowy, nigdy więcej nie chcę musieć walczyć tak zaciekle o PEP i przekonywać się, że tak wielu ludzi gardzi moimi decyzjami”, dał sobie „stały urlop od bycia BDFL” i dobitnie odmówił wskazania następcy.⁸ Społeczność zastąpiła go wybieraną, pięcioosobową Radą Sterującą.

Źródła