C. Wayne Ratliff - 2 (Programmers at Work)

4. 7. 2008 | Tomáš Znamenáček | Rozhovory | 2946×

C. Wayne Ratliff v pokračování rozhovoru vysvětluje, proč při programování zas tak moc nezáleží na drobnostech, jak zařídit, aby byl program elegantní a vyvážený a proč je podle něj umělá inteligence mrtvá.

Programmers at Work je kniha 19 rozhovorů s významnými programátory, kteří svou prací a myšlenkami tvarovali podobu dnešních operačních systémů a mnoha dalších aplikací. Ačkoliv vyšla již v roce 1986, rozhovory jsou z velké míry nadčasové a stále velmi zajímavé. Susan Lammers se po více než 20 letech od prvního vydání knihy rozhodla zveřejnit rozhovory na Internetu a dala AbcLinuxu.cz souhlas k jejich překladu a vydání. Kvůli jejich délce bude většina rozhovorů rozdělena na dva díly. Každý rozhovor doplníme o krátký dodatek, ve kterém budou shrnuty další osudy jednotlivých programátorů.

---

Začátek rozhovoru: C. Wayne Ratliff (Programmers at Work), dokončení rozhovoru: C. Wayne Ratliff - 3 (Programmers at Work).

Ono to vypadá, že hodně autorů úspěšných programů musí opustit své původní kořeny a zakotvit u managementu…

Právě to se stalo i mně, ale moje zapojení do managementu bude klesat a časem úplně zmizí. Alespoň doufám, protože mi management spolkne hrozně moc času. Když přijdu do kanceláře, programování vůbec nepřipadá v úvahu. Mluvím s lidmi – po telefonu, osobně, na jednáních. Prakticky veškeré programování dělám doma.

Jak se vám daří vyvážit běžný domácí život, obchod a záchvaty pozdně nočního programování?

V podstatě dělám na programátorských projektech v době, kdy mi to moje žena Carolyn dovolí. Než jsem byl ženatý, přesněji řečeno, když jsem zrovna nebyl ženatý, jsem dělával tak do půlnoci. Rád pracuji v noci, protože mě nikdo neruší. Telefon nezvoní, pošťák nechodí, zahradník nechodí. Je klid, je čas se soustředit.

Došel jste k nějakému konkrétnímu stylu práce, který je pro vaše účely nejproduktivnější?

Pracuji buď sám, nebo s velice malou skupinou lidí. Jakmile má tým víc než šest členů, nastane chaos. Ted Glasser, který má řadu patentů, záznam v Kdo je kdo a patří mezi důležitější postavy počítačového oboru, jednou prohlásil, že největší tým, který ještě zvládne řídit, je tým, který může vzít na pizzu ve Volkswagenu. Od té doby změnil písničku – teď už je to obyčejné americké auto. Vřele s ním souhlasím.

A co se týká počtu projektů, většinou dělám jen jednu věc a všechno ostatní nechávám stranou. Když přepnu, přepnu kompletně. Někdy musím něco odsunout stranou a třeba to zůstane několik měsíců nedotčené a teprve pak se k tomu vrátím. To je můj jediný přístup k multiprocessingu. Jakmile začnu nějaký projekt, chci ho dotáhnout až do konce. Ne třeba úplně k dokonalosti, ale do nějakého přijatelného stavu. Pokud mám práci přerušit, musí k tomu být dobrý důvod. Něco většího, třeba vina; vina funguje spolehlivě. Když mám pocit, že porušuji daný slib, klidně dám stranou i něco oblíbeného.

Patřím mezi programátory, kteří si práci plánují předem, ale neplánuji si všechno do nejmenších podrobností. Mám představu o svém cíli, ale skutečná práce je přijít na další krok směrem k tomuto cíli. Snažím se udělat nejmenší možný krok, který mě posune blíž. A v rámci jednoho cíle nebo jednoho kroku se snažím najít co nejmenší jádro. Nesnažím se jako první udělat tu nejtěžší část, ani tu nejjednodušší. Nedá se to matematicky definovat, záleží na cítění a intuici.

Takže byste neřekl, že vás příliš zajímají podrobnosti?

Ne. Podrobnostmi se nezabývám kvůli tomu, že by mě zajímaly, ale z nutnosti. Rozumějte, nějaké pilování nanosekund je – alespoň podle mého – naprosto nepodstatné. Pokud program běží z poloviny tak rychle, jak by podle vás měl, máte jistotu, že do roka poběží na nových strojích bezvadně.

Co vás na programování uspokojuje?

Třeba ten sporťák, na kterém jsem dělal, mě uspokojoval, protože jsem mohl na něčem pracovat a vidět, jak mi to roste před očima. Největší problém byl v tom, že jsem potřeboval neexistující součástky. Když mi něco chybí v programu, klidně si to dodělám o půlnoci, ať už je to cokoliv. V nejhorším případě to bude chvíli trvat.

Což samozřejmě není jediné, co se mi na programování líbí. Mám rád technické hračky – líbí se mi, když můžu něco udělat a nechat si to vypsat na obrazovku. Když program napíšete dobře, je velice elegantní; je dobře postavený, zpívá. Mám z něj radost jako technik a mechanik, stejně jako z dobře postaveného auta, mostu nebo budovy. Všechno je na něm v rovnováze, vyladěné.

Mohl byste tu představu elegance a rovnováhy nějak rozvést?

Rovnováha má řadu podob. Kód by měl být čistý a stručný. Každý modul byste měli být schopni popsat jednou větou a pokud to jde, všechno by mělo být v abecedním pořádku. Čistě z vizuální stránky, z pohledu odsazování by kód nikde neměl přetékat přes okraj papíru. Neměl by mít žádné if na půl stránky a k němu jednořádkové else. Všechno by mělo být vyvážené. Rovnováha je klíčové slovo.

Když píšete kód, podaří se vám ho vyvážit hned na první pokus, nebo je potřeba hodně změn?

Hodně změn. Rád psaní kódu přirovnávám k sochaření. Začnete s hroudou hlíny, kterou oškrabujete, přidáváte další hlínu a zase oškrabujete. Každou chvíli se rozhodnete, že tahle noha nevypadá dobře, takže ji utrhnete a přilepíte jinou. Je v tom hodně pohybu.

Ideální modul by se měl vejít na jednu stránku. Když je mu jedna stránka malá, musím se rozhodnout – co se to vlastně snažím udělat? Kolik různých věcí tu míchám dohromady? Neměl bych je rozdělit na samostatné moduly? Elegance a rovnováha programu spočívají částečně v tom, že na každé úrovni hierarchie programu jsou moduly zhruba stejně velké, stejně těžké, odvádí podobnou práci, pracují podobně.

V čem přesně rovnováha programu pomáhá?

Díky ní se program dá udržovat. Když máte dobrou rovnováhu, je to jako kdybyste našli a implementovali nějaké základní fyzikální principy programu. Když se rovnováha pokazí, poznáte, že je něco špatně. Nejspíš tam máte nějakou podstatnou chybu, která rovnováhu kazí. Když mám pocit, že něco nesedí, když je nějaký modul moc velký, většinou se zamyslím nad tím, co dělám, a jednotlivé kusy přeskládám.

Měl na vaše programování vliv někdo konkrétní?

Nadchla mě kniha Software Reliability od Garyho Meyera a v drobných věcech mě ovlivnily i další knihy. Řazení věcí podle abecedy je trik, který jsem se naučil z knížek o programátorském stylu. Zjednodušuje práci, vede k čistějším programům, je to zkrátka krok směrem k eleganci programu. A přitom je to taková drobnost – nechápu, proč jsem na ni nepřišel sám.

Velký vliv na mě měl jeden z mých šéfů ve firmě Martin Marietta Phil Carney. Tehdy jsem psával ve Fortranu a když jsem potřeboval nové číslo řádky, vybral jsem si další z řady. Jenže jak programujete, nejdete popořádku, takže jsem si je v podstatě vybíral náhodně. Když to viděl Phil, rozčílil se a povídá: „Jen to dej hezky do pořádku, začni stovkou a zvyšuj pokaždé o deset.“ Říkal jsem si, že to dává smysl. Jsou to drobnosti, ale počítají se.

Omrzí vás někdy programování?

Když si uvědomím, že dělám něco neustále dokola, začne mě to nudit. Nad JPL jsem měl neurčitý pocit, že znova a znova píšu jednu a tutéž smyčku. Pokaždé to bylo maličko jinak, ale smyčka byla v podstatě stejná. Pak jsem si jednoho dne listoval knihou Structured Programming a narazil na vývojový diagram, na strukturovaný návrh. Došlo mi, že tohle je přesně to, co hledám. A taky že bylo.

Komentujete svůj kód hodně?

Vlastně ne. Ve firmě mě kritizují, že píšu málo komentářů. Řekl bych, že jsou dva typy komentářů – jedny vysvětlují zjevné věci a program by byl lepší bez nich, a ty druhé vysvětlují komplikovaný, složitý kód. No a já se složitému kódu snažím vyhýbat. Snažím se psát opravdu silný, čistý a jasný kód, i kdyby to mělo znamenat pět řádek navíc. Skoro bych řekl, že čím víc komentářů potřebujete, tím je váš program horší a měli byste s ním něco udělat. Dobrý program by neměl potřebovat moc komentářů. Kód by měl vysvětlovat sám sebe.

Moduly by měly být poměrně malé. Jakmile modul přeroste jednu stránku kódu, něco je špatně. Rozhodně je potřeba mít na začátku každého modulu jednořádkový komentář, který jednou větou vysvětlí účel modulu. Pokud nedokážete účel modulu popsat jednou větou, zase je něco špatně.

Jaké kvality podle vás dělají dobrého programátora?

Existuje celé spektrum programátorů. Na jednom konci je programátor, který pracuje na sto procent pro uživatele, a na druhém konci je programátor, který pracuje na nějakém matematickém problému a uživatel ho naprosto nezajímá. Zvláštní je, že nejvíc si s uživateli rozumí programátoři her. Matematický model hry je nejspíš obtěžuje, zatímco programátor na druhém konci spektra hledá co nejlepší algoritmus pro druhou odmocninu a nejspíš by ho pro změnu obtěžovalo, kdyby pro něj měl hledat nejlepší místo na obrazovce. Sebe bych rád viděl někde ve třech čtvrtinách spektra směrem k programátorům her, směrem k uživatelským rozhraním.

Napříč tímhle spektrem se porovnávat nedá, ale uvnitř ano. Theodore Sturgeon prohlásil, že 90 procent všeho je odpad. Nemyslím, že by to bylo vyloženě přehnané. Možná jen trochu pesimistické – ve skutečnosti to může být dejme tomu 60, 70 nebo 80 procent. Existují jasné důkazy, podle kterých odvedou tři procenta libovolné skupiny populace desetinu veškeré práce, a na druhou stranu 50 procent lidí odvede jen 30 procent celkové práce. Platí to pro fotbalové obránce, programátory, novináře, zkrátka pro všechny. Všude najdete pár lidí, kteří dělají šestkrát víc než ta polovina. Takže jsou dobří programátoři i špatní programátoři, stejně jako jsou dobří a špatní zaměstnanci kdekoliv jinde.

Je pro vás programování příjemné?

Jak kdy. Programování je trochu jako armáda. Když jsem byl v armádě, z celého srdce jsem ji nenáviděl. Děsil jsem se každé minuty a těšil jsem se, až odtamtud zmizím. Ale teď, když už jsem pryč, se mi ta zkušenost hodí. Při programování mívám radost z různých drobností a když jsem hotový, jsem zpětně docela spokojený, ale pořád bych toho chtěl za jednotku času zvládnout víc. Takže je v tom celou dobu trošičku trápení.

Na programování mám nejradši, když už mám něco skoro hotové. Vyzkouším to poprvé, dopadne to hrozně. A dopadá to hrozně i dál, dokud to třeba na stopadesátý pokus nedopadne dobře. To je pro mě vrchol, protože už vím, že jsem to dokázal. Zbývá ohladit hrany a odlovit zbytek chyb.

Je práce programátora natolik osobní, že by se někdo mohl podívat na váš kód a prohlásit: „tohle musel napsat C. Wayne Ratliffe“?

No… Gary Balleisen, který napsal SuperCalc a použil některé části zdrojového kódu ze začátků dBASE, prý autora kódu podle stylu pozná. Vím, že se v některých věcech – například ve způsobu ukončování bloků – liším prakticky od všech ostatních. A jsem přesvědčený o tom, že můj způsob je zdaleka nejlepší.

Například když jsem poprvé viděl C, nelíbilo se mi, že složené závorky trčí tak daleko doleva. Přišlo mi to nepřehledné. Ale pak jsem náhodou v nějaké dokumentaci od Digital Research narazil na techniku, která předepisovala závorky dávat na stejnou úroveň jako odsazený text. To je další z těch malých změn, které ve výsledku dělají velký rozdíl. Snažím se každého přesvědčovat, že takhle je to správně, ale mám jen střídmé úspěchy. Dokonce jsem upravil i jeden program pro formátování zdrojového kódu, aby to dělal automaticky. Můžu vzít cizí kód, projet ho tímhle programem a bude odsazený po mém.

Věnoval jste se někdy umělé inteligenci?

Umělé inteligenci jsem se hodně věnoval, když jsem se pustil do svého současného podnikání. Zabýval jsem se jí před rokem a něco, protože jsem si myslel, že má velkou budoucnost. Ale už jsem z toho vyrostl.

Umělá inteligence budoucnost má, ale příliš vzdálenou. Za prvé je tu problém s přirozeným jazykem. Řekněme, že si pořídíte systém pro zpracování přirozeného jazyka, odnesete si ho domů a dáte do počítače. V tu chvíli nastává několik týdnů nebo i měsíců dlouhé období, ve kterém ho musíte učit významy různých slov. Jedno slovo znamená v různých kontextech různé věci. I na první pohled jednoduchá slova, například „zisk“, mají řadu významů. Musí se jasně definovat v závislosti na předmětu vašeho podnikání, vyhláškách a podobně. Kvůli tomu dlouhému zacvičování je umělá inteligence mrtvá, tedy alespoň jako systém na klíč.

Ale druhá věc, která je velice zajímavá, jsou expertní systémy. Řekl bych, že během následujících dvou nebo tří let se expertní systémy přestanou spojovat s umělou inteligencí. Tak to v umělé inteligenci chodí: jakmile se nějaká její část proslaví, osamostatní se. Rozpoznávání vzorů se dřív považovalo za umělou inteligenci, dnes tvoří samostatný obor. V nejbližší době to čeká i expertní systémy. Myslím si, že expertní systémy budou hodně důležité pro náš průmysl, podobně jako vertikální aplikace.

Myslíte si, že dojde k nějaké větší změně v našem chápání programů – v tom, jak s nimi pracujeme? Třeba nějaký nový jazyk, natolik jednoduchý, že by v něm mohl programovat kdokoliv?

Dokončení.

© Susan Lammers 1986–2008, přeloženo s laskavým dovolením autorky.

       

Komentáře