Portál AbcLinuxu, 2. května 2025 05:42
Bill Gates je osobnost, kterou není třeba představovat. V tomto rozhovoru mluví například o začátcích Microsoftu, psaní BASICu pro Altair a další počítače a svém stylu programování.
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žto výkonný ředitel Microsoftu bývá William H. (Bill) Gates považován za jednoho z hybatelů v oboru dnešních osobních počítačů a kancelářské automatizace. Jeho kariéra v počítačovém softwaru začala brzy – s Paulem Allenem, spoluzakladatelem Microsoftu, pracovali jako programátoři a konzultanti už na střední škole ve washingtonském Seattlu. V roce 1974 studoval Gates druhým rokem na Harvardské univerzitě a společně s Allenem vyvinul implementaci jazyka Basic pro první komerční mikropočítač Altair firmy MITS. Po úspěšném dokončení projektu oba založili Microsoft, aby vyvíjeli a prodávali software pro vznikající trh mikropočítačů.
Microsoft určuje v softwarovém průmyslu standard pro jazyky, operační systémy a aplikační software. Gates je autorem vize nových firemních produktů a technologií Microsoftu. Slouží také jako praktický průvodce technologických skupin, které pracují na vývoji nových produktů, a většinu svého času tráví pilováním softwaru, který Microsoft prodává.
Gates je rodák z washingtonského Seattlu a dodnes zde žije. Narodil se v roce 1955.
Jako výkonný ředitel Microsoftu máte určitě hodně zodpovědností. Programujete ještě?
Ne, neprogramuji. Pomáhám s návrhem algoritmů a základním přístupem a někdy se podívám na kód. Ale od té doby, co jsem pracoval na Basicu pro IBM PC a Model 100, jsem neměl příležitost něco napsat doopravdy sám.
Jakou roli hrajete při vývoji programů v Microsoftu?
Dělám dvě klíčové věci. První z nich je výběr funkcí, které se do programu budou dávat. K tomu je potřeba celkem dobře rozumět tomu, co se dá udělat snadno, a co už ne. A také musíte mít představu o celkové „rodinné“ strategii produktů a hardwaru, na kterém poběží.
Také pracuji na hledání ideální implementace nových funkcí, aby byly malé a rychlé. Například jsem napsal zprávu o návrhu a implementaci jedné funkce Excelu, která se stará o přepočítání vzorců při každé změně obrazovky.
První čtyři roky existence firmy nebyl v Microsoftu jediný program, na jehož návrhu a psaní bych se nepodílel. Ve všech našich prvních produktech, ať už šlo o Basic, Fortran, Basic 6800 nebo Basic 6502, nebyla jediná řádka kódu, kterou bych neviděl. Ale teď máme kolem 160 programátorů, takže už většinou pouze kontroluji hotové algoritmy a produkty.
Co považujete za svůj největší dosavadní programátorský úspěch?
Určitě Basic pro 8080. Protože měl takový dopad, protože tak přesně vystihl svou dobu a protože se nám ho podařilo udělat tak malý. Byl to první program, který jsme napsali, když jsme se rozhodli založit Microsoft.
Ten původní kód jsme všichni tři znali nazpaměť. Jedno léto jsme v Albuquerque dostali šanci ho úplně přepsat; říkal jsem si, že bychom mohli ušetřit pár bajtů a trošku ho přitáhnout. Velice, velice opatrně jsme ho odladili, až jsme nakonec dostali interpret Basicu ve čtyřech kilobajtech.
Původní osmikilobajtová verze Altair Basicu na děrné pásce.
Když znáte nějaký program takhle dobře, máte pocit, že se na jeho kód nemůže nikdo podívat a říct: „Tohle by šlo udělat líp.“ To je moc pěkný pocit. A navíc se program používal na tolika počítačích, zkrátka to byla vzrušující práce.
Dobrý pocit mám také ze softwaru pro Model 100 – zvlášť z toho, jak se nám do něj podařilo dostat i malý a užitečný editor. Pracoval jsem na něm s japonským programátorem Jey Suzukim a měli jsme velice málo času. Když děláte software, který se bude pálit do ROM, nesmíte si dovolit dělat chyby.
Co je pro vás na programování nejobtížnější?
Nejtěžší je najít algoritmy a pak je co možná nejvíc zjednodušit. Ořezat něco do základní podoby není jednoduché. Musíte si v hlavě simulovat, jak bude program fungovat, a musíte mít dokonalou představu o tom, jak jednotlivé části programu navzájem spolupracují. Nejlepší software je ten, u kterého má o celém fungování programu dokonalou představu jeden člověk. Abyste něco takového dostali, musíte program doopravdy milovat a soustředit se na maximální jednoduchost, do neuvěřitelné míry.
Velikost paměti a výkon počítačů rostou obrovským tempem. Jsou dnešní programy složitější, nebo hůř napsané? Jaký má výkon počítačů vliv na psaní programů?
Doby, kdy byl každý program dokonale vybroušený, jsou pryč. Ale uvnitř každého programu, který se dostane na špičku, najdete klíčový interní kód napsaný několika málo lidmi, kteří doopravdy věděli, co dělají.
Dnes už není tak důležité nacpat se do čtyř kilobajtů paměti. Přibývá případů, kdy si lidé mohou dovolit použít místo assembleru C. Hodně programů je ale bohužel tak složitých, že už je nikdo doopravdy nezná celé, takže sdíleného kódu ubývá. Také je méně příležitostí se k něčemu vrátit a doopravdy to přepsat, protože je potřeba neustále přidávat nové funkce.
Nejhorší programy jsou ty, ve kterých původní programátor nepoložil dostatečně pevné základy a na dalším vývoji už se nepodílí. Práce s takovými programy se dostane do fáze, které říkám „experimentální programování“. Programátoři těmto programům rozumí tak málo, že nemají představu, jak jejich změny ovlivní například rychlost. Začnou třeba psát kód, který už existuje, nebo něco změní a neuvědomí si, že se kvůli závislostem rozbije něco jiného. Přidají svůj nový kód a řeknou si: „Aha, takhle to nepůjde.“ To je velice, velice neefektivní způsob práce s programem – jenže řada projektů skončí právě takhle.
Jak ve firmě jako Microsoft, ve které máte 160 programátorů, připravujete prostředí vhodné pro vývoj úspěšných programů?
Jedna možnost je rozdělit programátory do malých projektových týmů, obvykle po čtyřech nebo pěti lidech, z nichž jeden musí mít schopnost skutečně obsáhnout celý program. A když si hlavní programátor něčím není jistý, měl by mít možnost si o tom promluvit s ještě zkušenějšími programátory.
Součástí naší strategie je přimět programátory k tomu, aby si před začátkem programování všechno pořádně promysleli. Zásadní je dokumentace návrhu, protože když uvidíte problémy zapsané jako algoritmy, můžete toho hodně zjednodušit. V takovém zápisu jsou problémy v jistém smyslu zapsané v nejmenší podobě a je vidět, kde se překrývají.
Další důležitá věc je čtení kódu, při kterém si kód důkladně projdete a zjistíte, jestli vám zkušenější kolegové někde neporadí lepší řešení. A taky si musíte prohlédnout několik podobných projektů, které dopadly na výbornou. Programátor se může podívat, jak postupoval někdo jiný před ním, a z tohoto projektu se inspirovat při zlepšování toho vlastního.
Kde se berou nápady na nové programy?
No, rozhodně na to není žádný formální proces. V Microsoftu většinou děláme brainstorming, v noci nebo o víkendu. Každý přijde s nějakým rámcovým nápadem, třeba že chceme udělat nejlepší textový procesor na světě. A chceme, aby zvládl všechny požadavky nějakého oddělení pro technické publikace. Sedíme, povídáme si. Jak zařídíme, aby běžel vážně rychle? Dáme do něj kreslení? Zvládneme kerning, aniž by se program neúnosně zpomalil? Probereme řadu problémů a objeví se několik šikovných nápadů.
V podstatě je to tedy týmová práce?
To, co mají programy dělat, navrhuje celkem početná skupina lidí. Návrhy pak prochází sítem a nakonec já rozhodnu, který z nich má smysl. Dávám si pozor na to, abychom měli u každého produktu několik zástupců uživatelů, kteří osobně dohlédnou na jeho úspěch. Realizujeme jen zlomek projektů, protože pokud máme produkt dostat na trh a přijít s novým světovým standardem, vyžaduje to obrovskou dávku soustředění.
Hodně se mluví o tom, jak mají velké firmy potíže přilákat talentované tvůrce kvalitního softwaru, protože takoví nekonformní lidé bývají nezávislí a chtějí pracovat samostatně. Jak přitahujete kvalitní lidi do Microsoftu a jak si je držíte?
Dobrý programátor je nezbytným předpokladem pro vznik dobrého softwaru. U nás ale nevěříme na nějaký premiantský režim, ve kterém by dobří programátoři nemuseli komentovat kód, nemuseli komunikovat s ostatními nebo naopak mohli vnucovat své představy všem ostatním.
Chceme lidi, kteří doopravdy respektují jeden druhého. Řekl bych, že většina dobrých programátorů se ráda pohybuje kolem dalších dobrých programátorů. Když přijdou na nějaký fantastický algoritmus, jsou rádi, když ho jejich kolegové umí ocenit. Protože přijít na něco takového a jen si to nosit v hlavě je smutná věc. Když se vám podaří zjednodušit nějaký původně složitý postup, je to skvělý pocit. Ale chcete si o tom promluvit i s ostatními. Jakmile se vám podaří získat několik výborných lidí, přijdou další.
Bývalo pravidlem, že programátorův manažer musel být lepší programátor. Nesmělo dojít k tomu, čemu jsme říkali „technická inverze“ – programátor nesměl pracovat pro někoho, kdo neuměl programovat. Této filosofie se držíme dodnes. Na jisté úrovni máme business manažery, ale programátorské projekty smí doopravdy řídit zase jen programátoři.
Myslíte si, že existují nějaká pevná pravidla, podle kterých jde napsat dobrý program?
Někdo začne rovnou psát a někdo si všechno důkladně promyslí předem, ale řekl bych, že i ta první kategorie používá úvodní kód jen jako poznámkový blok. Nejdůležitější je to, co se jim děje v hlavě.
Musíte mít někoho, kdo je extra chytrý. Dobrý programátor přemýšlí o programu neustále, i když řídí nebo jí. Takový přístup vyžaduje neuvěřitelnou duševní energii.
Jak byste popsal svůj styl programování?
Ještě než si sednu a začnu psát kód, rád si celý program rozmyslím na úrovni návrhu. A jakmile mám kód napsaný, často se vrátím na začátek a úplně ho přepíšu.
Na psaní programů je nejdůležitější návrh datových struktur. Druhá nejdůležitější věc je rozdělení kódu na jednotlivé části. Protože dokud se k tomu nedostanete a nenapíšete si to, nemáte úplně přesnou představu, jaké budete potřebovat společné podprogramy.
O všech opravdu dobrých programech, které jsem kdy napsal, jsem přemýšlel už strašně dlouho předem. Interpret Basicu jsem napsal už na střední škole. Měl jsem v něm obrovské chyby a pak jsem se dostal k několika dalším interpretům Basicu. Takže když jsem se v roce 1975 pouštěl do Microsoft Basicu, nešlo o to, jestli takový program vůbec napíšu, ale jestli ho dokážu dostat do 4 K a jestli bude extra rychlý. Celou dobu jsem se pohyboval na hraně, pořád jsem si říkal: „Bude dost rychlý? Nepřijde někdo, kdo by to dokázal rychleji?“
Pořád mám před sebou pana Nortona, kterého jsem potkal v TRW. Kdykoliv jsem něco nenapsal zrovna extra dobře, upozornil mě na to. Takže když začnu být líný nebo něco odfláknu, představím si, že přijde on, podívá se na program a řekne: „Hele, tady by se to dalo udělat líp.“ Do každého programu se postupem času dostanou drobné nedostatky. Pokud chcete mít z programu opravdu dobrý pocit, musíte se soustředit na to, aby vám nic podobného neuteklo. Proto je občas trochu nepříjemné nechat na projektu dělat někoho dalšího. Nikdo jiný to nenapíše přesně tak, jak byste chtěli. Pamatuji si, že když jsme dělali na Basicu, vracel jsem se ke kódu ostatních lidí a přepisoval ho, aniž bych ho nějak zásadně vylepšil. Lidem to vadí, ale někdy prostě máte pocit, že to musíte udělat.
Když jste pracoval v týmu, pokaždé jste ho vedl?
Ano, u všech programů, na kterých jsem se přímo podílel, jsem byl hlavní designér. U původního Basicu jsem návrh načmáral na kusy papíru. Paul Allen, můj spoluautor, navrhl a napsal všechny vývojářské nástroje.
Než se pustím do programování, většinu instrukcí už mám v hlavě. Nejsou uspořádané úplně dokonale a rozhodně dělám nějaké změny, ale všechny dobré nápady mě napadnou ještě před psaním. Pokud najdu nějakou chybu, cítím se vážně hloupě – protože když je tam jedna chyba, znamená to, že ten váš simulátor v hlavě nepracuje dokonale. A když nepracuje dokonale, v programu klidně může být dalších tisíc chyb. Opravdu nesnáším, když někdo programuje, aniž by přemýšlel.
Snad nejvíc zábavy jsem si v programování užil, když jsme dělali Basic. Měl jsem za sebou Basic pro 8080 a pak jsem měl asi dva týdny vyhrazené na Basic pro 6809, který jsem dělal společně s Markem Chamberlainem. Na začátku těch dvou týdnů jsem si přečetl instrukční sadu a napsal tři nebo čtyři programy. A pak jsem se podíval na několik programů od jiných lidí, abych viděl, jak instrukční sadu využívají oni. Strašně mě bavilo vzít problém, kterému už jsem rozuměl, namapovat ho na tuhle novou instrukční sadu a sledovat, jak dobře se nám ho podaří dát dohromady.
Dnešní programy výrazně tloustnou a během rozšiřování se často zpomalují, protože do nich programátoři přidávají speciální podmínky. Když chtějí přidat nějakou novou funkci, prostě do programu vlepí novou podmínku – aniž by je zajímalo, že tím program třeba zpomalí. Aby se tohle nestalo, musíte mít na projektu programátora, který zná program nazpaměť. Například když jsem společně se zbytkem původního týmu opustil náš Basic, nastalo asi tříleté období, ve kterém jsme neudělali nic nového. Teprve v posledním roce a půl zase máme lidi, kteří mají náš Basic dokonale v ruce a můžou říct: „No jasně, podprogramy jsou implementované za chvilku a čísla řádek odstraníme bez problémů.“ Tyhle funkce jsme chtěli vždycky, ale dokud nemáte někoho, kdo umí sáhnout doprostřed analyzátoru částí nebo příkazů – místo toho, aby kód jen lepil na ten původní, moc se vám do nich nechce.
Je fakt, že už dnes programy necháváme maličko tučnější, než bývaly dřív. Ale pokud jde o rychlost, je prostě pohodlnost neudělat něco tak rychlé, jak jen to může být. Protože uživatelé, i když vám to třeba nebudou umět přesně říct, si doopravdy rychlých programů všimnou. Opravdu úspěšné programy běhají krásně rychle.
Jak řešíte kompromisy mezi funkčností a rychlostí?
© Susan Lammers 1986–2008, přeloženo s laskavým dovolením autorky.
Na začátku těch dvou týdnů jsem si přečetl instrukční sadu a napsal tři nebo čtyři programy. A pak jsem se podíval na několik programů od jiných lidí, abych viděl, jak instrukční sadu využívají oni.Tehdy byl assembler, teď máme OSS. BG přece musí mít k OSS pozitivní vztah
Nektere relikty (sam v jednom dosud pracuji) to majiTakže programujete v Haskellu?
Pokud vam to neprijde jako nic zvlastniho, zkuste vzit kus kodu v Pythonu a presunout ho na jine misto. Pokud se nahodou netrefite do stejne hloubky vnoreni, ceka vas pakarna...pokud nepoužíváte dostatečně inteligentní editor, jako třeba Emacs, který je schopen s whitespaces v Pythonu zacházet poměrně inteligentně, cyklovat příkazy mezi úrovněmi vnoření (s indikací v minibufferu), indentovat/deindentovat celé bloky a podobně.
používám nejlepší editor na světě co zvládne leccosoperacni system Emacs?
deb http://ftp.cz.debian.org/debian jessie main contrib non-free
Tam atributy jazyka neresi, proste se programuje v tom, v cem je zrovna potreba, nebo jaci lide jsou zrovna volni. Berou to pragmaticky a nesnazi se bojovat s vetrnymi mlyny.To je vskutku inteligentní přístup, typu "kopáče ulic seženeme všude". Připomnělo mi to tenhle blogpost:
Negative indicators:A přišel mi ten text celkem rozumný. Ostatně Paul Graham k tomu taky řekl svoje (bod číslo 7). No, jestli někdo mermomocí cítí potřebu pracovat v megafirmě, ve které jaksi není součástí rozhodovacího procesu, budiž mu to dopřáno.
- Happy to work with whatever technology you’ve picked, “all technologies are good”
A ti opravdu velci (Microsoft, napriklad) si proste jazyky prizpusobi tak, jak jim vyhovuji.S nestupidními jazyky tohle dokáže jednotlivec za víkend, proč je nutné jmenovat zrovna Microsoft?
10 LET L = L + 1
…ježiš, to byly časy.
20 GO TO 10
GOTO
10 SIN 20 GOTO HELL(Tedy doufám že všichni znají...)
No já nevím, ale odstranění povinných labelů na každém řádkuTo už ale potom nezažil člověk tu srandu kdy u programu o 1000 řádcích je potřeba něco přidat mezi řádek 251 a 252.(
GOSUB
prosím nechme hnít)
když se tam neskáčeVšechno se dá, když se chce. Jen se místo labelů používaly návěstí(i když je dost možné, že si to pletu s BAŤáky)
a zrušení zbytečného příkazu LET mi jako fujtajcl nepřijdeProč zbytečného?
To už ale potom nezažil člověk tu srandu kdy u programu o 1000 řádcích je potřeba něco přidat mezi řádek 251 a 252.No nevím, v tu chvíli by mi to asi tak srandovní nepřišlo...
Všechno se dá, když se chce. Jen se místo labelů používaly návěstíCože? Já mluvím o tom, že ve starších verzích BASICu bylo povinné číslovat řádky a QBasic tuhle povinnost odstranil.
Proč zbytečného?Vzhledem k tomu, že přiřazení je jedna z docela častých operací, tak uvozovat ji nějakým příkazem mi přijde hodně zbytečné. Zatím jsem se nesetkal s jiným jazykem, který by něco takového vyžadoval.
Cože? Já mluvím o tom, že ve starších verzích BASICu bylo povinné číslovat řádky a QBasic tuhle povinnost odstranil.Já tam vidím napsáno v závorce když se tam neskáče, z čehož vyvozuji, že se v QBasicu nedá skákat a proto oponuji, protože dá a dokonce ještě pohodlněji. Toť vše.
Vzhledem k tomu, že přiřazení je jedna z docela častých operací, tak uvozovat ji nějakým příkazem mi přijde hodně zbytečné. Zatím jsem se nesetkal s jiným jazykem, který by něco takového vyžadoval.No tak na Spekáčích se s těmi proměnnými nedalo moc přehánět, když měl jen dvě 32kB banky, takže tam vůbec nějaké
LET
nevadilo. Dokonce bych si troufl tvrdit, že přiřazení hodnoty do proměnné nebylo tou nejčastější operací.
Já tam vidím napsáno v závorce když se tam neskáče, z čehož vyvozuji, že se v QBasicu nedá skákatNo jo, když vytrháváš z kontextu, tak se nediv, že něco pochopíš blbě. Samozřejmě to bylo myšleno tak, že není povinné číslovat řádek, na který se neskáče - v závorce to bylo proto, že jsem to považoval za jasné a pochopitelné.
No tak na Spekáčích se s těmi proměnnými nedalo moc přehánět, když měl jen dvě 32kB banky, takže tam vůbec nějaké LET nevadilo.Krom toho čtyři zbytečně zabrané byty navíc za jakékoliv přiřazení.
No jo, když vytrháváš z kontextu, tak se nediv, že něco pochopíš blbě. Samozřejmě to bylo myšleno tak, že není povinné číslovat řádek, na který se neskáče - v závorce to bylo proto, že jsem to považoval za jasné a pochopitelné.Jo tak to se omlouvám, jen mi to prostě přišlo jako by jsi se snažil podsouvat, že ten QBasic byl tak vymakaný, že nebylo potřeba skákat.
Krom toho čtyři zbytečně zabrané byty navíc za jakékoliv přiřazení.aaa, už je mi to jasné…tady ještě někdo neměl tu čest se Spekáčem.
LET
u moc nezáleželo, teda alespoň né víc než na jiných příkazech. O takových věcech jako psaní ala textový editor přímo v ROMce se mi v těch dobách mohlo jenom zdát.
Jo tak to se omlouvám, jen mi to prostě přišlo jako by jsi se snažil podsouvat, že ten QBasic byl tak vymakaný, že nebylo potřeba skákat.Ne, tak to opravdu ne. Osobně žádný takový jazyk neznám (i když předpokládám, že existuje)
Na klávesnici byla pro každý příkaz jedna klávesa, která měla přiřazený svůj příkaz a v paměti měl každý příkaz jeden bajt.Tak to aspoň něco.
Na klávesnici byla pro každý příkaz jedna klávesaAspoň na Didaktiku Gama byly na jedné klávese ty příkazy myslím hned čtyři
Aspoň na Didaktiku Gama byly na jedné klávese ty příkazy myslím hned čtyřiMyslel jsem to spíš tak, že se to nepsalo po jednotlivých písmenkách jako v QBasicu, ale že se prostě fláklo do jedné klávesy a všechno se to za něj napsalo samo a všechno bylo uloženo v paměti(a na médiích) jako 1B.
A docela se v tom dalo dělat, když si člověk zvykl.No, nevim. Já už měl vedle pixle nachystaný vždycky nůž na zaseknuté klávesnice(nebo jak se ty plastové kostičky na Didaktiku jmenovaly).
Pak jsem si čistě ze zájmu koupil dvoudílnou knížku o assembleru od Proximy, ale čuměl jsem do toho jako vyvoraná myš a rozuměl jsem tak každýmu druhýmu slovu.Tak s tou já čest bohužel neměl. Já měl k dipozici jen slovenský překlad nějaké anglické knížky s robůtky a to se docela dalo.
No, nevim. Já už měl vedle pixle nachystaný vždycky nůž na zaseknuté klávesnice(nebo jak se ty plastové kostičky na Didaktiku jmenovaly).To já zase ostrou tužku na RESET
To už ale potom nezažil člověk tu srandu kdy u programu o 1000 řádcích je potřeba něco přidat mezi řádek 251 a 252.(GOSUB
prosím nechme hnít)
Některé verze Basicu obsahovaly textový editor který uměl vše komplet přečíslovat. Stačilo něco jako RENUME 10 a řádky šly hezky po deseti, přečíslovalo to i všechny GOTO a GOSUB skoky :)
Dělat v assebleru bylo na dnešní poměry něco naprosto hardcore.No on se o moc ten samotný BASIC od assembleru v podstatě moc nelišil, jen člověk potřeboval trošilinku větší znalost HW a jak říkám, existoval i překladač BASICu do strojového kódu.
Nahrát zdlouhavě z magneťáku kompilátor (Mons/Gens)No jo, to se někdo zase měl. Já měl ze začátku k dispozici jen tabulku instrukcí pro Z80,
PEEK
, POKE
a RANDOMIZE USR
.
napsat pár řádek, zkompilovat, spustit, vlivem chyby se to celé zhroutilo -> tedy restartoval komp a člověk mohl začít znova úplně od začátkuNa disketovce to nebylo zas tak strašné.
Žádný mutitasking, procesy, žádný disk a soubory na něm, jen RAMka a Emgeton kazeta v magneťáku... :@)Multitasking, procesy a disk jsou jen serepetičky, který si může každý tvrdý geek odpustit.
BTW: Multitasking(nebo alespoň nějaké jeho záchvěvy) se používali např. u her když bylo třeba aby hrála(nebo spíš pípala) hudba a něco se vykreslovalo, ne?
Proč by někdo používal jiný systém než ten se kterým je počítač dodávánno to je tady, mezi nami linuxaky docela blba otazka. kdyz si vemu, ze sehnat ntb. bez windows a s linuxem je docela problem (nehlede na to, ze i predinstalovany linux bych treba ja rovnou smazal a dal si tam svuj).
A přitom stačilo programovat v nejvhodnějším jazyku pro osmibity, a člověk byl takovýchhle blbostí ušetřen...To stačilo ale ne každý měl trpělivost se ten assembler naučit. S knížkou Bity do bytu se to ale dalo zvládnout.
bylo to o něco rychlejší než přes interpretO něco? Když si vzpomenu na rozdíl kopírování něčeho do framebufferu nebo VIDEORAM nebo jak se to vlastně jmenovalo(prostě od adresy 16384 nahoru), tak to byl sakra rozdíl.
Akorát výsledný program měl dost často tendence se zhroutit.Tak toho jsem si nikdy nevšiml. Vždycky to zkontrolovalo na začátku jestli nemůže něco dělat neplechu a pak to šlapalo jako hodinky.
No to je asi tím že já měl Amstrad CPC a ne ZXCPC models were based on a Zilog Z80 processor clocked at 4 MHz.
ale myslím, že tohle není Billova chyba, on Microsoft v podstatě jen spustil a za chyby jejich sw nemůže on, ale právě těch 160 programátorů.Netvrdím, že jsou Windows bezchybné, ale copak je na samotných Windows tak hrozného, že za to zaslouží 160 programátorů ke zdi?
Programátor se může podívat, jak postupoval někdo jiný před ním, a z tohoto projektu se inspirovat při zlepšování toho vlastního.Tohle je imho jedna z myšlenek open source ne?
ISSN 1214-1267, (c) 1999-2007 Stickfish s.r.o.