Filozofia inżynierii: Thompson i Ritchie, rób jedną rzecz dobrze

Najważniejsze wnioski

• Małe, ostre narzędzia. Każdy program robi jedną rzecz dobrze i opiera się robieniu drugiej; nowe potrzeby otrzymują nowe narzędzie, a nie kolejną flagę.
• Składanie ponad funkcjami. Moc rodzi się z łączenia programów przez uniwersalny tekstowy interfejs – potoki – tak że możliwości pojawiają się w spojeniach, a nie wewnątrz któregokolwiek programu. Kanoniczne sformułowanie „rób jedną rzecz dobrze” należy do Douga McIlroya, a nie do Thompsona czy Ritchiego.
• Przenośność dzięki C. Przepisanie Uniksa w C pozwoliło przenosić go na nowy sprzęt poprzez portowanie kompilatora zamiast przepisywania całego systemu – to w dużej mierze powód, dla którego Unix rozprzestrzenił się wszędzie.
• Nie ufaj niczemu, czego sam nie zbudowałeś. Praca Thompsona „Reflections on Trusting Trust” pokazuje, że tylne wejście może żyć w pliku wykonywalnym bez najmniejszego śladu w jakimkolwiek kodzie źródłowym, który można sprawdzić – to założycielska myśl bezpieczeństwa łańcucha dostaw.

Zasada

„Pisz programy, które robią jedną rzecz i robią ją dobrze. Pisz programy, które współpracują ze sobą. Pisz programy, które obsługują strumienie tekstu, ponieważ jest to uniwersalny interfejs.” – Doug McIlroy, podsumowując filozofię Uniksa¹

To zdanie nie należy ani do Thompsona, ani do Ritchiego. Napisał je Doug McIlroy, ich kolega z Bell Labs i człowiek, który wynalazł uniksowy potok, w przedmowie do specjalnego wydania Bell System Technical Journal z 1978 roku.¹ Jest to jednak najczystsze sformułowanie tego, co Thompson i Ritchie naprawdę zbudowali, a powód, by zacząć właśnie od niego, a nie od słów któregokolwiek z nich, sam w sobie jest sednem: filozofia Uniksa nigdy nie była manifestem napisanym przez jednego geniusza. Była kulturą, a kultura była właściwym wytworem.

Zasada ma trzy ruchy i są one nierozdzielne. Niech każde narzędzie będzie małe i ostre – jedno zadanie, wykonane dobrze, bez ambicji robienia drugiego. Niech narzędzia będą składalne – wyjście jednego jest wejściem następnego, tak by możliwości brały się z łączenia, a nie z rozrastania się któregokolwiek programu. I niech interfejs między nimi będzie uniwersalny – czysty tekst, tak by dowolne narzędzie można było połączyć z dowolnym innym, przy czym żadne z nich nie musi wiedzieć o istnieniu drugiego. Moc mieszka w spojeniach, a nie w częściach. Program sortujący wiersze nie wie nic o dziennikach serwera WWW; program zliczający duplikaty nie wie nic o kodach stanu HTTP; połączone potokiem odpowiadają na pytanie, do którego żadne z nich nie zostało zbudowane.

Jest to przeciwieństwo instynktu, który tworzy większość oprogramowania. Naturalne ciążenie każe sprawić, by jeden program robił więcej – dodać flagę, dodać tryb, wcielić następny wymóg w to, co już się ma. Pierwsza reguła McIlroya nazywa to ciążenie i odrzuca je: „Aby wykonać nowe zadanie, buduj od nowa, zamiast komplikować stare programy przez dodawanie nowych »funkcji«.”¹ Cały system Thompsona i Ritchiego jest dowodem na to, że prostota jest warunkiem wstępnym wszystkiego innego oraz że to składanie – a nie funkcje – sprawia, że małe rzeczy stają się potężne.

Kontekst

Unix narodził się z porażki. Przez całą połowę lat 60. Bell Labs współpracowało z MIT i General Electric nad Multicsem, ogromnie ambitnym systemem operacyjnym z podziałem czasu, który miał robić niemal wszystko. Do 1969 roku rozrósł się tak bardzo i tak bardzo się spóźnił, że Bell Labs się wycofało, a badacze, którzy nad nim pracowali – Ken Thompson, Dennis Ritchie, Doug McIlroy, Joe Ossanna – pozostali sfrustrowani, z utratą wygodnego, interaktywnego środowiska obliczeniowego i mocnym poczuciem tego, jak nie należy budować systemu.²

Ken Thompson, urodzony 4 lutego 1943 roku w Nowym Orleanie, dołączył do Bell Labs w 1966 roku po uzyskaniu tytułów licencjata i magistra inżynierii elektrycznej oraz informatyki na UC Berkeley.³ Dennis Ritchie, urodzony 9 września 1941 roku w Bronxville w stanie Nowy Jork, dołączył do Computing Sciences Research Center w 1967 roku.⁴ W 1969 roku Thompson znalazł odrzucony PDP-7 – mały, już wówczas przestarzały minikomputer – i zaczął budować na nim malutki system operacyjny, po części po to, by uruchomić napisaną przez siebie grę Space Travel. Thompson później wyłożył podział pracy wprost: „Sam zrobiłem pierwszą z dwóch czy trzech wersji UNIX-a. A Dennis stał się ewangelistą.”³ Pierwsza wersja została napisana w asemblerze PDP-7.

Nazwa powstała jako żart. Tam, gdzie Multics był „Multiplexed”, nowy system był celowo mały, więc grupa nazwała go „UNICS” – Uniplexed Information and Computing Service – co było kalamburem kosztem Multicsa. Pisownia zmieniła się w „Unix”, a Brian Kernighan, któremu zwykle przypisuje się tę nazwę, później zauważył, że nikt nie potrafi do końca przypomnieć sobie, jak wyłoniła się ostateczna forma.² Małość nie była przypadkiem ani ograniczeniem, które należało przerosnąć. Była zamysłem projektowym.

Dzieło

Unix i system plików

Pierwszą rzeczą, którą Unix zrobił dobrze, był model tego, czym są zasoby komputera. Wcześniejsze systemy traktowały pliki, urządzenia i kanały komunikacji jako odmienne rodzaje rzeczy, każdy z własnym specjalnym interfejsem. Unix je scalił. Przedstawił jeden hierarchiczny system plików – drzewo katalogów – a następnie potraktował niemal wszystko jako plik w jego obrębie: nie tylko dokumenty, lecz także urządzenia i kanały komunikacji między procesami.² Program, który potrafił czytać z pliku i pisać do niego, mógł bez żadnej zmiany czytać z terminala, napędu taśmowego albo innego programu, ponieważ dla programu wszystko to były po prostu pliki.

Oto uniwersalny interfejs w swojej pierwszej postaci. „Wszystko jest plikiem” oznacza, że małe narzędzie nie potrzebuje odmiennej wersji dla każdego rodzaju danych wejściowych; potrzebuje jednej. Koszt składania spada niemal do zera, ponieważ każdy składnik mówi już tym samym językiem. Hierarchiczny system plików i jednolity interfejs open/read/write/close są powodem, dla którego reszta filozofii była w ogóle możliwa: nie da się składać narzędzi, z których każde domaga się złącza skrojonego na miarę.

C i przenośność

Drugim przełomem było uczynienie systemu przenośnym, a to wymagało języka. Ritchie stworzył C w latach 1969–1973, rozwijając go z języka B Thompsona, który z kolei wywodził się z BCPL.⁴ B był beztypowy i interpretowany; C dodał typy danych i struktury oraz kompilował się do wydajnego kodu maszynowego, dość bliskiego sprzętowi, by napisać w nim system operacyjny, a dość abstrakcyjnego, by przenosić go między maszynami.

Rozstrzygający moment nadszedł około 1973 roku, gdy Unix w wersji 4 został przepisany w C.² Aż do tej pory system operacyjny był językiem asemblera, przyspawanym na stałe do jednej maszyny, dla której go napisano. Przepisanie Uniksa w języku wysokiego poziomu graniczyło z herezją – powszechna wiedza głosiła, że kod systemowy musi być ręcznie dostrojonym asemblerem, bo inaczej będzie zbyt wolny. Thompson i Ritchie i tak to zrobili, a nagrodą była przenośność: Unix można było teraz przenosić na nowy sprzęt poprzez portowanie kompilatora zamiast przepisywania całego systemu. Ta jedna decyzja jest w przeważającej mierze powodem, dla którego Unix rozszerzył się na każdy zakątek informatyki, podczas gdy jego współcześni pozostali przykuci do swojego pierwotnego żelaza. W 1978 roku Ritchie i Kernighan opublikowali The C Programming Language – „K&R” – oszczędną, precyzyjną książkę, która nauczyła całe pokolenie pisać w C i pozostaje wzorcem prozy technicznej.⁵ Thompson i Ritchie ogłosili sam system szerszemu światu w artykule „The UNIX Time-Sharing System” w lipcowym numerze Communications of the ACM z 1974 roku.⁶

Potoki i model składania

Jeśli system plików sprawił, że narzędzia mówiły tym samym językiem, to potoki sprawiły, że rozmawiały ze sobą. Pomysł należał do Douga McIlroya: przez lata zabiegał o sposób łączenia programów koniec w koniec, tak by wyjście jednego płynęło wprost do następnego, niczym odcinki ogrodowego węża. Thompson wdrożył go w 1973 roku – jak głosi legenda, w ciągu jednej nocy – dodając wywołanie systemowe pipe() oraz operator | do powłoki.⁷ McIlroy opisał to, co stało się potem: „Następny dzień przyniósł niezapomnianą orgię jednolinijkowców, gdy wszyscy przyłączyli się do podniecenia hydrauliką.”⁷

Ta orgia jednolinijkowców jest filozofią w działaniu. Nikt nie musiał pisać nowego programu; odkryto, że małe programy, które już istniały, można nawlec na siebie, by odpowiedzieć na pytania, do których żaden z nich nie został zaprojektowany. Potok taki jak grep, potem cut, potem sort, potem uniq -c, potem sort -rn, a potem head jest zbudowany z sześciu etapów, z których każdy jest nieświadomy pozostałych, każdy robi jedną rzecz i są one składane od lewej do prawej przez strumień tekstu. Możliwość jest wyłaniająca. Mieszka w |, a nie w którymkolwiek pojedynczym poleceniu.

To najgłębsza idea w całym systemie. Większość oprogramowania rośnie przez nawarstwianie: program wchłania każdy nowy wymóg, aż staje się monolitem, który rozumieją tylko jego autorzy. Unix rośnie przez składanie: system pozostaje zestawem małych części, a nowe możliwości biorą się z nowych ułożeń starych części. Strumień tekstu jest uniwersalnym interfejsem, który czyni te ułożenia darmowymi. Dlatego właśnie uniksowa powłoka, pięćdziesiąt lat później, wciąż jest jednym z najbardziej wyrazistych środowisk programistycznych w ogóle – nie pomimo tego, że składa się z maleńkich, jednozadaniowych programów, lecz właśnie dlatego.

Trusting Trust i późniejsze dziedzictwo

W 1983 roku Thompson i Ritchie wspólnie otrzymali Nagrodę Turinga ACM. Uzasadnienie brzmi: „za rozwój ogólnej teorii systemów operacyjnych, a w szczególności za implementację systemu operacyjnego UNIX”, a oświadczenie komisji nazywa tę zasadę dokładnie: „Sukces systemu UNIX wypływa z gustownego doboru kilku kluczowych idei i ich eleganckiej implementacji.”⁸ Gustowny dobór kilku kluczowych idei – nagrodę przyznano w istocie za powściągliwość.

Własny wykład turingowski Thompsona, opublikowany w 1984 roku jako „Reflections on Trusting Trust”, skierował tę samą minimalistyczną surowość na bezpieczeństwo. Wykazał, że kompilator można nauczyć wstawiania tylnego wejścia do programu login oraz wstawiania samego mechanizmu wstawiania tylnego wejścia do każdego przyszłego kompilatora, który ten skompiluje – tak że złośliwy kod żył jedynie w pliku wykonywalnym, nie pozostawiając najmniejszego śladu w jakimkolwiek kodzie źródłowym, który można by sprawdzić. Jego wniosek to jedno z najczęściej cytowanych zdań w informatyce: „Nie można ufać kodowi, którego nie stworzyłeś całkowicie samodzielnie… Żadna ilość weryfikacji ani analizy na poziomie kodu źródłowego nie ochroni cię przed użyciem niezaufanego kodu.”⁹ To założycielski tekst myślenia o bezpieczeństwie łańcucha dostaw – uznanie, że tym, czemu ufamy, nie jest kod źródłowy, lecz cały zestaw narzędzi, który wytworzył plik wykonywalny.

Późniejsze kariery tej pary przedłużyły te same instynkty. Thompson pozostał niespokojny: w Bell Labs zbudował system operacyjny Plan 9 (popychając „wszystko jest plikiem” jeszcze dalej, w poprzek sieci), edytor ed oraz praktyczną teorię wyrażeń regularnych i grep. W 1992 roku wraz z Robem Pikiem zaprojektował UTF-8 – kodowanie tekstu o zmiennej szerokości, które dziś przenosi niemal cały tekst świata – w ciągu jednego wieczoru, jak głosi legenda naszkicowane na podkładce stołowej.³ A w 2007 roku, w Google, Thompson współprojektował język programowania Go wraz z Robertem Griesemerem i Robem Pikiem, publicznie ogłoszony w 2009 roku: celowo mały, szybko się kompilujący, składalny język, który czyta się jak świadomy powrót do wartości Uniksa.¹⁰ Ritchie, który zmarł 12 października 2011 roku, pozostawił cichszy, lecz bardziej wszechobecny ślad; jak ujął to historyk Paul Ceruzzi: „gdyby mieć mikroskop i móc zajrzeć do wnętrza komputera, jego dzieło widać byłoby wszędzie w środku.”⁴

Metoda

Metoda jest spójna na przestrzeni czterdziestu lat i dwóch ludzi, którzy rzadko musieli ją wyjaśniać.

Buduj małe, ostre narzędzia. Każdy program robi jedno zadanie. Tą dyscypliną jest odmowa: gdy pojawia się nowa potrzeba, odpowiedzią jest nowe narzędzie, a nie nowa flaga przyśrubowana do starego. „Buduj od nowa, zamiast komplikować stare programy.”¹

Składaj, zamiast nawarstwiać. Możliwości mają się wyłaniać z łączenia. System pozostaje zrozumiały, gdy jest zestawem małych części i rośnie przez przearanżowanie, a nie przez puchnięcie którejkolwiek części w monolit.

Standaryzuj interfejs, nie narzędzia. Jednoczący ruch – „wszystko jest plikiem”, strumienie czystego tekstu między programami – polega na uczynieniu połączenia uniwersalnym, tak by składniki mogły pozostać nieświadome siebie nawzajem. To tanie spojenia sprawiają, że małe części są potężne.

Wybieraj kilka kluczowych idei, z gustem. Wyrażenie komisji Turinga nie było pochlebstwem; było metodą. Unix jest sławny z tego, co pominął. Przenośność dzięki C, abstrakcja pliku, potok – garść decyzji, każda dźwigająca ogromny ciężar, z celowo nieobecnym zbędnym bałaganem.

Nie ufaj temu, czego nie możesz sprawdzić. „Trusting Trust” to metoda skierowana do wewnątrz: prostota i czytelność są nie tylko cnotami estetycznymi, lecz jedyną prawdziwą podstawą zaufania, ponieważ złożoność jest tam, gdzie kryją się rzeczy, których nie możesz dostrzec.

Łańcuch wpływów

Kto ich ukształtował

Multics, przez kontrprzykład. Najbardziej formującym wpływem był system, który pomogli zbudować, a potem od niego odeszli. Multics nauczył Thompsona i Ritchiego, w najdroższy możliwy sposób, ile kosztuje nadmierna ambicja – a Unix jest w dużej mierze zdyscyplinowaną reakcją przeciw niemu. (Wpływ formujący)

Doug McIlroy. Kierownik Computing Sciences Research Center, McIlroy wynalazł potok, na piśmie wyartykułował filozofię „rób jedną rzecz dobrze” i pełnił rolę nieustępliwego krytyka gustu grupy. Model składania należy do niego co najmniej tyle, ile do kogokolwiek innego, i to on jest właściwym autorem kanonicznego sformułowania tej filozofii. (Wpływ bezpośredni)

Kultura badawcza Bell Labs. Mała grupa równych sobie, obdarzona swobodą i dobrymi maszynami, optymalizująca pod kątem elegancji między sobą, a nie pod kątem mapy drogowej produktu. Unix nie został wyspecyfikowany przez kierownictwo; nawarstwił się z kultury, która ceniła to, co gustowne, i wyśmiewała to, co rozdęte. (Wpływ formujący)

Kogo ukształtowali

Każdego potomka Uniksa. Linux, systemy BSD i macOS są bezpośrednimi spadkobiercami w prostej linii; system, który Thompson i Ritchie napisali na odrzuconym PDP-7, dziś działa na większości serwerów, telefonów i urządzeń wbudowanych na Ziemi.

Każdą powłokę i wiersz poleceń. Potok i model składania są codziennym środowiskiem pracy w zasadzie każdego programisty i administratora systemu, pięćdziesiąt lat później – niezmienione w swej istocie, ponieważ ta istota była słuszna.

C i jego dzieci. C stało się lingua franca programowania systemowego, a jego składnia i semantyka pobrzmiewają w C++, Javie, Go, Ruście i w większości tego, co pisze się dzisiaj. K&R pozostaje wzorcem tego, jak dokumentować język.

Samą filozofię Uniksa. „Rób jedną rzecz dobrze” przerosło Uniksa, stając się ogólną zasadą projektowania – dla mikrousług, dla narzędzi wiersza poleceń, dla podejścia do sieci opartego na braku kompilacji i małych elementach oraz dla tego, jak utrzymywać systemy SI dość małe, by pozostały bezpieczne i czytelne.

Nić przewodnia

Thompson i Ritchie są wyrazem na poziomie systemowym tego samego przekonania, które przewija się przez całą tę serię. Edsger Dijkstra dowodził, że prostota jest warunkiem wstępnym niezawodności; Unix jest tym argumentem skompilowanym i dostarczonym – jądrem złożonym z kilku kluczowych idei, utrzymanym dość małym, by mu ufać. „Dobry gust” Linusa Torvaldsa, przepisanie, w którym znika przypadek szczególny, to „rób jedną rzecz dobrze” wewnątrz pojedynczej funkcji, a nie w poprzek potoku; a Torvalds zbudował Linuksa i Gita wprost na fundamencie, który ci dwaj położyli. Szybki, prosty rdzeń Johna Carmacka to ta sama redukcja wymierzona w sprzętowy sufit. A zaprojektowanie Ruby dla ludzkiego szczęścia przez Yukihiro Matsumoto to uniksowy instynkt – składalne, wyraziste małe elementy – przeniesiony w górę do języka wysokiego poziomu. Nić przewodnia jest jednym zdaniem: moc powinna brać się ze składania małych, zrozumiałych części przez uniwersalny interfejs, a nie z rozrastania się którejkolwiek pojedynczej części. (Most serii)

Co z tego biorę dla siebie

Lekcją, którą zachowuję, jest to, że interfejs jest architekturą. Gdy projektuję teraz cokolwiek – agenta, pętlę narzędziową, ciąg skryptów – pokusą jest zawsze, by uczynić jeden składnik mądrzejszym, by wcielić następny wymóg w to, co już mam, aż stanie się monolitem, który rozumiem tylko ja. Uniksowy ruch jest przeciwny: utrzymuj każdy element dość małym, by w pełni go zrozumieć, a inteligencję włóż w to, jak elementy się łączą. Czyste, uniwersalne spojenie między głupimi częściami za każdym razem bije sprytną część bez czystych spojeń. To ten sam standard, co jakość jako jedyna zmienna – pytanie nigdy nie brzmi „czy ten jeden program może robić więcej?”, lecz „czy ten system wciąż składa się z części, o których potrafię rozumować?”.

W świecie, w którym teraz buduję – agenci SI połączeni narzędziami i tekstem – projekt Thompsona i Ritchiego jest bardziej trafny, niż ma do tego prawo w wieku ponad pięćdziesięciu lat. Agent jest małym programem; narzędzie jest małym programem; tym, co czyni je potężnymi, jest czysty, uniwersalny interfejs między nimi, którym dziś jest w przeważającej mierze ustrukturyzowany tekst. To potok, zbudowany na nowo. A „Trusting Trust” to ostrzeżenie, które biorę najpoważniej: gdy system generuje kod szybciej, niż ktokolwiek zdoła go przeczytać, jedyną trwałą podstawą zaufania jest utrzymywanie części małymi, a spojeń czytelnymi, ponieważ złożoność jest dokładnie tym miejscem, gdzie chronią się rzeczy, których nie możesz dostrzec. To przekonanie – że gust jest systemem technicznym i że małe, składalne, dające się sprawdzić elementy nie są udogodnieniem, lecz całą grą – biegnie prosto od komputera PDP-7 z 1969 roku do struktury agentowej z 2026 roku.

FAQ

Czym jest filozofia Uniksa?

Filozofia Uniksa to podejście projektowe zbudowane na małych, jednozadaniowych narzędziach, które składają się przez uniwersalny interfejs. Jej kanoniczne sformułowanie, autorstwa Douga McIlroya z 1978 roku, brzmi: „Pisz programy, które robią jedną rzecz i robią ją dobrze. Pisz programy, które współpracują ze sobą. Pisz programy, które obsługują strumienie tekstu, ponieważ jest to uniwersalny interfejs.” Pierwsza zasada to budowanie nowego narzędzia zamiast dodawania funkcji do istniejącego, a moc systemu bierze się z łączenia małych części – przez potoki i czysty tekst – a nie z rozrastania się któregokolwiek pojedynczego programu.¹

Czy Ken Thompson powiedział „rób jedną rzecz dobrze”?

Nie. Maksymę „rób jedną rzecz dobrze” i szerszą filozofię Uniksa wyartykułował na piśmie Doug McIlroy, kierownik Computing Sciences Research Center w Bell Labs, w przedmowie do specjalnego wydania Bell System Technical Journal o Uniksie z 1978 roku.¹ Thompson i Ritchie zbudowali system, który ucieleśnia tę filozofię, a McIlroy – który wynalazł również uniksowy potok – był jej najjaśniejszym wyrazicielem i rezydującym krytykiem gustu grupy. Przypisywanie tej maksymy Thompsonowi to powszechny, lecz błędny skrót.

Co właściwie stworzyli Thompson i Ritchie?

Ken Thompson zbudował pierwsze wersje systemu operacyjnego Unix na PDP-7, zaczynając w 1969 roku, a później stworzył język B, edytor ed, praktyczne wyszukiwanie za pomocą wyrażeń regularnych (grep), system Plan 9, UTF-8 (wraz z Robem Pikiem) oraz współprojektował Go w Google.³ Dennis Ritchie stworzył język programowania C (1969–1973), użył go do przepisania Uniksa w 1973 roku, by uczynić go przenośnym, a także był współautorem The C Programming Language wraz z Brianem Kernighanem w 1978 roku.⁴⁵ Wspólnie otrzymali Nagrodę Turinga ACM z 1983 roku za Uniksa.⁸

Czym jest „Reflections on Trusting Trust”?

To wykład Kena Thompsona z okazji Nagrody Turinga ACM z 1984 roku, opublikowany w Communications of the ACM. Pokazał, że kompilator można zmusić do wstawienia ukrytego tylnego wejścia do programu oraz do odtwarzania tego tylnego wejścia za każdym razem, gdy kompiluje nową wersję samego siebie – tak że złośliwy kod istniał jedynie w pliku wykonywalnym i nie pozostawiał żadnego śladu w jakimkolwiek kodzie źródłowym, który można by odczytać. Jego wniosek: „Nie można ufać kodowi, którego nie stworzyłeś całkowicie samodzielnie… Żadna ilość weryfikacji ani analizy na poziomie kodu źródłowego nie ochroni cię przed użyciem niezaufanego kodu.” To fundamentalny tekst bezpieczeństwa łańcucha dostaw oprogramowania.⁹

Źródła