Portál AbcLinuxu, 1. května 2025 07:01
Gary Kildall bývá někdy označován za člověka, ze kterého mohl být Bill Gates. Napsal první operační systém pro mikroprocesory (CP/M), protože na rozdíl od ostatních věřil, že budou mikroprocesory užitečné i pro běžné počítače. Kromě toho vyvinul koncept BIOSu a adaptoval optické disky pro ukládání počítačových dat. Jeho firma vydala první encyklopedii na CD-ROM.
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ů.
Jako zakladatel a ředitel firmy Digital Research vyvinul Gary A. Kildall v letech 1972–73 první operační systém pro mikropočítače. Pojmenoval ho CP/M (Control Program/Monitor) a udělal z něj první produkt své firmy. Kromě něj navrhl programovací jazyk DR Logo určený pro IBM PC a vyvinul PL/M, jeden z prvních vysokoúrovňových jazyků pro mikropočítače. Kildall je rodák ze Seattlu, narodil se 19. května 1942. Doktorát z informatiky získal v roce 1972 na Washingtonské univerzitě. Pak se dal k námořnictvu a vyučoval informatiku na Námořní univerzitě v kalifornském Monterey, kde jako učitel pokračoval i po svém propuštění z námořnictva. V roce 1984 založil novou firmu jménem Activenture (nedávno přejmenovanou na KnowledgeSet), aby prozkoumal možnosti publikování na optických discích. V roce 1985 Activenture oznámilo, že ve formátu CD-ROM vydá encyklopedii firmy Grolier. Kromě svého prezidentského postu ve firmě KnowledgeSet si Kildall ponechal i místo ředitele Digital Research.
Do sídla Digital Research jsme vyrazili jedno pondělní ráno po dálnici číslo jedna vedoucí podél kalifornského pobřeží. Místní scenérie je jedna z nejkrásnějších v celé zemi, a na pobřeží se to spíše než počítačovými firmami hemží rekreačními středisky. Digital Research a KnowledgeSet, firmy založené Gary Kildallem, jsou dvě z několika málo špičkových technologických firem v okolí. Nemohla jsem se nedivit, jak se někdo může zavřít do typicky ošuntělé a špatně osvětlené kanceláře a programovat, když má přímo pod okny takovou krásu. Ale Gary Kildall se na svou práci zřejmě soustředí bez problémů a okolí si užívá ve svém volné čase. Hraní se věnuje stejně důsledně jako své práci – mezi jeho „hračky“ patří nové Lamborghini Countach, akrobatický dvojplošník Pitts a Rolls Royce.
Gary se k nám v konferenční místnosti přidal kolem poledne. Je vysoký, má zrzavé vlasy a zastřiženou bradku; na sobě měl nové modré džíny, bílou kovbojskou košili a vysoké boty. Přiznal se, že právě dorazil z víkendu v Tahoe, kde se celou dobu přecpával, takže zatímco my ostatní jsme si dali sendviče, Gary sáhl po dietní Pepsi. A s tou začal svým typicky zdrženlivým a přemýšlivým způsobem vážně a zapáleně mluvit o programování. Vlastně jsme ho kvůli rozhovoru zrovna vyrušili od psaní kódu pro jeho poslední CD-ROM encyklopedii. Jedním z jeho důvodů pro založení KnowledgeSet bylo, aby se mohl dostat zpátky k základnímu programování – pryč od manažerských povinností jeho první firmy Digital Research, která tolik narostla. Během rozhovoru se často obracel k tabuli, aby mohl diagramem lépe vysvětlit puntičkářský a tvůrčí proces, kterým dává počítače do pohybu.
Učil jste na Námořní univerzitě. Kdybyste se tam měl vrátit a zase učit, dělal byste to jinak?
Nejspíš ne, protože můj dnešní způsob programování se od mé tehdejší výuky v ničem neliší. Asi bych se soustředil na mou nejoblíbenější přednášku, datové struktury. Ta se týká samotných základů programování, zjednodušování problémů. Jednou z částí programování je obecné řešení problémů. Je celkem jedno, jestli navrhujete počítačový program, nebo stavíte budovu – jak vyřešíte nějaký složitý problém? Vezmete si místo, které je podle vás moc složité, a zkusíte ho rozdělit na menší kusy. Tohle jsem se vždycky snažil učit.
Řešení problémů se učí těžko. Jak jste ho pojal vy?
Hned první přednášku o datových strukturách jsem řekl: „Uděláme si malý test. Dejte všechny učebnice pryč a vezměte si kus papíru. Chci, abyste napsali program na symbolické řešení diferenciálních rovnic. Program dostane polynom, spočítá jeho derivaci a vrátí symbolický, nikoliv číselný výsledek.“ Studenti začali psát, přemýšleli, lámali si hlavy. Nechal jsem je asi deset minut a pak jsem všem řekl, aby přestali. Nechal jsem je zamyslet nad tím, jak problém řešili, jaké nástroje používali. Začali rovnou psát program? Přemýšleli matematicky? Začali s jednoduchými příklady? Celou půlku semestru jsme strávili nad postupy a nástroji pro řešení problémů. Při závěrečné zkoušce jsem jim zadal ten samý problém, který řešili na první přednášce.
Jaké nejdůležitější principy si studenti odnesli z vašich přednášek?
Učil jsem je dvě věci, které jsou pro studenty nejdůležitější: řešení problémů a učení. Když se umíte učit, projdete všemi zkouškami a zvládnete i ostatní věci, které jsou pro přežití na škole potřeba. A když se naučíte řešit problémy, zvládnete život a budete se mít dobře.
Jak byste popsal svůj vlastní styl programování?
Řídím se velice striktními postupy, které u mě osobně fungují, ale nemusely by fungovat u každého. Začnu kreslením datových struktur a dlouho nad nimi přemýšlím. A ještě než začnu psát, představuji si, čím vším bude program muset projít.
Programy jsou jako mechanické stroje – spolupráce dvou kusů kódu se hodně podobá tomu, jak do sebe zapadají dvě ozubená kola. Psát kód je jako stavět převodovku. Dobrým příkladem je překladač PL/1, který jsem napsal před několika lety. Tehdy se říkalo, že na mikropočítači se dobrý překladač napsat nedá. Ale po několika letech práce už se PL/1 považoval za jeden z nejlepších optimalizujících překladačů.
Jakmile jsou datové struktury hotové, začnu psát malé kusy kódu, které postupně zlepšuji a sleduji. Díky průběžným kontrolám mám jistotu, že mají provedené změny jen místní dosah; a když dojde k nějakému problému, okamžitě na něj přijdu. Takový iterativní vývoj vyžaduje rychlost, takže alespoň pro mě je velice důležité, aby jedna otáčka s úpravou kódu, spuštěním a odladěním netrvala dlouho. Na sálových nebo dávkových počítačích tenhle systém nefunguje, protože nemůžete udělat pár malých změn a hned si je vyzkoušet.
Dáváte přednost interpretům?
Ne, současné interprety se mi moc nelíbí. Chtěl bych nějaký interpret systémového jazyka, například C, který by se vyrovnal současným překladačům. Těžko se ale odhaduje, jak by taková věc fungovala, protože většina systémových programů je stavěná s ohledem na výkon nebo rychlost. Kdybych měl vysoce efektivní interpret – takový, jaký jsem používal při vývoji PL/M, nebo dnes třeba C, asi by stál za zkoušku.
Jak jste se dostal k programování?
Původně jsem chtěl učit matematiku na střední škole a začal jsem brát lekce matematiky na Washingtonské univerzitě. Ale kamarád měl takovou kartičku s příkazy Fortranu, kterou mi ukázal a řekl, že tohle bude jednou opravdu velká věc. Tolik mě zaujala, že jsem to musel zkusit. Začal jsem tedy chodit na přednášku o programování v assembleru a pak ve Fortranu a byl jsem ztracený. Zjistil jsem, že se mi programování líbí ze stejných důvodů, ze kterých rád stavím modely, auta a podobně. Psaní programů pro mě byl podobný zážitek.
Pamatujete si první program, který jste kdy napsal?
Ano. Počítal vteřiny mezi libovolnými dvěma časy a daty. Ještě pořád ho mám. Narazím na něj pokaždé, když si uklízím stůl; jako na staré oblečení ve skříni.
A co váš první profesionální program?
Ten jsem napsal pro navigační školu, kterou vlastnil můj otec. Pro jedno nakladatelství ze Seattlu jsme ručně chystávali tabulky přílivu. Napsal jsem ve Fortranu program, který příliv spočítal za nás. Byl to první program, na kterém jsem vydělal – asi 500 dolarů nebo tak nějak.
Jak jste se dostal k práci na operačním systému CP/M?
Operační systém byl ve skutečnosti jen malou částí obrovského projektu. Pracoval jsem s XPL, specializovaným jazykem pro sálové počítače, který navrhl Bill McKeeman na Stanfordu. Navrhl jsem podobný jazyk PL/M, který byl určený pro mikropočítače. Snažil jsem se PL/M dostat na mikroprocesor 8080 a musel jsem napsat rozhraní pro komunikaci s diskem. Nakonec se naštěstí ukázalo, že i tenhle operační systém jménem CP/M (Control Program for Micros) bude mít úspěch.
Takže jste během vývoje CP/M neměl tušení, že bude tak úspěšný?
Ne. Vůbec jsem nevěděl, že se z CP/M stane takový hit. Ale bylo mi jasné, že diskety budou velká věc. Jeden a půl roku jsem dělal s papírovými páskami. Disketová mechanika stála 500 dolarů, čtečka papírových pásek s pořádnou děrovačkou 2000 dolarů. Stačilo se podívat na jejich ceny a bylo mi jasné, že diskety budou mít ohromný komerční úspěch.
Někteří programátoři chrlí kód a když narazí na hodně velký problém, začnou od začátku. Stává se vám to někdy?
Ne. Moje problémy nejsou nikdy tak vážné, abych musel začínat znovu. Kdybych si nebyl jistý svými datovými strukturami, nikdy bych se nepouštěl do psaní. Když u mě dojde na trhání kódu, většinou je to kvůli špatným datovým strukturám, ne kvůli špatným algoritmům.
Komentujete svůj kód?
Jen zřídka komentuji něco jiného než začátek procedury a i tehdy popisuji jen datové struktury. Samotný kód už nekomentuji, protože mám pocit, že dobře napsaný kód mluví sám za sebe. Jakmile mám vymyšlené algoritmy, začnu kód psát rovnou do počítače. Ani si ho předem nepíšu na kus papíru, připadne mi to zbytečné. Samotný proces psaní kódu je pro mě odjakživa trochu adrenalin, protože nevím, jestli to píšu správně, ani co vlastně napíšu jako další. Vždycky to ze mě nějak vypadne. Někdy mi dojde, že to nemám úplně přesně správně, ale okamžitě si intuitivně uvědomím, že to nevadí – že je tu nějaká další část programu, se kterou se příslušný kód složí a nakonec to vyjde správně, i když v daném okamžiku přesně nevím jak.
Kouzelné na tom je, že v určitém okamžiku to najednou celé zacvakne. Je to něco jako když se díváte na booleovský výraz, který zjednodušujete a zjednodušujete, až to najednou máte. Když dosáhnu toho bodu, ve kterém se kód dá dohromady, už jsem si jistý, že program bude fungovat. A navíc jsem si jistý, že jsem ho napsal zhruba nejlépe, jak to šlo. Sám tomu procesu moc nerozumím, ale můžu se na něj spolehnout, i když třeba dělám podstatné zásahy do datových struktur nebo algoritmů.
Je pro vás psaní kódu těžké?
Ne. Když programuji bez tlaku, bez termínů, výborně se při tom uvolním. Když mám někdy naplánovaný dlouhý let, vezmu si malý přenosný počítač s sebou a programuji jen tak, pro radost. A vlastně i když mám termín, baví mě sedět u terminálu a nechat ruce běžet. Zní to zvláštně, ale jde mi to samo. Jakmile se do toho dostanu, už o tom nemusím přemýšlet.
Stalo se vám někdy, že se vám nedařilo kód napsat podle vaší představy?
Bylo několik málo případů, kdy se někdo podíval na můj kód a řekl, že by to „zvládli mnohem lépe“. Ale bývají i chvíle, kdy to mně samému nesedí. Dobrým příkladem je editor v interpretu DR Loga. Měl jsem pár kusů kódu, o kterých jsem věděl, že nejsou ideální. Fungovaly, ale nezapadaly do sebe, zkrátka za moc nestály. Technici, kteří ten kód po mě dostali, se právě na tuhle část zaměřili, ale už nebyl čas – museli jsme produkt poslat na trh. To je přesně ta věc, u které doufáte, že se nikdy nestane. Někdy se ale stane, takže se musíte vrátit a opravit ji; dozvědět se něco o svém vlastním stylu.
Myslíte si, že se programování dá cvičit, třeba jako hra na klavír?
V jistém smyslu ano. Podle Seymoura Paperta si děti cvičí vynalézavost hraním s ozubenými kolečky a dalšími mechanickými součástkami. Věci, které se takovou hrou naučíte, se dají přenést do jiných oborů. Přinejmenším u mě to takhle probíhalo. Můj otec byl vynikající řemeslník, celé hodiny jsem ho sledoval a pak jsem vyrazil ven a zkoušel ho napodobit svým vlastním kladivem a hřebíky.
Datové struktury, které jsou základem každého programu, jsou ve své podstatě mechanické – stejně jako věci, se kterými jsem si jako malý hrával. Takže v tomhle smyslu jsem jako malý cvičil programování. Velký rozdíl je v tom, že udělat něco ze dřeva nebo kovu zabere hodiny a hodiny práce. A když se vám to nepovede, musíte začít znovu a předělat to. Programy se dají změnit okamžitě.
Jak jinak by si ještě programátor mohl budovat repertoár?
Musíte studovat práci jiných lidí. Jejich přístup k řešení problémů a jejich nástroje vám dají nový pohled na vaši vlastní práci. K napsání programu vám stačí pochopit několik málo postupů. Například při psaní překladačů napíšete jako první scanner, což je malý nástroj, který pak využijete ještě mockrát. Jakmile se s těmito nástroji naučíte pracovat, už je to jen otázka skládání jednotlivých kousků dohromady. Vezmete kousek odsud, kousek odjinud a všechny je poskládáte dohromady. Čtením programů od jiných lidí se můžete naučit další způsoby, jak vytvořit nějaký logický celek. Proto jako učitel trávím se studenty hodně času analýzou čistých algoritmů, které jsem někde odkoukal.
Mluvil jste o tom, jak učíte. Ovlivnil někdo nebo něco váš styl programování?
Jsem velký pragmatik. Rád píšu programy, které jsou rychlé a malé a používají jasné, výstižné algoritmy. Tenhle styl mám z Burroughse 5500, což byl ve své době velice pokročilý stroj, který vycházel z Algolu a jeho filosofie blokově strukturovaných programů. Překladač Algolu je asi jeden z nejhezčích kusů softwaru z té doby. Strávil jsem hodiny jeho opravováním a změnami, takže ovlivnil mé programátorské myšlení a měl ohromný vliv na můj styl. Naštěstí se Algol stal základem pro návrh populárních jazyků, jako například Pascalu nebo C, takže mám s tímto stylem úspěch.
Člověk občas zaslechne historky o šílených hodinách, které programátoři stráví u počítače. Co vy? Jaký máte pracovní režim?
Mé tempo se liší podle toho, v jaké fázi se vývoj programu nachází. Někdy mi kód začne kynout pod rukama a mám v hlavě všechno najednou – všechna jména proměnných a jak navzájem souvisejí a kde začínají ukazatele a kde končí a kde se přistupuje na disk a tak dále. Mám všechno v hlavě a nemá smysl to dávat na papír, protože se to neustále mění. Strávil bych víc času psaním dokumentace než programováním a nikdy bych projekt nedokončil v rozumném čase.
Když jsou datové struktury takhle čerstvé, musím se hodně soustředit, abych si v hlavě udržel pořádek. V téhle části projektu tedy obyčejně začnu ve tři ráno a pracuji třeba až do šesti večer. Pak si dám večeři, jdu brzy do postele, vstanu zase brzy po ránu a buším do mašiny, dokud se věci neuklidní.
V období klidu, když zrovna pracuji volnějším tempem, přemýšlím nad řešením dalších částí projektu. Když se snažím vyřešit problém složený z několika kroků, beru je popořádku, jeden po druhém – krok A, krok B, krok C. Zkoušel jsem to, ale nemůžu pracovat na C, dokud není hotové B.
V období klidu si také beru krátké dovolené, protože si kromě práce rád užívám i život. Vyrazím ven a vyletím si letadlem, jen abych se dostal pryč. Pro práci je to dobré, pokaždé se vrátím s novými nápady.
Má vaše létání ještě nějaký další vliv na vaše programování?
Srdečně doufám, že mi plánování programů jde lépe než létání. Slyšel jsem, že mezi programátory je pilotů celkem hodně. Charles Simonyi například létá s vrtulníkem. A Fred Gibbons a Vern Rayburn se o létání dost zajímají.
Programátoři rádi pilotují, protože je to mechanický proces, jako programování. A kdo má rád počítače, má většinou rád různé technické hračky, kterých je každé letadlo plné. V letadle jsou všechny číselníky a budíky a páčky, kterých se vám kdy zachtělo. Jen je to trochu nebezpečná hra, protože je to opravdové letadlo, nejen nějaká videohra. Počítače jsou vysoce abstraktní, letadla opravdová.
Omrzí se vám někdy programování?
Pokračování za dva dny...
© Susan Lammers 1986–2008, přeloženo s laskavým dovolením autorky.
Mluvil jste o tom, jak učíte. Ovlivnil někdo nebo něco váš styl programování?není označeno jako nadpis
Ne. Když programuji bez tlaku, bez termínů, výborně se při tom uvolním.Ti studenti, kterým zadal ten příklad, taky museli být skvěle uvolnění.
koef = koef .* stup; stup = max(stup - 1, 0);ale uznávám, že deset minut je na toto pro mě fakt málo. Samozřejmě má tahle reprezentace svoje podstatná ale. Ale o to v tomhle konkrétním příkladě nějde.
v letech 1972 – 73
Kolem pomlčky by neměly být mezery, neb jde o interval.
Da sa tento zbytocny thread vymazat?Da, ale jelikoz neni nijak skodlivy, nechme ho byt.
ISSN 1214-1267, (c) 1999-2007 Stickfish s.r.o.