Filozofia inżynierii: Donald Knuth, programowanie jest sztuką

Najważniejsze wnioski

• Programowanie jest sztuką, nie tylko inżynierią. Knuth nieprzypadkowo zatytułował dzieło swojego życia The Art of Computer Programming, poddając kod miernikowi piękna, którego nie zmierzy żaden zestaw testów.
• Kod to literatura pisana dla ludzi. Pierwszym odbiorcą jest następna osoba, która przeczyta program; kompilator jest dopiero drugi w kolejności. Czytelność to wymóg inżynierski pierwszej kategorii, a nie uprzejmość.
• Rygor stosuj tam, gdzie się liczy; powściągliwość — wszędzie indziej. Dowiedź poprawności algorytmów, przeanalizuj dokładnie ich koszt, dopracuj rzemiosło do ostatniego znaku — i odmów wkładania wysiłku w te 97% kodu, które nie mają znaczenia.
• „Przedwczesna optymalizacja” znaczy: najpierw zmierz. Słynne zdanie to dyscyplina pomiaru, a nie wymówka dla wolnego kodu: znajdź przez profilowanie te krytyczne kilka procent, uderz wyłącznie w nie i pozostaw resztę czytelną.

Zasada

„Zamiast wyobrażać sobie, że naszym głównym zadaniem jest instruowanie komputera, co ma robić, skupmy się raczej na wyjaśnianiu ludziom, co chcemy, aby komputer robił.” — Donald Knuth¹

Jedno zdanie zawiera całą postawę. Dla Knutha program nie jest przede wszystkim strumieniem instrukcji skierowanym do maszyny; jest tekstem skierowanym do człowieka — do następnego czytelnika, którym zazwyczaj jest się samemu, pół roku później, po zapomnieniu wszystkiego. Kompilator to odbiorca drugorzędny. Pierwszym odbiorcą jest człowiek, a program albo jest dla niego literaturą, albo jest porażką — bez względu na to, jak poprawnie działa.

To dlatego Knuth zatytułował dzieło swojego życia The Art of Computer Programming, a nie The Science czy The Engineering. Sztukę rozumie dosłownie: jako rzemiosło uprawiane dla jakości wytworzonej rzeczy, poddane miernikowi piękna, którego nie zmierzy żaden zestaw testów. Wynikająca z tego dyscyplina jest wymagająca w bardzo określony sposób. Mówi: zrób tę niewielką liczbę rzeczy, które naprawdę się liczą, i zrób je dokładnie tak, jak trzeba. Udowodnij poprawność swoich algorytmów. Przeanalizuj precyzyjnie ich koszt, zamiast zgadywać. Złóż stronę tak, by dała się czytać bez tarcia. I — to ta część, którą wszyscy cytują, a której prawie wszyscy nie rozumieją — nie wkładaj rzemiosła w te 97% kodu, które nie mają znaczenia, ponieważ wysiłek wlany w niewłaściwe miejsce nie jest kunsztem, lecz marnotrawstwem przebranym za staranność.

Zasada ma więc dwie twarze, które wyglądają na przeciwstawne, a w rzeczywistości są jednym. Rygor wszędzie tam, gdzie się liczy; powściągliwość wszędzie tam, gdzie się nie liczy. Sztuką jest wiedzieć, co jest czym — a odpowiedź Knutha na pytanie skąd to wiesz jest tą samą odpowiedzią, która przewija się przez całą tę serię: mierzysz. Słynne zdanie o przedwczesnej optymalizacji nie jest przyzwoleniem na pisanie wolnego kodu. Jest żądaniem, byś najpierw, na podstawie dowodów, znalazł te krytyczne kilka procent, zanim czegokolwiek dotkniesz — to samo przekonanie, które głosi, że wydajność to właściwość, którą się wbudowuje i mierzy, a nie warstwa dodawana na końcu.

Kontekst

Donald Ervin Knuth urodził się 10 stycznia 1938 roku w Milwaukee w stanie Wisconsin.² Uzyskał tytuły licencjata i magistra w Case Institute of Technology — uczelnia była pod takim wrażeniem, że w 1960 roku przyznała mu magisterium jednocześnie z licencjatem — oraz doktorat z matematyki w Caltechu w 1963 roku.² W 1969 roku dołączył do kadry Stanford, w 1977 roku został profesorem informatyki imienia Fletchera Jonesa, a w 1990 roku przyjął tytuł, który w istocie wymyślił dla siebie sam: profesor The Art of Computer Programming.² Od lat jest profesorem emerytowanym Stanford i wciąż pracuje — ręcznie i listownie — nad tym samym projektem, który zajmuje go od ponad sześciu dekad.

Projekt ten zaczął się od przypadkowego rozrostu zakresu. W 1962 roku wydawnictwo Addison-Wesley zleciło młodemu Knuthowi napisanie książki o kompilatorach.³ Zaczął pisać i doszedł do wniosku, że nie da się uczciwie wyjaśnić, jak zbudować kompilator, bez uprzedniego wyłożenia leżącej u jego podstaw fundamentalnej teorii — sortowania, wyszukiwania, struktur danych, analizy tego, ile czasu algorytmy faktycznie zabierają. Jedna książka stała się planowaną serią. Pierwszy tom, Fundamental Algorithms, ukazał się w 1968 roku. Plan rozrósł się ostatecznie do siedmiu tomów, a dzieło do dziś pozostaje nieukończone.³ American Scientist zaliczył je później do około stu książek, które ukształtowały stulecie nauki, a New York Times nazwał je „definiującym traktatem tej profesji”.³ Według rozsądnego konsensusu jest to coś najbliższego biblii, jaką ma informatyka.

W 1974 roku Knuth otrzymał Nagrodę Turinga ACM A.M. — najwyższe wyróżnienie w informatyce — „za szereg istotnych wkładów w analizę algorytmów i projektowanie języków programowania, a w szczególności za najznaczniejszy wkład w »sztukę programowania komputerów« poprzez serię jego znanych książek”.⁴ Jego wykład turingowski nosił, jakże charakterystycznie, tytuł „Computer Programming as an Art”.⁴

Dzieło

The Art of Computer Programming i analiza algorytmów

Knutha nazywa się ojcem analizy algorytmów — i tytuł ten jest zasłużony.² Przed TAOCP programiści rozumowali o algorytmach głównie nieformalnie: ten wydaje się szybszy, tamten zdaje się rozrzutny. Projektem Knutha było postawienie tego rozumowania na rygorystycznych podstawach matematycznych: wyprowadzenie dokładnej liczby operacji, jakie algorytm wykonuje w funkcji swoich danych wejściowych, i to z taką samą precyzją, z jaką matematyk podchodzi do twierdzenia. Spopularyzował asymptotyczną notację „dużego O”, której dziś używa każdy programista do opisu tego, jak skaluje się koszt.² Nigdy nie chodziło o notację; chodziło o przekonanie, że koszt programu to wielkość poznawalna, którą należy obliczyć, a nie przeczucie, które się ma.

Same tomy słyną z pewnego rodzaju obsesyjnej kompletności — każde twierdzenie udowodnione, każdy algorytm przeanalizowany, każdy przypadek brzegowy obsłużony — oraz z czeków nagrody, które Knuth wystawia za każdy znaleziony błąd. Czek opiewa na 2,56 dolara, co opisuje jako „jednego szesnastkowego dolara”, ponieważ 256 centów to 100 w systemie szesnastkowym.⁵ Kwota jest żartem; stojąca za nią dyscyplina — nie. Knuth stawia pieniądze na to, że jego praca jest poprawna, i zaprasza świat, by dowiódł mu, że się myli. Dopracowany, wciąż autorytatywny stan TAOCP po dekadach jest po części wytworem tego trwającego zakładu.⁵ (W 2008 roku przestał wysyłać prawdziwe czeki po oszustwie bankowym i teraz wystawia certyfikaty wymierzone w wyimaginowany „Bank of San Serriffe” — rygor przetrwał; zmienił się ślad papierowy.)⁵

Przedwczesna optymalizacja i krytyczne 3%

Najczęściej cytowane zdanie w inżynierii oprogramowania należy do Knutha — i niemal zawsze cytowane jest błędnie, pozbawione zdania podrzędnego, które nadaje mu sens. Oto pełen fragment z jego artykułu z 1974 roku „Structured Programming with go to Statements”, opublikowanego w ACM Computing Surveys:

„Programiści marnują ogromne ilości czasu, myśląc o szybkości niekrytycznych części swoich programów albo się o nią zamartwiając, a te próby uzyskania wydajności mają w istocie silnie negatywny wpływ, gdy weźmie się pod uwagę debugowanie i utrzymanie. Powinniśmy zapomnieć o drobnych usprawnieniach, powiedzmy w jakichś 97% przypadków: przedwczesna optymalizacja jest źródłem wszelkiego zła. A jednak nie powinniśmy przepuszczać naszych okazji w tych krytycznych 3%.”⁶

Czytane w całości, nie jest to argument przeciwko wydajności. Jest to argument za pomiarem. Pointa Knutha jest empiryczna: program spędza niemal cały swój czas w drobnym ułamku swojego kodu, a optymalizowanie pozostałych 97% — części, które ledwie się wykonują — kosztuje realny wysiłek, kupuje prawie nic i sprawia, że kod staje się trudniejszy do czytania i do zaufania. „Złem” nie jest optymalizacja. Złem jest optymalizowanie, zanim wiesz, na co schodzi czas — wkładanie rzemiosła w wiarę zamiast w dowód. Dyscyplina, którą zaleca, jest przeciwieństwem lenistwa: znajdź przez profilowanie te krytyczne 3%, a potem uderz w nie z całą mocą.

Słowo o atrybucji, bo ma to znaczenie dla każdego, kto cytuje to zdanie uczciwie. Zdanie pojawia się w artykule Knutha z 1974 roku, w jego własnej prozie. Lecz piętnaście lat później sam Knuth określił je jako „maksymę Hoare’a”, przypisując je Tony’emu Hoare’owi — a gdy zapytano wprost Hoare’a, on również się go wyparł, sugerując, że być może należy do Dijkstry, i że najlepiej traktować je jako „wspólną kulturę albo folklor”.⁷ Najczystsze i najściślejsze stwierdzenie brzmi więc tak: sformułowanie, które wszyscy cytujemy, należy do Knutha, opublikowane przez Knutha w 1974 roku; idei zaś wielkodusznie odmówił uznawania za wyłącznie własną. Sama ta odmowa jest dla niego znamienna. Człowiek, który płaci ci za znajdowanie jego błędów, nie jest zainteresowany przypisywaniem sobie zasług, co do których nie ma pewności, że mu się należą.

TeX, METAFONT i typografia cyfrowa jako rzemiosło

W 1976 roku Knuth otrzymał odbitki szpaltowe drugiego wydania tomu 2 i był zbulwersowany. Skład gorącym metalem, który uczynił pierwsze wydanie pięknym, zastępowano wczesnym fotoskładem, a rezultat był brzydki — zwłaszcza matematyka wyglądała źle.³ Ktoś inny przyjąłby to jako cenę postępu. Knuth, który nie mógł znieść, by jego własne książki były źle składane, postanowił w 1977 roku poświęcić trochę czasu na zbudowanie czegoś lepszego. To trochę czasu rozrosło się w niemal całą dekadę. Rezultatem był TeX, system składu, oraz METAFONT, towarzyszący mu system do projektowania samych krojów pisma; oba ukończono i opublikowano w postaci książek w 1986 roku.³

Żaden inny zakręt jego kariery nie odsłania więcej. Matematyk przerwał swoje opus magnum na osiem lat, by od podstaw rozwiązać problem umieszczania pięknych znaków na stronie — ponieważ w jego umyśle wygląd strony nie był oddzielny od jakości pracy. TeX, czterdzieści lat później, wciąż jest światowym standardem składu matematyki. To najjaśniejsze możliwe stwierdzenie, że dla Knutha artefakt sięga aż do ostatniego piksela ostatniego znaku: rzemiosło nie kończy się na kodzie. To inżynierska wersja wykończenia tylnej strony płotu — część, której czytelnik nigdy świadomie nie zauważa, jest tą częścią, której Knuth odmówił zrobienia byle jak.

Programowanie piśmienne

Jeśli program ma być czytany przez ludzi, to sposób, w jaki go piszemy — w kolejności narzucanej przez kompilator, z komentarzami doczepionymi po fakcie — jest odwrócony. W 1984 roku, w artykule w The Computer Journal, Knuth zaproponował jego odwrócenie. Praktykę tę nazwał programowaniem piśmiennym (literate programming) i zbudował do niej system o nazwie WEB.¹

W programowaniu piśmiennym pisze się jeden dokument w kolejności ludzkiej myśli — prozę wyjaśniającą zamiary, z wplecionymi fragmentami kodu tam, gdzie domaga się ich wyjaśnienie, w dowolnej sekwencji, która czyta się najlepiej. Dwa narzędzia następnie go przetwarzają: tangle wydobywa kod w kolejności, jakiej potrzebuje kompilator, a weave wytwarza sformatowaną, złożoną dokumentację, którą czyta człowiek.⁸ WEB łączył Pascal i TeX; późniejszy CWEB, opracowany z Silviem Levym, zrobił to samo dla języka C.⁸ Według własnego opisu Knutha „program najlepiej jest pojmować jako sieć… zadaniem programisty jest sformułowanie tych części i tych relacji w takiej kolejności, jaka jest najlepsza dla ludzkiego zrozumienia”.⁸

Programowanie piśmienne nigdy nie stało się powszechną praktyką i warto przyznać to uczciwie. Lecz przekonanie leżące u jego podstaw — że wyjaśnienie nie jest dokumentacją programu, ale jest programem; że czytelność to wymóg inżynierski pierwszej kategorii, a nie uprzejmość — po cichu zwyciężyło. To ten sam instynkt, który każe nam cenić kod, który sam siebie tłumaczy, i jest to najgłębsza odpowiedź, jakiej Knuth udziela na pytanie, do czego programowanie służy.

Metoda

Metoda jest spójna na przestrzeni sześćdziesięciu lat i czterech dziedzin — algorytmów, typografii, projektowania języków oraz samego pisania.

Pisz najpierw dla ludzkiego czytelnika. Maszyna jest drugim odbiorcą. Program, podobnie jak dowód czy akapit, ocenia się po tym, czy następna osoba potrafi za nim podążyć. Programowanie piśmienne to owo przekonanie przekute w narzędzie.¹⁸

Udowodnij, a potem przetestuj. „Strzeżcie się błędów w powyższym kodzie; udowodniłem jedynie jego poprawność, nie wypróbowałem go” — napisał Knuth w notatce z 1977 roku — zdanie zabawne właśnie dlatego, że jest on tą rzadką osobą, która faktycznie dowodzi poprawności swojego kodu.⁹ Żart zawiera w sobie dyscyplinę: poprawności się dowodzi, a nie zakłada, a dowód jest konieczny, lecz wciąż niewystarczający. Jesteś winien jedno i drugie.

Analizuj koszt; nie zgaduj go. Czas działania algorytmu to wielkość, którą należy wyprowadzić matematycznie, a nie przeczucie. To akt założycielski analizy algorytmów i dlatego właśnie „duże O” jest na ustach każdego programisty.²

Mierz, zanim zoptymalizujesz. Przedwczesna optymalizacja jest źródłem wszelkiego zła, ponieważ wkłada rzemiosło w wiarę. Znajdź na podstawie dowodów te krytyczne 3%; optymalizuj wyłącznie tam; pozostaw resztę czytelną.⁶

Pozwól rzemiosłu sięgnąć aż do ostatniego znaku. Wstrzymanie dzieła swojego życia na osiem lat, by zbudować TeX, to metoda w najczystszej postaci: jakość artefaktu nie kończy się tam, gdzie kończy się kod. Kończy się na krawędzi strony.³

Chroń głębokie skupienie. Knuth zrezygnował z poczty elektronicznej 1 stycznia 1990 roku — „od tamtej pory jestem szczęśliwym człowiekiem”, napisał — uzasadniając to tym, że e-mail jest dla ludzi, których zadaniem jest być na bieżąco ze wszystkim, podczas gdy jego zadaniem jest być u podstaw rzeczy, zgłębiając temat na tyle dogłębnie, by umieć go dobrze wyjaśnić.¹⁰ Odmowa przerywania nie jest ekscentryzmem; jest warunkiem wstępnym pracy.

Łańcuch wpływów

Kto go ukształtował

Tradycja matematyczna, zwłaszcza kombinatoryka i teoria liczb. Knuth przyszedł do programowania jako matematyk i wniósł do dziedziny, która dotąd radziła sobie intuicją, nienegocjowalny standard matematyka — twierdzenie nie jest wiedzą, dopóki nie zostanie udowodnione. (Wpływ formujący)

Zlecenie Addison-Wesley z 1962 roku. Przypadek, który nadał trajektorię. Poproszony o książkę o kompilatorach, Knuth podążył za problemem aż do jego fundamentów i nigdy stamtąd nie wrócił; analiza algorytmów istnieje w swojej współczesnej postaci, ponieważ odmówił napisania łatwej książki, o którą go poproszono. (Wpływ bezpośredni)

Typografia gorącego metalu i drukowana książka. Jego standard tego, jak powinna wyglądać złożona strona, ukształtował kunszt wcześniejszej epoki druku — i właśnie dlatego fotoskładane odbitki z 1976 roku były nie do zniesienia, a TeX stał się konieczny. (Wpływ formujący)

Kogo on ukształtował

Każdego praktykującego programistę. Analiza „dużego O”, rygorystyczne badanie algorytmów i samo TAOCP to bazowa piśmienność. Całe pokolenie nauczyło się, ile algorytm kosztuje, od Knutha — niezależnie od tego, czy kiedykolwiek otworzyło jego książki.

Światowe wydawnictwa matematyczne i naukowe. TeX i LaTeX są podłożem zasadniczo każdej pracy matematycznej, każdego preprintu fizycznego i każdej książki technicznej złożonej w ciągu ostatnich czterdziestu lat. Ośmioletni zakręt Knutha stał się infrastrukturą.

Kulturę poprawności i czytelności. Programowanie piśmienne, czeki nagrody, „udowodniłem poprawność, nie wypróbowałem” — to nadało ton. Oczekiwanie, że poważny kod powinien być zarazem dowiedlnie poprawny i przyjemny w czytaniu, jest po części spuścizną Knutha.

Nić przewodnia

Knuth i Edsger Dijkstra to dwaj wielcy apostołowie poprawności w tej serii, a płodne napięcie między nimi jest w niej rzeczą najbardziej pouczającą. Obaj pisali ręcznie, nie ufali maszynie jako arbitrowi prawdy i nalegali, by o programie należało rozumować, a nie jedynie go uruchamiać. Lecz tam, gdzie Dijkstra utrzymywał, że testowanie może jedynie wykazać obecność błędów, lecz nigdy ich nieobecność — i mocno skłaniał się ku dowodowi jako jedynemu prawdziwemu gruntowi — Knuthowe „udowodniłem jedynie poprawność, nie wypróbowałem” mruga okiem na granicę samego dowodu: on dowodzi i testuje, i płaci ci, gdy obie metody chybią. Pragmatyzm wewnątrz rygoru. John Carmack siedzi na tej samej osi, lecz od drugiego jej końca — profiluj wąskie gardło, zrozum maszynę aż do fundamentu, uderz w krytyczną pętlę — co jest dokładnie Knuthowym „krytycznym 3%” wymierzonym w sufit sprzętowy, a nie w dowód. A Unix Thompsona i Ritchiego, w którym C zbudowano po to, by system operacyjny dało się czytać i przenosić, zamiast spawać go ręcznie z jedną maszyną, to to samo przekonanie, które Knuth wyraził wprost: programy pisze się dla ludzi. (Pomost serii)

Co z tego biorę

Lekcją, którą zachowuję, jest to, że najczęściej cytowane zdanie w mojej dziedzinie to dyscyplina pomiaru przebrana w kostium aforyzmu. „Przedwczesna optymalizacja jest źródłem wszelkiego zła” bywa używane jako usprawiedliwienie wolnego, leniwego kodu, co jest dokładnym odwróceniem tego, co Knuth miał na myśli. To, czego on faktycznie żąda, jest trudniejsze niż optymalizowanie wszystkiego albo optymalizowanie niczego: najpierw profiluj, zlokalizuj na podstawie dowodów te krytyczne 3%, wlej swoje rzemiosło dokładnie w to i pozostaw resztę czytelną. To ten sam standard co jakość będąca jedyną zmienną — pytanie nigdy nie brzmi „czy to jest dość szybkie?” ani „czy to jest dość sprytne?”, lecz „czy mam dowód na to, gdzie naprawdę leży koszt?”. To bramka dowodu zastosowana do wydajności: przeczucie co do wąskiego gardła nie jest wiedzą, dopóki się go nie zmierzy.

W świecie, w którym dziś buduję — agenty, pętle narzędzi, wywołania modeli — obie twarze Knutha są nośne. Powściągliwość: nie optymalizuj promptu ani ścieżki pobierania, których nie zmierzyłeś; niemal całe opóźnienie tkwi w kilku wywołaniach, a reszta to szum, który należy pozostawić czytelnym. Rygor: tam, gdzie się to liczy, udowodnij, przetestuj i postaw coś na to, że masz rację. A przekonanie z programowania piśmiennego jest tym, które uważam za najbardziej istotne po pięćdziesięciu latach — gdy system potrafi generować kod szybciej, niż ktokolwiek zdoła go przeczytać, pisanie najpierw dla ludzkiego czytelnika przestaje być uprzejmością i staje się jedyną rzeczą, która utrzymuje system w stanie poddającym się inspekcji. To przekonanie — że smak jest systemem technicznym, który się mierzy i którego się broni, a nie nastrojem, który się głosi — biegnie wprost od zlecenia książkowego z 1962 roku do mechanizmu agenta z 2026 roku.

FAQ

Na czym polega filozofia inżynierii Donalda Knutha?

Knuth traktuje programowanie jako sztukę, której pierwszym odbiorcą jest człowiek, a nie maszyna: „wyjaśnianie ludziom, co chcemy, aby komputer robił”.¹ Wynikająca z tego dyscyplina łączy wymagający rygor z rozmyślną powściągliwością — dowiedź poprawności algorytmów, przeanalizuj matematycznie ich koszt i dopracuj rzemiosło aż do złożonej strony, odmawiając przy tym wkładania wysiłku w optymalizowanie tych części programu, które nie mają znaczenia. To, co jest czym, rozstrzyga pomiarem — i na tym polega prawdziwy sens jego zdania o przedwczesnej optymalizacji.⁶

Co naprawdę znaczyło „przedwczesna optymalizacja jest źródłem wszelkiego zła”?

To żądanie pomiaru, a nie odrzucenie wydajności. Pełny cytat z 1974 roku brzmi: „Powinniśmy zapomnieć o drobnych usprawnieniach, powiedzmy w jakichś 97% przypadków: przedwczesna optymalizacja jest źródłem wszelkiego zła. A jednak nie powinniśmy przepuszczać naszych okazji w tych krytycznych 3%”.⁶ Pointa Knutha jest taka, że program spędza niemal cały swój czas w drobnym ułamku swojego kodu; optymalizowanie pozostałych 97% marnuje wysiłek i szkodzi czytelności. Dyscyplina polega na tym, by najpierw profilować, znaleźć te krytyczne kilka procent i optymalizować wyłącznie je. Używanie tego zdania jako usprawiedliwienia wolnego kodu odwraca jego sens.

Czy to Knuth ukuł cytat o „przedwczesnej optymalizacji”, czy Hoare?

Sformułowanie, które wszyscy cytują, należy do Knutha, opublikowane w jego własnym artykule z 1974 roku w Computing Surveys pod tytułem „Structured Programming with go to Statements”.⁶ Piętnaście lat później jednak sam Knuth określił je jako „maksymę Hoare’a” i przypisał je Tony’emu Hoare’owi; gdy zapytano wprost Hoare’a, on również wyparł się autorstwa, zasugerował, że być może wywodzi się ono od Dijkstry, i stwierdził, że najlepiej traktować je jako „wspólną kulturę albo folklor”.⁷ Uczciwe podsumowanie: zdanie w postaci, w jakiej je cytujemy, należy do Knutha, lecz wielkodusznie odmówił on uznawania samej idei za wyłącznie własną.

Co stworzył Donald Knuth?

Knuth napisał The Art of Computer Programming (rozpoczęte w 1962 roku, pierwszy tom w 1968 roku, wciąż w toku — definiujący traktat informatyki) i ugruntował współczesną analizę algorytmów, popularyzując notację „dużego O”.²³ Sfrustrowany złym składem swoich własnych książek, stworzył system składu TeX oraz system krojów pisma METAFONT — oba opublikowane w 1986 roku i wciąż będące standardem wydawnictw matematycznych.³ Zapoczątkował również programowanie piśmienne i system WEB, czyli praktykę pisania programów tak, by czytali je ludzie.¹⁸ W 1974 roku otrzymał Nagrodę Turinga ACM.⁴

Źródła