[ Pobierz całość w formacie PDF ]
Spis treści
O autorze
7
Podziękowania
9
Wprowadzenie
11
Rozdział 1.
Jamie Zawinski
13
Rozdział 2.
Brad Fitzpatrick
45
Rozdział 3.
Douglas Crockford
75
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Ł
8
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ż
[ Pobierz całość w formacie PDF ]