Portál AbcLinuxu, 30. dubna 2025 23:50
John Page pracoval dlouho pro Hewlett-Packard, ale začátkem 80. let založil s partnery firmu Software Publishing, pro kterou napsal jedny z prvních programů, jež mohli obyčejní uživatelé používat na Apple II. Vše začalo databázovou aplikací PFS:File.
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ů.
John Page se narodil 21. září 1944 v Londýně, kde také v mládí začal pracovat s počítači a zatím u nich vydržel přes dvacet let, tedy celou svou profesionální kariéru.
V roce 1970 přišel do firmy Hewlett-Packard. Čtyři roky poskytoval technickou podporu HP v Londýně, Ženevě a jiných částech Evropy. V roce 1974 se přestěhoval do centrály HP v kalifornském Cupertinu, aby řídil celosvětovou technickou podporu počítače HP 3000. Později přešel do oddělení pro výzkum a vývoj softwaru, ve kterém vyvinul takzvaný Image Database Management System. Zároveň s prací pro HP studoval informatiku a umělou inteligenci na Stanfordu.
V roce 1980 odešel z HP a společně s Fredem Gibbonsem a Janelle Bedkeovou založil firmu Software Publishing Corporation. Ve své garáži napsal první firemní produkt, ze kterého se později stal systém PFS:File. Rodina PFS dnes obsahuje přes šest programů, které pokrývají všechny možné aspekty řízení informací. John Page dělá ve firmě Software Publishing Corporation viceprezidenta pro výzkum a vývoj.
John Page je upravený, příjemný a trochu klukovsky vypadající muž s přívětivýma očima, vřelým úsměvem a lehkým britským přízvukem. Na sobě měl šedé kalhoty a modrou košili s rozepnutými knoflíčky u krku. Po průchodu pohodlnými, v kalifornském stylu zařízenými kancelářemi firmy SPC s borovými trámy jsme se dostali do prázdné konferenční místnosti. Tam začal Page klidně rozebírat svůj přístup k programování a vedení softwarové firmy.
Když jsem ho požádala, aby se s námi podělil o ukázku svého zdrojového kódu, která by byla otištěna v knize, odmítl. Řekl, že to je „šílený nápad. Architekti také publikují ukázky kostelů a muzeí, které postavili, a nikoliv fragmenty stavebních plánů.“ Měl za to, že kus kódu by byl pro čtenáře poměrně nesrozumitelný. Namísto toho navrhl, abychom uvedli seznam jeho mnoha úspěchů a příspěvků k celému počítačovému oboru. Právě tato poznámka víc než cokoliv jiného názorně ukazuje Pageův přístup k programování: když píše software, má před sebou obraz obyčejného uživatele. Johna Page nefascinují a nemotivují prostředky, ale výsledky.
Co vás vedlo k vývoji systému PFS:File a celé rodiny PFS?
Když mě přeložili do kalifornské továrny HP, ve které se vyrábí HP 3000, dostal jsem se hodně k softwaru. Tehdy jsem začal pracovat na Image, svém databázovém programu pro HP 3000. Dnes je z něj nejrozšířenější databázový systém pro mainframy a minipočítače.
Když jsem v HP nad databázovými systémy strávil nějaký čas, překvapilo mě, jak moc jsou navržené s ohledem na programátory a nikoliv koncové uživatele. Tehdy to bylo v pořádku, protože firmy chtěly spíš vývojářský nástroj než produkt pro uživatele. Ale jak jsem tak sledoval vývoj osobních počítačů, došlo mi, že by se dal udělat databázový systém opravdu použitelný obyčejnými lidmi. A začal jsem si s tímhle nápadem hrát.
Firmu Hewlett-Packard tehdy osobní počítače moc nezajímaly, natož pak software pro osobní počítače. Setkal jsem se s Janelle Bedkeovou a Fredem Gibbonsem, se kterými jsem později založil firmu. Mluvili jsme spolu o tom projektu a rozhodli se najít někoho, kdo by nám ho vydal. Nenašli jsme. Pak jsme si ale uvědomili, že softwarový průmysl čeká velký boom. Došlo nám, že je nejlepší příležitost založit firmu, a tak vzniklo SPC. Dali jsme dohromady podnikatelský plán, ve kterém byla vidět rychlost růstu a podíl na trhu, se kterým jsme mohli počítat. Jakmile jsme se jednou definitivně rozhodli firmu založit, měl jsem kde začít realizovat nápady, které se mi v hlavě honily už asi rok. Tak vznikla celá rodina programů se společnou hlavičkou PFS.
Jak jste chtěl programy z rodiny PFS odlišit od ostatních programů, které tehdy byly na trhu?
Podle mě tehdy chyběla aplikace, kterou by mohli používat obyčejní lidé – třeba jako telefon nebo auto. Cílem bylo navrhnout program, který by se používal stejně snadno jako nějaký spotřebič. Znamenalo to dělat zajímavé kompromisy v návrhu, protože jsem nutně musel usilovat o maximální srozumitelnost, nikoliv maximální výkon nebo funkčnost. Je to jako s telefonem, který zvenčí nevypadá nijak složitě. Vytočíte číslo, telefon zazvoní a můžete mluvit. To je všechno. Což není moc, že ano? Ale aby to fungovalo, musí se za scénou snažit řada složitých technologií. Návrh PFS vypadal stejně jako telefonní systém: jednoduchý zvenčí, náročnými technologiemi zajištěný zevnitř.
Během návrhu PFS jsem narazil na jeden zvláštní princip návrhu softwaru: Složité programy se píší mnohem snáz než programy jednoduché. Přesně opačně, než byste čekali. Napsat složitý program je jednoduché, protože složitost přenesete na uživatele; necháte všechna složitá rozhodnutí na něm. Například dejme tomu, že uživatel chce vědět, kolik je v souboru bloků. Vy to uděláte tak, aby si to mohl sám zjistit. Co s těmi údaji bude dělat, ví Bůh. Ale při návrhu jednoduchého programu si musíte na všechny otázky odpovědět sami. Přesun od vývoje složitého softwaru určeného především programátorům k vývoji programů pro obyčejné pany Nováky pro mě byl fascinující zážitek.
Proč jste PFS psal v Pascalu?
Nezapomínejte na to, že teď po odchodu VisiCalcu je PFS služebně nejstarší program na trhu. Tehdy před pěti lety nebylo žádné C, takže jsem měl na výběr mezi Basicem, assemblerem a Pascalem. Basic prostě nebyl ono. A v assembleru se mi to celé psát nechtělo, trvalo by to moc dlouho. Potřeboval jsem vyšší jazyk, který má nějakou páru. Jediná možnost byl Pascal. Taky nesmíte zapomínat na to, že tohle bylo před vynálezem IBM PC, takže na trhu stál za úvahu jen Apple II a Pascal byl jediný jazyk, který na téhle platformě splňoval mé potřeby.
Při psaní nových verzí přecházíme k C, protože je pro vývoj lepší než Pascal. Ale s Pascalem jsme se neměli zle – rozhodně ne tak zle, jak si nerdové myslí. Řekl bych, že vývoj v C je jen o nějakých 5–10 procent produktivnější než v Pascalu.
Zmínil jste se o tom, že vývoj PFS byla složitá záležitost. Jak dlouho vám trvalo PFS navrhnout a napsat?
Asi osmnáct měsíců mi zabral návrh programů File a Report. Dělal jsem to z větší části sám, až ke konci jsem dostal pomoc.
Co byl při návrhu PFS největší problém?
Tehdy byl největší problém nacpat všechno do 48K Apple a dosáhnout rozumné rychlosti. Pascal byl interpretovaný, takže jeho výkon měl docela rezervy. Když byl program hotový, byl neuvěřitelně pomalý, takže jsem vzal všechna úzká hrdla a přepsal je v assembleru. Tím jsem se zbavil výkonnostních problémů a program jel dostatečně rychle, ale přepisovat něco v assembleru bez ladicích nástrojů je hrozná zkušenost.
Druhý problém byl strategický, obchodní. Zrovna když jsme přišli s PFS, 48K Apple se považoval za silnou konfiguraci – vlastně to byla jejich tehdejší špička, většina modelů měla 32 K paměti. Existoval sice i 64K Apple, ale těch 16 K paměti navíc stálo 550 dolarů. Nesmíte zapomínat na to, že tehdy ještě byly počítače v pravém slova smyslu „osobní“: většina lidí si je platila z vlastní kapsy a přídavná paměť za 500–600 dolarů byla pořádná investice. Museli jsme se rozhodnout.
Na 32 K jsme program prostě neměli šanci dostat. Už tak jsme rozdělili File a Report na dva samostatné programy, protože společně by se do 48K Applu II nevešly. Dodneška jsou samostatné, ale už to nebude trvat dlouho. Přemýšleli jsme nad tím, jestli můžeme mít úspěch i s požadavky na 48 K paměti. Větší paměťové nároky byly riziko, protože zmenšovaly cílový trh. Řadu nocí jsem proležel a přemýšlel, jestli nám to projde.
Jak se tehdy dařilo ostatním databázovým programům?
Tehdy jsme měli docela slušný strach z toho, že přijde Stoneware DB Master a vymete nás z kurtu. Ale obešli jsme ten problém rozdělením trhu – zařídili jsme, aby DB Master vypadal jako špičkový produkt, který je pro obyčejné lidi příliš složitý. Je legrační, jak nám štěstí za ta léta různě přálo.
Tušil jste, že bude PFS mít takový úspěch?
Ani v nejmenším. Často se mi v životě stává, že si určím nějaký cíl a pak už ho nikdy nepřehodnocuji; nepřemýšlím nad tím, jestli je složitý, jestli ještě pořád stojí za to, jestli ho zvládnu. Mám klapky na očích a věnuji se svému problému. Přesně tak to bylo s PFS:File. Když se začal prodávat, byl jsem v šoku. Říkal jsem si: „Bože můj, ono to funguje.“
Programujete ještě?
Programování mě ještě pořád baví, ale nedostanu se k němu tak často, jak bych chtěl. Pro morálku ve firmě by nebylo dobré, kdybych se moc věnoval nějakému projektu nebo programování. Ve větších firmách zaměstnanci potřebují šéfa, který všechno ví, ale jen do té míry, aby si zaměstnanci nepřipadali zbyteční. Musí mít pocit, že jejich práce je jejich vlastní dítě, musí se cítit jejím autorem, jinak ztrácejí motivaci.
Často si říkám, jaké to asi musí být v Microsoftu, kde mají ve vedení někoho tak známého a technicky dominantního. Přemýšlím, jestli to nemá negativní vliv na morálku softwarových vývojářů ve firmě. A taky si říkám, jestli když někomu svěříte kontrolu nad celou firmou, jestli tím neomezujete její potenciál pro další růst. Když firma dosáhne velikosti, při které už to zakladatel nezvládá, musí se zodpovědnosti chopit další a vést ji směrem, kterým by ji vedl on. V SPC se snažíme větší slávě vyhýbat, šetříme síly na pozdější růst.
Měl jste potíže s přechodem od programování k vedení velké firmy?
Ten přechod byl velice pozvolný, protože lidi už řídím asi dvacet let. Jestli chcete slyšet pravdu, tak těžký byl přechod nazpět, od manažera k programátorovi. Ještě než jsme založili firmu, byl jsem zvyklý řídit hodně lidí v HP. A když jsem se vrátil k programování, musel jsem se spolehnout výhradně na sebe. To byl šok. Měl jsem z toho trochu strach – říkal jsem si, jestli ještě vůbec umím psát programy. Ale je to jako jezdit na kole. To se nezapomíná, prostě šlápnete do pedálů a vyrazíte do zapadajícího slunce.
Když už teď necháváte programování na ostatních, jak hledáte dobré programátory?
Firmy potřebují opravdové architekty – lidi, kteří vidí dál než na základní nástroje; kteří chápou, co je potřeba postavit; kteří vědí, kdy a jak využít výhody různých technických řešení. Například chytrý inženýr, který ví, že paměti obrovsky porostou, si může sednout a zamyslet se, co z toho plyne pro návrh systému. Které předpoklady souvisely s omezenou velikostí paměti? Jak na tyhle staré představy přijít a jak se jich zbavit? Jak přijít na jiný návrh, který bude odrážet nový úhel pohledu na věc? Bez takových lidí se firma neobejde.
Firma také potřebuje lidi, kteří dokáží napsat hromadu kódu pro danou architekturu. Lidi, kteří jsou zkrátka dobří mechanici. Zadání je naprosto jasné a na starost ho může kterýkoliv čerstvý bakalář informatiky. A nejspíš ho zvládne bez problémů. Hlavní otázkou pak je, jak dosáhnout rovnováhy mezi těmihle dvěma druhy lidí.
Jaký je rozdíl mezi sólovým psaním programu a programováním v týmu?
Pokud produkt vyžaduje čtyři nebo pět lidí, musíte k němu přistupovat jinak, než kdybyste ho psali sami. Pevně věřím tomu, že návrh a hlavní datové struktury by měl dělat jeden člověk, nanejvýš dva lidé. Pak dostanete konzistentní a elegantní návrh. Můžete to vzít za špatný konec, snažit se do hry pustit ostatní a nechat návrh na nějaké komisi. To je naprosto fatální.
Takže během specifikace mám velice malý tým, který pak – pokud je to potřeba – na implementaci rozšiřuji o další lidi. Čím větší je tým potřebný na implementaci nějakého návrhu, tím pečlivější musíte být při rozebírání programu na samostatně zvladatelné kusy a definování rozhraní. Psát nějaké zprávy o struktuře programu a dokumentovat každý krok není vyloženě nutné – ledaže by program byl tak velký, že by na něj dva nebo tři programátoři nestačili.
Některé systémy, třeba návrh programu pro ovládání raketoplánu, vyžadují stovky programátorů. Pak musíte mít tu disciplínu a rozebrat ho na malé kousky tak, aby to všechno fungovalo. Malý program se dá rozdělit zbytečně podrobně a velký program naopak nedostatečně, takže musíte vybrat správnou techniku pro daný problém. Tak to dělám já.
A co programátoři, kteří se neměli možnost zúčastnit návrhu; jak je motivujete?
Ti mohou být zklamaní, ale hned na začátku jim řeknete, že to musí přijmout jako podmínku práce na projektu. Naštěstí je hodně nových programátorů, kteří se rádi něco naučí od dobrého, vysokoúrovňového designéra. Dáváte jim tím cestu k oboru. Cestu, která je časem může přivést až k jejich cíli, k návrhu.
Jakým způsobem řídíte tým, který pracuje na nějakém programu?
Když dostane tým v naší firmě první projekt, musí se hodně naučit o tom, jak věci děláme u nás v SPC. Uvažujeme o věcech způsobem, který naše produkty odlišuje od těch ostatních. Já je těmi principy provádím od samotného začátku. Neříkám jim, jak mají navrhovat – spíš jim vysvětluji proces, kterým já sám navrhuji. Jinými slovy se je snažím vzdělávat. Snažím se jim předat důležité schopnosti, které jim zůstanou navždycky. Někdy přijdou s něčím, co se mi nelíbí – ale na druhou stranu i já občas přijdu s něčím, co se zase nezdá jim. První program takového týmu v sobě většinou mívá pár přehmatů. Necháváme je tím projít záměrně, protože ve firmě chceme lidi, kteří zvládnou další růst. Nechceme, aby se to zvrtlo. Funguje to výborně. Máme ve firmě týmy, které pracují na svém třetím produktu, a ty jsou vážně dobré. Odvádí lepší práci, než bych odvedl já. Zjišťuji, že se od nich sám leccos naučím, a z toho mám velkou radost.
V čem přemýšlí SPC o problémech jinak? Máte nějaké postupy nebo pravidla, kterých se programátoři musí držet?
Žádné základní principy nemáme – jen musíte znát svého zákazníka, znát hardware a navrhnout nejlepší možný produkt pro daného zákazníka a hardware.
Musíte rozumět zákazníkům a jejich potřebám. Teprve pak pro ně můžete navrhnout správný produkt. Může to být něco na první pohled jednoduchého, třeba jako PFS:File, nebo něco zdánlivě složitého, například překladač. První je určený obyčejným uživatelům, druhý programátorům a inženýrům. Netoleruji vývojáře, kteří chtějí pracovat jen na složitějších problémech. Za prvé mi takový přístup připadá nedospělý – dobrý architekt navrhuje se stejnou radostí altán i muzeum a každé zadání pro něj představuje jedinečnou výzvu. A za druhé si myslím, že skutečná výzva je navrhnout software, který je jednoduchý zvenčí a složitý zevnitř. Nechápu lidi, které taková výzva neláká; mě fascinuje.
Za ty roky, které pracujete s počítačem, jste si jistě vytvořil nějakou představu o tom, jak se počítače průběhem času mění?
Počítače zapadly do stereotypu, už se hezky dlouho neobjevilo nic nového. Trh nás navezl do zbytečně komplikovaných systémů, a je to z větší části chyba IBM. Každá z těch „nových“ inzerovaných funkcí je vypůjčená od minipočítačů a mainframů. Každá další generace IBM PC je složitější než ta předchozí a hůř se používá. PC rychle klesá zpátky na úroveň minipočítače a snad se z něj IBM dokonce podaří udělat mainframe. Staré složitosti se vracejí, elegance mizí. Dokonce i chudák starý Macintosh to schytal, protože nemá všechno, co by od něj manažeři podnikových informačních systémů chtěli. I jeho návrháři do něj zřejmě budou muset všechny ty složitosti přidat. Je škoda, že k takovým věcem musí dříve nebo později dojít.
Osobní počítače jsou v důsledku čím dál oblíbenější u lidí z velkých firem, kteří byli dřív zvyklí na mainframy. Ti začínají osobní počítače přijímat, ale pořád se k nim snaží chovat jako k minipočítačům. Což ony nejsou – jsou to přerostlé osobní kalkulačky. Na to už jsme zapomněli.
Myslíte si, že tento trend zvyšování složitosti bude pokračovat?
Doufám, že ne. Mám pocit, že se osobní počítače budou vyvíjet dvěma směry. Jednak tu budou obchodní osobní počítače, na kterých poběží tytéž nástroje jako na mainframech, tedy Cobol a všechny podobné hrůzy. (Manažeři podnikových IS totiž ještě pořád programují v Cobolu, stejně jako před dvaceti lety. Když se jim pokusíte navrhnout něco jen trochu nového, řeknou vám: „Ne, nekomplikujte mi život, chci svůj starý dobrý Cobol.“) A jednak si optimisticky myslím, že se průmysl vrátí ke skutečným osobním počítačům, které budou použitelné pro obyčejné lidi; stejně jako byl například původní Apple. Budou levnější, výkonnější a budou se lépe používat. Momentálně trochu bloudíme. Příchod skutečného osobního počítače nalije celému oboru novou krev do žil.
Jak při vývoji programů držíte tempo s měnícími se požadavky zákazníků?
Produkt se dá změnám na trhu přizpůsobit dvěma způsoby. Jedna možnost růstu je spoléhat na vývoj počítačů a počítačových technologií. Hledáte nové využití počítačů, i kdyby se třeba rozcházelo s vaším původním nápadem. Takový vývoj od vás vyžaduje něco úplně jiného, než jste dělali na začátku. Když se například pustíte do sazby, můžete si najednou uvědomit, že počítače jsou perfektní na sazbu. K tomu ovšem bude potřeba naprosto jiný software, než který jste původně vyvíjeli – a pokud se má prodávat, musí se vám opravdu povést.
Druhý typ růstu mají na svědomí změny ve zkušenostech vašich zákazníků. Oni si lépe uvědomují, co pro ně počítač může udělat, a jejich požadavky tím pádem rostou – což ovšem neznamená, že by chtěli něco složitějšího. Chtějí, aby toho nové programy uměly víc, ale aby zůstaly jednoduché. Právě tenhle požadavek je pro nás výzva, právě tenhle směr jsme si vybrali. Snaha uspokojit zákazníka je podle mě potřeba, pokud se má celý obor někam posunout – například tím, že uděláte program s větším počtem funkcí, aniž byste ho komplikovali. Vyžaduje to od nás jistou intelektuální námahu, ale právě v tom děláme pokroky. Celý počítačový průmysl se bohužel zbláznil do složitosti a z nějakého perverzního důvodu chce, aby byla vidět.
Takže si myslíte, že celý počítačový průmysl ženou dopředu spíš technologie než trh?
Přesně. Skoro jako kdyby ty technologie chtěli jen na parádu. Je to něco jako drahé přehrávače: čím víc zaplatíte, tím víc světel a čudlíků dostanete. Stačí se na věc podívat z pohledu opravdového uživatele – řekněme ženy toho pána, co kupuje – a je vám jasné, že to je naprosté šílenství. Zjistíte, že je z těch udělátek jenom nešťastná. Vsadím se, že kdybyste mohli sejmout otisky a zjistit, které z ovládacích prvků se doopravdy používají, došli byste k nějakým třem z devadesáti. Nikdo neví, co ty ostatní dělají, a nikoho to nezajímá, protože přehrávač hraje i bez nich.
Stejně lidé přistupují i k programům. Chtějí psát dopisy nebo výkazy, a tak si koupí ohavný, špatně navržený textový procesor. Jenže on je plný ovládacích prvků, na které nikdo nesahá a které nikdo nechce. Téhle technologické mánie se musíme zbavit. SPC schovává technologie před uživatelem záměrně, a proto nás bohužel často považují za technologicky nedospělou firmu. Je nepříjemné, když si dáte tolik práce s tím, abyste veškerou složitost schovali, a pak vás na trhu vypískají, protože program nevypadá složitě.
Jak se dá schovat složitost?
© Susan Lammers 1986–2008, přeloženo s laskavým dovolením autorky.
Stejně lidé přistupují i k programům. Chtějí psát dopisy nebo výkazy, a tak si koupí ohavný, špatně navržený textový procesor. Jenže on je plný ovládacích prvků, na které nikdo nesahá a které nikdo nechce.A to se psal rok 1986!
25.6.2008 11:38
Jiří Svoboda | skóre: 37
| blog: cat /dev/mind
| Prostějov
25.6.2008 21:16
Pavel Čejka | skóre: 28
| blog: tosinezaslouzijmeno
Stejně lidé přistupují i k programům. Chtějí psát dopisy nebo výkazy, a tak si koupí ohavný, špatně navržený textový procesor. Jenže on je plný ovládacích prvků, na které nikdo nesahá a které nikdo nechce. Téhle technologické mánie se musíme zbavit. SPC schovává technologie před uživatelem záměrně, a proto nás bohužel často považují za technologicky nedospělou firmu.
Brrr... tak přesně tohle je pitomost. Schovávat nebo dokonce odstraňovat málo používané funkce je špatné. Dobré je často používané funkce ponechat snadno dosažitelné, přehledné, srozumitelné. Ale rozhodně a v žádném případě neodstraňovat (nebo složitě skrývat) funkce, které uživatel použije sice jen sporadicky, ale když chybí, tak mu to způsobí víc problémů než jejich hledání a ta trocha času, který věnuje na seznámení se s takovou funkcí. <provokace>Velký to problém Gnome</provokace> Je mi upřímně jedno, když hloupější uživatel tápe.
Je mi upřímně jedno, když hloupější uživatel tápe.Hádám, že právě tohle bude rozdíl mezi tebou a člověkem, který se snaží najít a pochopit svou cílovou skupinu
27.6.2008 09:58
Petr (DotaZ) Jakubec | skóre: 5
ale ma kazdy tolik casu aby se jimi zabyval? vetsina urcite ne, neb to pro ne ani neni nijak dulezite, a rozhodne ne stezejni.
jestlize sw nejde pouzit na zaklade pocitacove gramotnosti, je neco spatne. a je jedno ze tuto gramotnost leta devastuje microsoft, s tim se musi proste pocitat. menit to lze pouze pomalu a zlehka v ramci evoluce, revoluce sice muze vyjit ale obvykle to je velky risk.
27.6.2008 19:28
Pavel Čejka | skóre: 28
| blog: tosinezaslouzijmeno
pan Cejka by prvne musel pochopit, ze to neni o relaci chytry - hloupy, ale o tom "chci/potrebuji se zabyvat" a "kaslu na to chci to hlavne rychle".
Myslím, že to není o tom, co bych měl pochopit, ale o tom, co každý z nás chápe pod schováváním funkcí pro dobro tápajících a pro zlost těch ostatních. Ta hranice je totiž u každého trochu jinde.
Zrovna produkty Micro$oftu považuju často za příklad programů s nimiž se pracuje na základě zkušeností relativně dobře, ale běda, pokud má člověk zkušenosti obecnější, tím myslím ne jenom s M$ produkty, tak se tam najednou začne ukazovat spousta všelijakých nelogičností. Například ... doufám, že si to pamatuju dobře, už jsem s M$ Office nepracoval pár let (vídám ho, jen když se pokazí někomu jinému) - v M$ Office do verze 2003 se nastavoval formát a okraje stránky někde v menu "Soubor" -> "Vlastnosti" ... nebo něco podobně divného, v OpenOffice to je v "Formát" -> "Stránka". Čímž neříkám, že OOo je vždy logičtější, ale chci tím ilustrovat, co si představuju pod špatně umístěnou funkcí programu.
Ano, chápu že existují nedočkavci, co chtějí vše hned bez práce, ale proč je za každou cenu podporovat? Bavíme-li se o softwaru, tak bychom se mohli dostat třeba ke srovnání jednoúčelového generátoru hezkých obrázků a srovnání Gimpu. Je Gimp horší jen proto, že nakreslit stejný/podobný obrázek je v něm pracnější? Lze říct, že jeden z nich je lepší, nebo je nejprve nutné se zeptat "a k jakému účelu"?
Ani jedno ovšem nevyvrací můj názor, že skrývat funkce jen proto, aby hloupější uživatele nemátly je pitomost. Hloupější uživatelé nechť používají pro ně určené jednoduché programy a nekecají do zjednodušování těch, které vyhovují schopnějším.
jestlize sw nejde pouzit na zaklade pocitacove gramotnosti, je neco spatne
A co to je počítačová gramotnost? Schopnost psát na klávesnici a trefit kurzorem ikonu? Najít si něco na webu? Hrát hry? Vytvořit web? Vytvořit hru? Napsat jaderný modul k hardwaru?
Object Pascal (Delphi apod.) rozhodne neni spatnej jazykŠkoda, že dneska je to v podstatě mrtvola.
Byl jsem přesvědčený, že jazyk, překladač ani vývojové prostředí už se dávno nevyvíjí, ale koukám, že CodeGear se pořád ještě snaží. Tak tu mrtvolu beru zpět, jsou jednou nohou v hrobě S razantním nástupem .NETu na Windows, za kterým stojí bývalá klíčová persona Borlandu, a těžce nevydařeným Kylixem navrch, se to prostě muselo stát.
ISSN 1214-1267, (c) 1999-2007 Stickfish s.r.o.