sztuka-kodowania.-sekrety-wielkich-programistow full scan.pdf

Spis treści

O autorze

Podziękowania

Wprowadzenie

Rozdział 1.

Jamie Zawinski

Rozdział 2.

Brad Fitzpatrick

Rozdział 3.

Douglas Crockford

Rozdział 4.

Brendan Eich

101

Rozdział 5.

Joshua Bloch

123

Rozdział 6.

Joe Armstrong

147

Rozdział 7.

Simon Peyton Jones

169

Rozdział 8.

Peter Norvig

197

Rozdział 9.

Guy Steele

221

Rozdział 10. Dan Ingalls

251

Rozdział 11. L Peter Deutsch

277

Rozdział 12. Ken Thompson

299

Rozdział 13. Fran Allen

321

Rozdział 14. Bernie Cosell

341

Rozdział 15. Donald Knuth

369

Dodatek

Bibliografia

391

Skorowidz

395

ROZDZIAŁ

Peter Norvig

Peter Norvig jest z natury człowiekiem o szerokich horyzontach i hakerem. Kiedyś napisał program

do znajdowania w dziennikach wyszukiwania serwisu Google trzech kolejnych zapytań jednego użyt-

kownika składających się na haiku (oto jedno z tych, które najbardziej utkwiły mi w pamięci: „java

ECC / java elliptical curve / playboy faq”).

Na swojej stronie Norvig udostępnia odnośniki do standardowych materiałów: napisanych przez sie-

bie książek i prac, slajdów z wygłoszonych wykładów oraz różnych fragmentów kodu. Jednak oprócz

tego znajdują się tam odsyłacze do tekstów opublikowanych w McSweeney’s Quarterly Concern,

dowcipny opis prac nad programem do generowania rekordowo długich palindromów i prezentacja

Gettysburg Powerpoint Presentation (jest to parodia programu PowerPoint Microsoft wspomnia-

na przez Edwarda Tuftego i pojawiająca się na pierwszej stronie wyników po wpisaniu w wyszuki-

warce Google hasła PowerPoint ).

Norvig jest obecnie dyrektorem do spraw badań w firmie Google. Wcześniej piastował stanowisko

dyrektora do spraw jakości wyszukiwania. Przedtem kierował działem nauk obliczeniowych w ośrod-

ku NASA Ames Research Center, a jeszcze wcześniej pracował w powstałym pod koniec lat dziewięć-

dziesiątych dwudziestego wieku internetowym startupie Junglee. W 2001 roku Norvig otrzymał na-

grodę NASA Exceptional Achievement Award i jest członkiem organizacji American Association for

Artificial Intelligence oraz Association for Computing Machinery.

Dzięki pracy w Google, NASA i Junglee Norvig ma doświadczenie w stosowaniu „hakerskich” i „in-

żynieryjnych” technik budowania oprogramowania, a w wywiadzie opowiada o zaletach oraz wa-

dach obu tych podejść. Ponieważ jest byłym wykładowcą nauk komputerowych, a obecnie pracuje

w jednej z największych na świecie firm zajmujących się oprogramowaniem, ma też ciekawy punkt

widzenia na relacje między akademickimi naukami komputerowymi i praktyką ze świata przemysłu.

Oprócz tego, rozmawiamy, jak zmieniło się programowanie w ostatnich latach, dlaczego żadne tech-

niki projektowania nie zastąpią wiedzy na temat wykonywanych zadań i dlaczego dla NASA korzyst-

niejsze może być stosowanie bardziej zawodnego, ale tańszego oprogramowania.

198

Sztuka kodowania. Sekrety wielkich programistów

Seibel: Kiedy nauczyłeś się programować?

Norvig: W szkole średniej. Szkoła miała komputer PDP-8, tak mi się wydaje, i zapisałem się na

kurs. Zaczęliśmy od programowania w języku BASIC i to był mój początek.

Seibel: W którym to było roku?

Norvig: Skończyłem średnią szkołę 1974, dlatego musiał to być rok 1972 lub 1973. Pamiętam z tych

czasów parę rzeczy. Przykładowo nauczycielkę, która próbowała nauczyć nas tasowania talii kart.

Jej algorytm działał tak: użyj generatora liczb losowych do wyboru dwóch miejsc, a następnie za-

mień karty z tych pozycji miejscami; przechowuj wektor bitowy z informacją o przeniesionych

kartach i kontynuuj proces do czasu zamiany wszystkich kart. Pamiętam, że pomyślałem wtedy:

„To bez sensu. Musi to być najgłupsze rozwiązanie na świecie. Algorytm może działać w nieskoń-

czoność, ponieważ może znaleźć się jedna para, której nigdy nie wybierzemy”. Nie wiedziałem wte-

dy, że wystarczy stwierdzić, iż złożoność to n kwadrat, choć powinna to być złożoność liniowa n .

Wiedziałem jednak, że rozwiązanie jest po prostu złe. Potrafiłem wymyślić, jak mi się zdaje, algo-

rytm Knutha, który zamieniał kartę zerową z pięćdziesiątą drugą, potem zerową z pięćdziesiątą

pierwszą itd. — daje to złożoność liniową n . Pamiętam, że nauczycielka broniła swojego podej-

ścia. Wtedy pomyślałem: „No cóż, może mam talent do programowania”. Pomogło mi to także

stwierdzić, że chyba nauczyciele nie wiedzą wszystkiego.

Seibel: Czy zaraz po tym, jak nauczycielka opisała algorytm, uznałeś, że jest błędny? A może naj-

pierw przez pewien czas eksperymentowałeś z nim, a dopiero potem stwierdziłeś: „Jejku, to strasz-

nie dużo operacji”?

Norvig: Chyba od razu zauważyłem problem. Trudno stwierdzić, co naprawdę myślałem, ale chy-

ba od razu dostrzegłem, że algorytm może nie zakończyć pracy. Nie jestem pewien, czy równie

dobrze zdawałem sobie sprawę z oczekiwanego czasu działania.

Pamiętam też, że znalazłem na strychu stare numery „Scientific American” ojca. Był w nich arty-

kuł Christophera Stracheya na temat inżynierii oprogramowania. Strachey pisał, że zaczniemy

używać języków wyższego poziomu. Wymyślił język, dla którego nigdy nie utworzono kompilatora.

Był to język „papierowy”. Strachey stwierdził, że napisze w tym języku program do gry w warca-

by. Pamiętam, jak go czytałem. Był to pierwszy skomplikowany program, z którym się zapozna-

łem — w szkole uczyliśmy się tylko, jak tasować karty i robić podobne rzeczy. Niedawno ponow-

nie przeczytałem artykuł i pierwszą rzeczą, jaką zauważyłem, było to, że znajduje się w nim błąd.

To wspaniałe uczucie, ponieważ wiesz, że to Christopher Strachey i powinien wiedzieć, co robi.

Dodatkowo to magazyn „Scientific American” — pracują nad nim redaktorzy i inni ludzie, którzy

powinni wykryć błędy. W tekście autor twierdzi, że funkcja make-move przyjmuje pozycję na plan-

szy i zwraca posunięcie. Kiedy zajrzysz do kodu, zobaczysz, że funkcja make-move przyjmuje pozy-

cję na planszy i dodatkowy parametr. Najwidoczniej autor najpierw napisał tekst, a dopiero po-

tem kod. Okazało się, że głębokość przeszukiwania nie może być nieskończona, dlatego Strachey

dodał nowy parametr. Określa on głębokość przeszukiwania. Program przechodzi rekurencyjnie do

określonego poziomu, a następnie kończy przeszukiwanie. Operację tę dodano później, ale autor

nie poprawił dokumentacji.

Seibel: Był to więc pierwszy ciekawy kod, który przeczytałeś. Jaki pierwszy interesujący program

napisałeś?

Norvig: Chyba był to program Game of Life. Napisałem go w ramach zadania domowego. Szybko je

ukończyłem, a wtedy — oczywiście — nie mieliśmy dobrych wyświetlaczy. Nie posiadałem swoje-

go trzydziestocalowego monitora — miałem dalekopis z żółtym papierem. Stwierdziłem, że szkoda

drukować jedno małe pole (mieliśmy chyba użyć pola dziesięć na dziesięć kratek), a potem następne

Peter Norvig

199

i jeszcze następne. Dlatego stwierdziłem, że wydrukuję pięć pokoleń, jedno za drugim. Pamiętam,

że w języku BASIC nie można było stosować tablic trójwymiarowych, a z jakiegoś powodu nie

mogłem nawet użyć zestawu tablic dwuwymiarowych. Prowadziło to do wyczerpania pamięci lub

czegoś w tym rodzaju. Dlatego musiałem wymyślić, jak utworzyć pięć lub sześć potrzebnych tablic

dwuwymiarowych. Wtedy odkryłem pola bitowe.

Seibel: Z uwagi na ograniczenia pamięci utworzyłeś własną pamięć na dużą ilość danych. Czy ktoś

nauczył cię używać tablic bitów i wymyśliłeś, jak je zastosować, czy może przeglądałeś podręcznik

i stwierdziłeś: „O, popatrzcie, mamy tu instrukcje PEEK i POKE” lub coś w tym rodzaju?

Norvig: No cóż, zapisywałem w każdej lokalizacji zero lub jedynkę, a gdzie indziej musiałem za-

pisać więcej danych. Stwierdziłem: „Och, zapiszę inne liczby tutaj”. W zasadzie nawet nie pamię-

tam, czy użyłem pamięci bitowej. Możliwe, że stosowałem cyfry i to raczej dziesiętne niż dwójko-

we, ponieważ nikt nie przedstawił nam systemu dwójkowego w ciekawy sposób. Potem dodałem

różne możliwości, np. sprawdzanie, czy liczby się nie powtarzają, a jeśli tak, to w jakim cyklu. Nie

można było tego zrobić przy przechowywaniu tylko jednego wcześniejszego pokolenia.

Seibel: Kiedy rozwijałeś się jako programista, czy robiłeś coś specjalnego, aby wzbogacić swoje

umiejętności w tym obszarze, czy po prostu pisałeś programy?

Norvig: Wydaje mi się, że tylko pisałem programy. Przede wszystkim robiłem to, co sprawiało mi

przyjemność. Działo się tak zwłaszcza na studiach, kiedy byłem mniej zależny od harmonogramu.

Znajdowałem ciekawy problem i próbowałem go rozwiązać. Robiłem to dla przyjemności, a nie

dlatego, że prowadził do postępów w pisaniu pracy dyplomowej.

Seibel: W college’u studiowałeś przedmioty komputerowe, ale nauki komputerowe nie były twoim

głównym kierunkiem, prawda?

Norvig: Kiedy zaczynałem, kursy komputerowe były prowadzone na wydziale matematyki sto-

sowanej. Zanim ukończyłem college, powstał wydział nauk komputerowych, ale moim głównym

kierunkiem pozostała matematyka. Miałem wrażenie, że jeśli chcę ukończyć nauki komputerowe

jako główny kierunek, muszę jako główny kierunek studiować IBM. Trzeba było poznać ich asem-

bler, ich system operacyjny 360 itd. Nie uznałem tego za ciekawe. Niektóre kursy mi się podobały,

dlatego się na nie zapisałem, ale nie chciałem brać udziału we wszystkich wymaganych zajęciach.

Po college’u przez dwa lata pracowałem w firmie programistycznej w Cambridge. Po tych dwóch

latach stwierdziłem: „Szkoły zacząłem mieć dość po czterech latach, a pracy — po dwóch, może

więc dwa razy bardziej lubię szkołę?”.

Seibel: Co robiłeś w tej firmie?

Norvig: Jej głównym produktem był pakiet narzędzi do projektowania oprogramowania. Firma

prowadziła też doradztwo z różnych obszarów oprogramowania. Założyciele pracowali w Draper

Labs w Cambridge w ramach misji Apollo i nad podobnymi projektami. Mieli znajomości w lot-

nictwie i otrzymywali zlecenia od rządu. Posiadali swoją wizję projektowania oprogramowania.

Nigdy w nią nie wierzyłem, ale była ciekawa.

Pamiętam, że jeden z projektów w tej firmie wymagał napisania narzędzia do rysowania diagra-

mów przepływu. Pomysł polegał na tym, że narzędzie miało analizować program i generować dla

niego diagram przepływu. Było to idealne rozwiązanie, ponieważ właśnie w ten sposób ludzie ko-

rzystają z takich diagramów. Należy je przygotować na początku, ale nikt tego nie robi — two-

rzymy je po napisaniu kodu. Narzędzie było pomysłowe, ponieważ miało specyficzną gramatykę

częściową, dlatego działało dla programów niepoprawnych składniowo i ukrywało elementy, któ-

rych nie potrafiło przetworzyć. Narzędzie musiało umieć przetwarzać instrukcje IF , ponieważ

Plik z chomika:

Inne pliki z tego folderu:

Inne foldery tego chomika: