Wow!

Vida. Myslel jsem si, jak si pěkně budu hovět v laskavé náruči .NET, a místo toho jsem spadl přímo do Win32. Však víte: to je ten svět, kde ty důležité věci jsou psány velkými písmeny, každá funkce má alespoň jednu Ex (a možná i ExEx) verzi a základem je pamatovat si, že když něco chcete, musíte pěkně poprosit funkcí SendMessage.

Popravdě musím říct, že až teď jsem si uvědomil, jak jsou Windows obrovské, co všechno v nich je a jak je zatraceně těžké v nich programovat.

Win32 API je vlastně úžasný artefakt závratné historické hodnoty, který umožňuje sledovat jak se osobní počítače vyvíjely posledních dvacet let. V dobách, kdy výkonné počítače měly 2MB paměti a jejich procesor běžel s taktem 20MHz, jistě bylo rozumné snažit se nacpat co nejvíce informací do co nejméně bytů paměti, a co nejvíce věcí řešit co nejmenším množstvím kódu. V té samé době, když ještě neexistovalo C++ (současná podoba byla standardizována až v roce 1998), bylo zcela určitě novátorským přístupem implementovat ten jediný prvek uživatelského rozhraní kterým Windows disponují (ano, správně, je to okno, hned ten název -- Windows -- dává takový pěkný dvojsmysl, že?) tak, že umožňuje tzv. subclassing, tedy možnost podstrčit systému ke správě takového okna správně napsanou funkci, ve které můžete z pitomého obdélníku udělat cokoliv, od tlačítka, přes textové pole až po... no, třeba ribbon, kdybyste o to stáli. A ačkoliv si to nebudete myslet, i ty registry, nad kterými každý ohrnuje nos, jsou poměrně slušně navržené (horší je to samozřejmě s implementací -- skoro bych se vsadil, že registry vymyslel ten tým, co dělal Windows NT, a pro Windows 95, blahé paměti, vyšla jejich nedomrlá verze, která brala ohled na to, že uživatelé nechtějí věnovat 70% výkonu svého počítače robustnímu úložišti konfigurace).

Bizarní na tom je, že tenhle místy prazvláštní slepenec funkcí (z nichž některé spojují podobné vstupní parametry a podobné výstupní hodnoty) pohání všechny Windows (tedy od verze 3.1, nebo kolik), včetně těch úplně posledních.

Znamená to dvě věci. Za prvé: skoro všechno co napíšete ve Win32 pro jedny Windows, poběží i na všech ostatních. A za druhé: Microsoft ve Windows nemůže nic změnit.

Myslím to takhle: Když píšete program, a rozhodnete se, že mezi dvěma verzemi něco změníte nebo opravíte, čímž se chování vašeho programu v 1% případů mírně změní, je to pro vaše uživatele jistě nepříjemné, ale, zatraceně, je to jedno mizerné procento a opravili jste chybu, kdo by si s tím lámal hlavu? Ovšem pokud jste Microsoft, a jedno procento uživatelů je, řekněme, 10 miliónů lidí, pak už takhle uvažovat nemůžete. Říkáte si: K čertu, náklady na opravu všeho softwaru, který je na téhle chybě závislý se zhruba vyrovnají nákladům na stavbu jedné či dvou letadlových lodí, nebo na stavbu základny na Měsíci, nebo tak něco. A nikdo nezaručí, že software, na kterém je třeba to jedno procento lidí existenčně závislých, někdo opraví. Co pak budete dělat s těmi 10 miliony telefonátů na servisní linku?

Podívejte se na Visty: Microsoft se v nich pokusil opravit hodně chyb, které mu byly dlouho vyčítány. Od přístupu co není zakázáno, je povoleno (tedy: uživatelé přeci nejsou banda tupých hovad), přešel k co není povoleno je zakázáno (tedy: dobře, když se chováte jako banda tupých hovad, ztížíme vám provádění těch největších pitomostí), protože léta uživatelé fňukali nad mizernou bezpečností Windows a tak dále. Odměnou mu za to je nepřetržitý proud neinformovaného plácání o tom, jak Visty jsou jen nové UI (jistě, navíc zkopírované z počítačů Apple), jak najednou nefunguje spousta software a hardware, kolik Visty čeho žerou a čím vším pořád točí a že Windows XP jsou stejně lepší, a kdo ví co ještě.

Dobrá, při uvedení Windows XP také všichni blekotali o tom, že v nich není nic nového než kulatá okna a tak dále a tak podobně, a stejně jako při přechodu z Windows 2000 na Windows XP tahle nesnesitelná litanie nejpozději koncem tohoto roku ustane.

Je tu ale přeci rozdíl: změna mezi Vistami a XP je opravdu podstatná, a ovlivní poměrně mnoho uživatelů (třeba celá ta věc s UAC -- v okamžiku, kdy na XP máte hotovou aplikaci, musíte ve Vistách začít řešit všechny tyhle manifesty, a Windows Defendery, a blokovače Bůh ví čeho). Spousta programů, které spoléhaly na to, že to či ono, je tam či onde, najednou nefunguje, protože tady a támhle, byly zalepeny ty či ony bezpečností díry, nebo se věči, o kterých Microsoft nikdy neřekl, že budou tam kde jsou i v budoucnu, přesunuly jinam, a najednou informace, která se ve Windows 2000 nebo XP dala vyčíst jedním dobře mířeným přístupem do registrů musí dohledávat přes API (což se ostatně měla už i ve Win2000, jen to nikdo nedělal, protože to bylo moc práce, a registry jsou přeci naše, že ano!).

Čímž se oklikou dostávám k tomu, co jsem asi tak zhruba chtěl říct: ve Win32 se neprogramuje moc dobře. Ne proto, že by API bylo nějak extrémně špatně navržené. Ve skutečnosti je docela slušné a v rámci jednotlivých domén i poměrně konzistentní, když uvážíme, že se z počítačů s výkonem, který dnes má každá lepší kalkulačka dokázalo úspěšně přesunout na stroje s kdo ví kolika jádry a gigantickým (z pohledu počátku 90. let) množstvím paměti všeho druhu. (Vsuvka: Zrovna tento týden jsem poslouchal nějaký podcast, kde se řešilo, proč Windows nemohou pracovat na více než 64 procesorech. Je to proto, že maska, která určuje, na kterých procesorech -- nebo jádrech procesoru -- může program běžet, má jen 64 bitů. Dovedu si představit, jak někdo v roce 1992 uvažuje, zda takovou masku implementovat obecně, jako nějaký druh seznamu, nebo malinko špinavým trikem, jako jednu dlouho proměnnou. A je mi jasné proč, při tehdejší úrovni počítačů, zvolil malinko špinavý trik.) Problém programování ve Windows je v tom, že ve Windows je toho tolik.

Na tomto místě je obvyklé říct (a ano, i já to s oblibou říkám), že tyhle obří operační systémy jsou nesmysl, a že z nich stejně většina lidí využije jen malou část. Ovšem otázka je, kterou malou část většina lidí využije, když je jich třeba miliarda? Čeho vlastně má mít takový správný malý operační systém vestavěnou podporu? Sítě? Grafická akcelerace? Asi tak sto tisíc různých druhů nejexotičtějších periferií, bez kterých právě těch bezvýznamných 10 miliónů lidí nemůže být? Co byste z Windows vyhodili, aby to nikomu nechybělo? Nebo aby to chybělo méně než milionu lidí? Co když někdo rozhodne, a z další verze vypadne zrovna to, co potřebujete vy?

Na druhou stranu: Windows API má dneska kolem 14000 funkcí. I když dokumentace, kterou Microsoft k API poskytuje je (ve srovnání s jinými API) na dobré úrovni, je to, zatraceně, 14000 funkcí. Kdo se tohle může naučit? Kdo může mít alespoň základní přehled o tom, jak co správně udělat v kterékoliv oblasti, kterou to API pokrývá? Dobrá, dneska zadáte dotaz do Googlu, klik-klik, a o hodinu hledání dál máte zhruba dvě až tři diskusní fóra, ze kterých poskládáte jak udělat to co potřebujete udělat. Ale kdo z programátorů, po kterých šlape jejich šéf, že už to, sakra, mělo být dávno hotové, si vybere hodinu hledat, dvě hodiny studovat, a další hodinu programovat (správně), když může zmáčknout Win+R, napsat regedit, Ctrl+F, klepy-klepy-klep, hmmm, takže HKEY_LOCAL_MACHINE lomeno System lomeno... no vida, a už je to tady!? Samozřejmě kromě vás?

Proto není divu, že pro Windows vznikají -- ehm, jak to říct -- zprasené aplikace. I já sám jsem jistě spoustu věcí udělal nesprávně. A to ne proto, že bych je nechtěl udělat správně. Prostě nevím, jak to správně vypadá. Původně jsem si myslel, že by mi třeba pomohlo nějaké školení nebo knížka. Ale jak chcete udělat školení nebo knížku na 14000 funkcí? Mám Petzolda, který je jistě dobrý jako úplný základ, ale problém s aplikacemi je v tom, že mají řešit nějaký problém, a řešení takového problému se většinou skládá ze spousty ne zcela souvisejících pod-problémů. Jak se na tohle připravit? Jak máte vědět, co budete dělat příště (pokud tedy pracujete na více malých a krátkých projektech a ne na jednom velkém a dlouhém)? Myslím si, že jediné opravdu smysluplné řešení je průzkum bojem, kdy vám někdo zkušenější ukáže, co a jak. Ovšem kde pořád brát ty zkušenější lidi, to netuším.

Tenhle problém, myslím tu objemnost a horizontální rozplizlost, měl asi vyřešit .NET, a částečně se mu to i podařilo. Ovšem s každou další verzí .NET, přibývá jmenných prostorů a tříd a metod a jazykových konstrukcí .NET jazyků takovým tempem, že po pěti letech jsme se dostali skoro do stejné situace, v jaké jsme byli předtím: Vím jistě, že na tohle bude v .NET nějaká třída. Ale kde, proboha? A tak si programátoři znovu a znovu píší jednoduchá řešení složitých problémů, které už dávno někdo robustně vyřešil, jen o tom nikdo neví.

V každém případě: Windows je jeden z nejúžasnějších inženýrských projektů na světě. Ať už je to s jejich použitelností v jednotlivých verzích jak chce, tohle se jim upřít nedá. Při rozsahu, který mají, je vůbec div, že je ještě Microsoft dokáže udržovat, a občas dokonce i dál vyvíjet.

Představuji si, jak za milión let archeologové vyhrabou někde v místech, kde je dneska Seattle, server se zdrojovými kódy Windows, a vystaví je v muzeu, a děti se na to budou muset chodit dívat, a paní učitelky budou říkat Tady děti vidíte, kolik úsilí lidé dokázali vyvinout, když šlo o předměty sloužící nějakým tajemným divošským rituálům, a děti budou znuděně lepit na vitrínu žvýkačky a těšit se, až se na ty lidi půjdou podívat do zoo, a budou po nich házet kamínky a dělat na ně obličeje.

Děti už jsou prostě takové.

Na plný koule

Začněme něčím jednoduchým. Třeba rockem. Víte, popravdě kytarovky nemám rád. Přijdou mi nudné a tak nějak si myslím, že ty za roky, co je elektrická kytara s námi, už byly všechny kombinace akordů vyzkoušeny, a přijít s něčím novým je vlastně nemožné, a upřímně: jen lidé slabí duchem by mohli chtít poslouchat pořád dokola to samé (ach, když tohle naprosto vážně říkám ve společnosti, kde se seriózně diskutuje o rockové hudbě, některým lidem povážlivě roste tlak...). Navíc je pravda, že většina těchhle rockerů nemá žádné hudební vzdělání, kromě toho, že nedokáží hrát na žádný hudební nástroj, neumí často ani zpívat a tak dále a tak podobně.

Přesto, přiznávám, i já mám některé rockové desky rád. Třeba Angel Dust, nebo Proud Like a God nebo Hybrid Theory (ano, jistě, nu-metal, ale proto používám raději výrazu kytarovky, než rock) a tak dále a tak podobně. Prostě: drtivá většina toho, co z rocku snesu jsou první, nebo skoro-první desky (takové ty první, kde členové skupiny umí už alespoň trochu mačkat akordy).

Druhá skupina rockových nahrávek které docela dobře snáším, patří do kategorie art rock (nebo progressive rock, nebo jak se to jmenuje). Sem tam něco do Pink Floyd, skoro celý Marillion, jistě, Queen, dokonce i Enchant (i když od těch znám jen první dvě alba, tak snad hrají pořád to samé). Čili: takový ten rock, který hrají lidé, kteří už umí trochu hrát, místy je ta hudba až k hranici absurdity překombinovaná a přeplněná vším možným, nicméně pořád je dost zajímavá na to, aby se dal poslouchat.

Jistě jste si všimli toho vzoru: buď našlapané první desky, kde pár (nejlépe mladých lidí) ze sebe vychrlí něco úžasně nabitého energií (ano, někdy jsou klišé opravdu nejlepším popisem reality), nebo mimořádně rafinovaně promyšlené útvary, které obsahují tolik materiálu, že i po několikerém poslechu pořád slyšíte něco nového, zábavného, zajímavého.

Problém je v tom, že většina těch mladých a nabitých se rychle změní na mladé a vybité, a pokud nemají dost soudnosti tak i na, nemůžu odolat, mladé a vyblité. Takových muzikantů, co dokáží udržet dlouhodobě vysokou úroveň produkce je málo, a čím déle si to odmítají přiznat, tím jsou trapnější (protože Olympic je kachna na vejcích, zmíním třeba U2).

Tak a teď k tomu na co čekáte: tohle všechno samozřejmě má nějak ilustrovat situaci kolem software. Je to přeci zřejmé: Jsou firmy a projekty, které jsou mladé, dravé a tak dále, pak je pár vyjmečných, kteří dokáží inspirovat celé roky a desetiletí, no a nakonec jsou tu ti nudní, kteří ať se snaží jak se snaží, pořád z nich leze jen průměrný rádiový popík s elektrickou kytarou.

Samozřejmě, že bych teď mohl volně permutovat jména firem a přiřazovat je do libovolných skupin, a tak dále. Ale jistě uznáte, že by to bylo zbytečné. Navíc jsem spíš chtěl říct něco v tom smyslu, že je to vážně zajímavé, že každý z těch úžasných a odvážných start-upů, které se povedou jen proto, že někdo je dost mladý a pitomý na to, aby si neuvědomil, že cíl, který si dal, je prostě nesplnitelný, mají vlastně jen dvě cesty: buď se změní na ty nudné, nebo prokáží, že mají na to být těmi inspirativními.

A uznejte, že vyjmenovat tři firmy, které se pohybují v softwarovém průmyslu, a lze je bez obav prohlásit za dlouhodobé tahouny, je vážný problém. Nakonec se všichni vydají buď cestou Microsoftu, a utopí se ve vlastním úspěchu (třeba Google tohle skvěle dokumentuje, protože teď už víme nač se dívat), nebo skončí jako Nullsoft. (Samozřejmě pokud se neztratí z povědomí ještě dřív, než se do něj vůbec stačí dostat.)

Nicméně: Tuhle jsem četl, že Facebook má hodnotu (pokud to správně počítám) srovnatelnou se státním rozpočtem České Republiky (plus mínus pár stovek miliard v těchhle počtech nic neznamená), ale že ho Mark Zuckerberg stejně nechce prodat, a že cenu šroubuje výš a výš, až se dostává na částky, které nikdo nikdy nezaplatí, a o kterých ví, že jsou praštěné.

Víte, asi rozumím proč to dělá. Podle mě chápe, že je lepší nechat srdce v projektu, po kterém sice možná za pár let ani pes neštěkne, ale bude to všechno jen a jen jeho zásluha, než se stát korporátním droidem a vidět, jak jiní lidé z jeho úžasného projektu dělají projekt, po kterém za pár let ani pes neštěkne. Web 2.0 se, stejně jako rock, hraje koulema, a ty má Zuckerberg jak dva kokosové ořechy.

A proto ho také chce, podle mého, koupit Microsoft. Microsoft (resp. Bill Gates) měl taky koule až ke kolenům -- jak jinak by z podniku o dvou lidech živořících někde v motelu v Albuquerque vybudoval největší softwarovou firmu na světě -- ale jak už to tak bývá, v současné době, byť má nejlepší lidi na vývoj software na světě, patří přesně k tomu druhu nudných popíkářů, které sice celý den posloucháte v rádiu, ale právě proto je upřímně nenávidíte.

Jenže aby si Microsoft koupil Facebook, to je jako by si Rolling Stones chtěli koupit nějakou garážovou kapelu s tááákovýmle drive, a mysleli si, že když je zavřou do kumbálu vedle studia, že něco z jejich šťávy přejde na ně.

Takže. Chtěl jsem říct asi toto: Software sice není rock, ale zatraceně, někdy to tak skoro vypadá.

Plus C++

Nedávno jsem teď četl tenhle text Bjarne Stroustrupa: Evolving a language in and for the real world: C++ 1991-2006. Ach, pro neznalé: Stroustrup je ten člověk, který rozšířil jazyk C o třídy a všechny ty další objektově orientované vymyšlenosti a další doplňky jako jsou šablony a tak dále. Tím způsobil malou revoluci v programování, protože z objektově orientovaných jazyků, které do té doby byly převážně záležitostí akademického světa (Smalltalk, Eiffel a další, které to nikam nedotáhly), udělal něco, co mohly vzít ty hordy zkormoucených programátorů v C a zanést díky tomu do svých programů o dva řády více složitosti (samozřejmě, že časem se i programátoři v C naučili co to vlastně znamená ten objektově orientovaný přístup, ale i tak: znám některé lidi, kteří nikdy v C++ nenapsali jinou než statickou metodu a atribut.)

Nuže, v tom textu Stroustrup shrnuje jak se vyvíjel jazyk C++, co byly jeho hlavní cíle při jeho návrhu, jak se zformovala standardizační skupina ISO, kdo přišel z nechutným bastardem Embedded C++, jak je těžké se na něčem dohodnout, že STL neznamená Standard Template Library, protože Stepanov na STL pracoval dávno před tím, než v C++ existovala věc, které se říká template (neboli šablona; v tomto směru doporučuji rozhovor s Alexem Stepanovem Al Stevens Interviews Alex Stepanov) a tak dále a tak podobně.

Je to vážně moc zajímavé čtení a pokud programujete (jedno v jakém jazyce), rozhodně si ten text přečtěte, abyste příště, až budete mít chuť pomlouvat C++ nevypadali jako... no, jako někdo, kdo o něm nic neví.

Takže: chtěl jsem říct, že jsem pod dojmem tohoto textu tak trochu přemýšlel o C++. Jako ostatně každý soudný člověk, mám z C++ strach. C++ je krutý a syrový jazyk, který neodpouští chyby, a kdo není obdařen železnou disciplínou, která mu zabrání dělat cokoliv v rozporu s pravidly, toho rozdrtí, zašlape do země, poplive a nakonec se na jeho ostatky -- no, nechal jsem se unést, ale asi chápete co chci říct. Stroustrup přiznává, že jeho snahou nebylo znemožnit programátorů stát se svými vlastními oběťmi. (Oproti tomu designeři C# se vyznávají z opačného přístupu: C++ and the Pit Of Despair.) Stroustrup chtěl jazyk tak mocný, že umožní až bizarní úrověň abstrakce, ale přitom programy v něm napsané poběží stejně rychle, ne-li rychleji než ty v C.

Věru, to se mu povedlo. Nicméně cenou za to je, že spousta z nás, nedomrlých programátorských wannabes, si, jsme-li vyzbrojeni C++, dříve či později ustřelí nohu, nebo nějakou jinou, možná ještě důležitější, část těla.

Proto jsem si myslel, že čas C++ pomalu končí, že až vymře těch pár dědků s táákovýmihle fousy, kteří udržují v chodu existující aplikace, celý svět se prozáří, a všichni budeme rázem programovat jen a pouze pro garbage collected jazyky, které generují nějaký ten byte code pro virtuální stroje jako je Java Virtual Machine, nebo Common Language Runtime.

Samozřejmě, že to byla hloupá představa.

Problém je v tom, že nějaký ten mikroprocesor je součástí skoro každého zařízení, které koupíte ve vašem oblíbeném (internetovém) obchodě s elektronikou. A jelikož to zhusta jsou málo výkonné procesory, je potřeba psát pro ně v jazyce, který je hardwarovému modelu takového procesoru co nejblíže. A takovým jazykem je právě C++. C++ přistupuje k paměti se stejnou nenuceností jako C, ale přitom se v něm dá vyvíjet na rozumné úrovni abstrakce, takže výsledný program může být hotov rychle a dá se udržovat.

Samostatnou kapitolou pak jsou různé tyhle PDA, nebo chytré telefony. Čert vem PDA -- těm už vážně odzvonilo (jejich prodej opět poklesl o 40%), ale za pár let budou všechny telefony chytré, protože to bude lacinější, mít jen jednu základní desku (resp. její zapojení) pro celou modelovou řadu, a na každém telefonu poběží nějaký ten operační systém (ať už Symbian, nějaký ten klon Linuxu, nebo Windows Mobile, či jak se to vlastně bude za tři roky jmenovat), a pro ten bude potřeba vyvíjet aplikace v jazyce, který bude co nejblíže hardwaru.

Říkáte si: blbost, za pár let bude v každém telefonu Java, a po C++ nikdo ani nevzdechne. Myslím, že ne. Svůj odpor ke snobské společnosti Apple jsem tu vyjádřil tolikrát, že to už ani není zajímavé, ale přesto nemohu Apple upřít, že iPhone to bere v zásadě za správný konec. Mám na mysli tohle: co jsem tak četl, iPhone disponuje dlouhou výdrží baterie, což je jistě vlastnost, kterou každý rozumný člověk od podobného zařízení očekává, nicméně málokdy jsou jeho oprávněná očekávání naplněna.

Aby baterie vydržela dlouho, a přitom telefon mohl dělat všechny ty cool věci, které od něj očekáváme, má jeho výrobce v zásadě jedinou možnost: snížit spotřebu procesoru a pamětí (nebo displeje, ale displej je to, co dnes odlišuje jednotlivé třídy telefonů, takže pro high-end modely s ním nejde moc dělat). V tomto směru jsou tu dvě možnosti: zaprvé do telefonu strčit pro některé, na procesorový čas náročné operace, speciální obvod (jako je v iPhone hardwarový dekodér videa). To je ovšem drahé a pro low-end se to nehodí (na méně movité zákazníky s telefonem za 500USD dojem neuděláte), navíc speciální čip bude vysávat baterii. Nebo můžete do přístroje strčit pomalejší a úspornější procesor, který bude mít k dispozici méně paměti, a operační systém a aplikace napíšete tak, aby z takového hardware vyždímaly co se dá. A tady se zase vracíme k C++.

Čili, ať děláte co děláte, programování na úrovni (resp. rozsahu úrovní), kterou poskytuje C++ se nevyhneme ani v nejbližších několika letech.

Řikáte si: ale já kašlu na nějaký chytrý mobil. Mám své PC (od libovolného výrobce) a tam je výkonu taková přehršel, že se o nějakých pár usmolených wattů starat nemusím. Ohó, říkám já, to se tedy pletete.

Pomalu začíná docházet k tomu, po čem toužím už několik let: aby PC žraly (nedá se to říct jinak) méně. Počítače se zvolna začínají učit šetřit energií, a jak její cena poroste, a jak se na trhu budou stále více prosazovat mobilní PC (notebooky a to, v co se časem přemění TabletPC nebo UMPC), bude zase potřeba být s to využít výkon který je k dispozici co nejúčelněji.

.NET sice umí předkompilovat strojový kód svého virtuálního stroje do nativního kódu procesoru na kterém běží, a asi v tom je i docela dobrý, ale poctivá kompilace C++ programu nastavená na rychlost (nebo na velikost) je něco, s čím se dá asi při Just In Time kompilaci jen těžko bojovat.

Jsem první, kdo řekne: čert vem 15% výkonu, hlavně že tu aplikaci napíšu rychle, půjde udržovat, a využije konzistentního frameworku, ale firmy, které vyrábějí výpočetně a paměťově intenzivní software (třeba ty navigační programy, o kterých jsem tu tuhle mluvil), ví své. Každých pár kilobytů paměti se počítá, každé procento na rychlosti běhu se u zákazníků počítá.

Závěrem: Tak se stalo, že jsem se z odmítače C++ stal ostražitým sledovačem, který bude vývoj tohoto jazyka, který jsem už považoval za mrtvý (v smyslu, v jakém je mrtvá Latina), bude pečlivě sledovat. Protože jak tuhle řekl BVer: správný programátor udržuje svou bedničku s nářadím vybavenou a připravenou.

To neprojde...

Taková malinkatá celebritka mezi .NET vývojáři Jeff Atwood se rozhodl, že si na svůj blog vpustí reklamu a zisky z ní utratí na sponzorování open source (OSS) projektů vyvinutých pro .NET (viz Supporting Open Source Projects in the Microsoft Ecosystem. Vcelku nic moc zajímavého.

Zajímavé jsou ale některé komentáře pod jeho textem. Třeba ten od Franse Bouma:

In fact, the whole MS platform eco system isn't suitable for open source tools to become very effective. As soon as they do, MS will come with an equivalent, and what's worse: large droves of developers don't even know how to spell open source, left alone that they're even looking for open source projects, they simply look at Redmond and wait till MS comes with something.

In the Java community, things are completely the opposite. The whole eco-system around Java is simply build on top of the open source model: libraries and tools are very often free and open source. The business model of java oriented companies is build around providing services, not by selling licenses. On the MS platform this is the opposite.

Vcelku s tímto popisem situace souhlasím. Také používám (soukromě i pracovně) několik OSS produktů, jako je třeba MbUnit (na kterou jsem přešel z NUnit, protože MbUnit má spoustu sexy vlastností, které NUnit nemá), nebo ZedGraph (vážně lepší než drtivá většina placených komponet pro kreslení grafů, distribuovaná pod LGPL), nebo #ziplib (a asi i další).

Nicméně je fakt, že většina těchto komponent dříve nebo později dojde do situace, kdy si Microsoft všimne, že mu někdo loupe perníček, a buď si koupí (rozuměj zaměstná) přímo vývojáře té které komponenty, nebo vymyslí něco vlastního, skoro stejného, ale ne tak úplně kompatibilního, a přibalí to k Visual Studiu, nebo to vydá jako nějakou zdarma stažitelnou komponentu, na což vývojáři většinou reagují tak, že převedou své aplikace na věci od Microsoftu. Podívejte, jak nepotřebné jsou k Visual Studiu přibalené Crystal Reports od doby, kdy Microsoft distribuuje svůj vlastní ReportViewer (pro jednoduché reporty, samozřejmě).

Já to Microsoftu nezazlívám: je to firma, jejímž cílem je znásobovat investice do ní vložené, která potřebuje růst na trhy na kterých zatím není a tak dále. Microsoft je trochu jako hypermarket: všechno co potřebujete byste měli najít pod jednous třechou, aby vás ani nenapadlo dívat se jinam. Na druhou stranu se pak nemůže nikdo divit, že některé lidi takový přístup znechutí, a že začnou raději věnovat něčamu jinému než je .NET. Něčemu, co jim přinese nehynoucí slávu a uznání, a ne jen temný kout v domě zapomnění.

Říkám si: v čem je ten rozdíl, mezi vývojáři opravdového OSS, kteří se věnují Javě, nebo Ruby, nebo něčemu podobně zajímavému, a vývojáři kteří se spokojeně rochní v teplé náruči Microsoftu?

Napadlo mě tohle: zatímco všichni ti opravdoví OSS vývojáři tělem i duší, sní o tom, že jejich produkt (jeden z mnoha ve stejné kategorii na Sourceforge) napraví svět a tak dále, a že když budou dost dobří, tak je nakonec zaměstná Google nebo nějaká podobně trendy firma, snem vývojářů pro Windows (nebo platformy Microsotu obecně) je opustit řeholi zaměstnání, stát se nejprve MicroISV a pak třeba i regulérním ISV (tedy že naberou zaměstnance, kteří budou makat za ně). Rozdíl je totiž v tom, že zatímco pro osvědčené OSS platformy (Linux, Java, atp.) jsou věci zadarmo, pro ty, co se tak či onak spolčili s Microsoftem je naopak normální za věci platit. Takže stačí, když vyvinete nějakou sadu dostatečně kulatých a gradientních tlačítek, vyrobíte si stránku, zaspamujete pár diskusních fór (nebo nabídnete svůj "produkt" pro nekomerční využití zdarma), a díky té mase vývojářů se docela slušně uživíte.

Jistě OSS produkty se živí službami. Ale množství počátečního kapitálu a výše rizika pro zaběhnutí produktu založeného na službě jsou úplně jinde než u balíku ovládacích prvků, který lze vyvinout poměrně dobře i u práce (dokonce i když máte rodinu) a riziko je vcelku nulové.

Chci tím říct: myslím si, že lidem, kteří obcují s produkty Microsoftu současný stav vcelku vyhovuje. Dává jim totiž naději, že jednoho dne budou pracovat na svém, a že zvyk Microsoftích nohsledů nakupovat licence, jim umožní zbavit se jha práce pro někoho jiného. To, že v okamžiku, kdy se stanou příliš úspěšnými, vrhne Microsoft na stejné pole několik set ze svých tisíců vývojářů, kteří je o jejich malý kšeft zase připraví, je nevzrušuje, protože se ukájejí tím, co tvrdí Paul Graham a Tim O'Reilly: totiž že jsou pod radarem, že na ně není vidět, že jim se něco takového prostě nemůže stát.

Proto si myslím, že podporovat finančně OSS projekty pro .NET je jen takové plácnutí do vody, které stejně nikam nepovede. Aby to bylo k něčemu, musel by se změnit přístup Microsoftu, a to se nestane, protože Microsoft potřebuje růst a nemůže si dovolit, aby místo, kam by se mohl natlačit on sám, zabírala nějaká pochybná skupinka předstírající filantropii, či co.

Tak tohle mě napadlo.

WT^hPF

Tak. Tímto textem bych chtěl na nějakou dobu uzavřít diskusi o Microsoftu, Apple a podobných věcech.

Když teď nedávno Microsoft přejmenoval WPF/E na Silverlight, a všichni bloggeři se kolem této události začali rojit s tím, jestli Silverlight převálcuje Flash nebo ne, také jsem cítil potřebu se k tomu nějak vyjádřit. Nakonec jsem se rozhodl to neudělat, protože je podle mě na nějaké hodnocení brzo. Jednak Microsoft chystá ještě nějaké šokantní oznámení (bude Silverlight open-source? Tak ta velká novina je platformě nezávislá implementace CLR pro prohlížeče.), jednak mě vývoj webových aplikací tak úplně nezajímá. (Nicméně jsem chtěl poznamenat, že už delší dobu si myslím, že Apollo je ten Next Big Language, o kterém mluví Steve Yegge. Beru zpět. Teď myslím, že myslel JavaFX.)

Nicméně jsem se chtěl otřít o WPF, kterou se teď snažím nějak sestudovat (samozřejmě to jde pomalu, ale snažím se). Takže co je to WPF? Windows Presentation Foundation. (Pokud jde o mě, klidně bych celou tu věc pojmenoval Avalon i oficiálně, ne jen krycím jménem, ale jak známo, pojmenovávání věcí v Microsoftu je sofistikovaný proces, který vyústí v použití slova Microsoft nebo Windows v názvu, ať to zní jakkoliv pitomě -- tedy kromě sady programů Expression, které se, nějakým záhadným způsobem, tomuto jevu vyhnuly.) Pokud jste tenhle pojem ještě neslyšeli, určitě si přečtěte článek Windows Vista: more than just a pretty face, který poskytuje velmi slušný úvod do problematiky.

Takže ještě jednou: co je to WPF? Podívejte, všichni víme, že GDI(+), je zastaralá záležitost, že ji Microsoft držel při životě především proto, že si nechtěl utnout kus trhu s kancelářskými počítači, ve kterých ještě donedávna byly opravdu hloupé integrované grafické čipy, které neuměly nic, než převést kus operační paměti na analogové úrovně na D-SUB konektoru. Ovšem, doba se změnila, a i ten nejhorší integrovaný grafický čip dneska disponuje nějakou tou 2D/3D akcelerací, kterou je velká škoda nevyužít.

Takže se Microsoft rozhodl, že ve Windows Vista, bude 3D akcelerace tak nějak vyžadována, a že na ní bude postaveno celé zobrazování systému. A jelikož perspektivním vývojovým prostředím je .NET, vznikl .NET Framework 3.0 (který by ve skutečnosti spíše měl mít číslo 2.5, ale přeci nelze nový nablýskaný operační systém distribuovat s nějakou polovičatou verzí frameworku), který obsahuje, mimo jiné, WPF.

WPF je především prostředek, jak co nejvíce oddělit uživatelské rozhraní aplikace od výkonného kódu, a to tak, že uživatelské rozhraní bude definováno pomocí XML, respektive jeho "dialektu" XAML, který umožňuje popsat UI do takové hloubky, že pro řadu jednoduchých aplikací opravdu není potřeba psát skoro žádný kód (vážně -- poměrně sofistikovaný textový editor vygenerujete pomocí prvku System.Windows.Controls.RichTextBox a nějaké té bižuterie, s použitím asi 50 řádků kódu, které se starají o uložení a tisk dokumentu).

Kromě onoho zřejmého požadavku na oddělení kódu a uživatelského rozhraní z důvodu znovupoužitelnosti obého, je tu ještě bonusová možnost nechat nějakého grafika pracovat na rozhraní v poměrně sofistikovaném programu Expression Blend bez toho, aby něco věděl o programování (samozřejmě musí něco vědět o aplikaci a její struktuře, ale nemusí být seznámen s její vnitřní mechanikou). Také lze takový popis uživatelského rozhraní v XAML snadno vyměnit za jiný (třeba podle velikosti displeje, zvoleného režimu funkce programu, nebo cílové platformy).

WPF tedy umožňuje rozdělit vývoj logiky programu a jeho prezentační vrsty jak je to jen možné.

Současně s tím ovšem nabízí velmi vypečený způsob jak se zbavit všech těch problémů, které vznikají se stále rostoucím rozlišením displejů (písmenka jsou příliš malá!), nebo potřeby předělávat uživatelské rozhraní pokaždé, když program lokalizujete do nového jazyka, který místo textu o šesti znacích potřebuje znaků dvacet, protože všechny souřadnice jsou relativní a při změně velikosti ovládacího prvku, nebo okna, se umí dobře přizpůsobit novým podmínkám.

Dále je tu hierarchičnost prvků uživatelského rozhraní. Ve WinForms (tedy rozhraní, které používá GDI ve Windows do verze XP bez WPF), jste museli podstoupit bolestivý proces vlastního vykreslování, když jste chtěli do tlačítka dostat obrázek nebo dva řádky textu. S WPF napíšete něco ve smyslu <tlačíko pozadí="obrázek"><popiska text="hlavní"/><popiska text="vedlejší"/></tlačíko> a je to! A samozřejmě můžete definovat co se stane, když nad tlačítkem bude myš, včetně různých animací.

Čili variabilita je o několik řádů dál, než s použitím WinForms a GDI (a to vás nechci zdržovat básněním o tom, že takové tlačítko můžete namapovat na libovolný 3D povrch, takže pak můžete vytvářet skoro stejně sexy uživatelská rozhraní jaká používají Hollywoodské trháky).

Nějaké nevýhody? Ó jistě: použití WPF znamená, že se vaše aplikace na starších počítačích (řekněme starší než tři roky) zpomalí zhruba dvakrát (především na Windows XP je to hodně znát). A dále: dokud nevyjde nové Visual Studio (kódové označení Orcas, v současné době ve stádiu Beta 1), neexistuje nějaký spolehlivý nástroj, ve kterém by se dalo s WPF pracovat. Existují sice nějaká rozšíření Visual Studia 2005, ale věřte mi, pořád bude řešit nějaká neopodstatněná varování, IntelliSense funguje jen částečně a tak dále. Expression Blend už by měl být ve stavu RTM (Release To Market), ale jde o placený nástroj, a věřte, že XAML není myšleno jako jazyk, který budete psát ručně (i když leckdy nic jiného nezbývá).

Sečteno podtrženo: WPF je skvělá věc, která ovšem pro produkční aplikaci bude zajímavá někdy v půlce příštího roku, až budou všechny nástroje připraveny a penetrace Windows Vista dosáhne nějaké smysluplné úrovně.

Kde jsem to začal? Aha, Silverlight (podmnožina WPF) versus Flash. Upřímně: když jsem se tak díval na vývoj jmenných prostorů v .NET frameworku, domnívám se, že v Microsoftu opravdu existuje nějaký grand plan, ve kterém se dříve nebo později objevuje lehkotonážní managed framework pro prohlížeče -- to znamená, že bude notně ořezaný, třeba jako Compact .NET Framework (PDA a smartphones) nebo XNA Framework (XBox 360), ale nebudete muset stahovat 60MB záplat, které vám umožní jej provozovat, který umožní vyvíjet pro prohlížeče v C#, nebo jiném .NET kompatibilním jazyku.

Jak pak bude vypadat sronání Flash/Apollo a Silverlight/.NET? Který z těchto balíků zvítězí? Myslím si, že ten, který bude nabízet více zajímavých aplikací. Pokud Google začně vyvíjet v Appolo (což by se náramě hodilo třeba pro GMail, který by mohl stažené e-maily skladovat lokálně a odesílat odpovědi až se obnoví připojení k Internetu) a bude Flash aplikace tlačit svým zákazníkům, bude pozice Microsoftu jistě mnohem horší. Pokud se něco zlomí v Microsoftu a začne vyvíjet věci dost zajímavé na to, aby uživatelé počkali těch několik sekund než se stáhne pár mega Silverlight (nebo jej budou distribuovat jako doporučenou aktualizaci Windows), není výsledek vůbec jistý.

V každém případě bude pár následujích měsíců zajímavých. Uvidíme, jestli strategie vnucování se na obsazený trh skrze Windows Microsoftu tentokrát vyjde nebo ne.

Pokud ne, má pravdu Paul Graham, a Microsoft už je opravdu mimo mísu, ať má finanční výsledky jekékoliv.

PS: A ještě bych si dovolil doporučit vaší pozornosti starší podcast s Robertem Scoblem, který přináší mnoho zajímavých poznámek k tomu, jak funguje Microsoft uvnitř.

PPS: Ta věc s grafickými kartami mi připoměla, proč je dobré mít managed framework běžící na virtuálním stroji. Představte si, že Microsoft portuje CLR (Common Language Runtime, tedy virtuální stroj, na kterém běží .NET aplikace) na grafické procesory, takže aplikace mohou běžet paralelně nejen na hlavním procesoru (procesorech) vašeho počítače, ale i, na jinak zahálejícím, GPU...

Trocha poctivé demagogie

Takže další kolo. (Než se pustíte do dalšího čtení, doporučuji vaší pozornosti poměrně zajímavý komentář uživatele Q, který jste třeba přehlédli.)

Problém s celou věcí je v tom, že naprostá většina lidí se otázkám, v nichž nějak figuruje Microsoft, nedokáže vyhnout zpolitizování věci, a tak, místo abychom se tu bavili o tom, jak obecně přistupovat k podobnému druhu chyb, kterým se někdy prostě nedá vyhnout, a může se s nimi setkat každý vývojář, řešíme nějaké zbytečné spory ve smyslu katedrála vs bazar, uzavřený vs otevřený, Microsoft vs Samba. Uznávám, mám na tom svůj díl viny, protože jsem si nedokázal odpustit trochu té infantilní jedovatosti (a protože je mi bližší Joel Spolsky než Paul Graham, jsem nutně vychýlený na stranu -- jak to bylo? -- jedné dominantní firmy).

Co mě osobně na celém problému nejvíce zaujalo, je to hledání metody, jak s podobnou chybou naložit. Upřímně řečeno -- nevím. Myslím si, že uživatelé mají právo na zpětnou kompatibilitu, současně ale souhlasím s tím, že zrychlení operací FindFirstFile, FindNextFile je žádoucí, a že po něm korporátní zákaznící Microsoftu touží, a neměli by o něj být připraveni. Myslím, že není správné vyhazovat message box u takových operací jako je vylistování obsahu adresáře, ale přitom chápu, že spamování error logu není řešením pro domácí uživatele, kteří najednou neuvidí své soubory, a kteří nevědí (a nechtějí vědět) nic o tom, co je to nějaká Samba, nebo jakým způsobem Explorer zjistí které soubory jsou ve kterém adresáři. Souhlasím s tím, že nejlepším řešením je opravit instalace vadné Samby, ale nejsem si úplně jistý, jestli je to realizovatelný požadavek u jednoúčelových fileserverů, které firmy (s Linuxem ve ROM/flash paměti) chrlí po desítkách tisíců.

Jak říkám -- nevím jak takovou situaci řešit. Proto mě celý problém zaujal, protože jsem si myslel (a pořád si to myslím), že se dovím, jak se v takové situaci zachovají (ať už se to někomu líbí nebo ne) ti nejlepší programátoři a softwaroví obchodníci na planetě.

Pokud jde o to, jestli samba-team musel nebo nemusel reverzně inženýrovat (ha!) protokoly Microsoftu: Microsoft má svaté právo nechat si své protokoly pro sebe. Nejsem tak kovaný v historii operačních systémů, abych to mohl říct určitě, ale domnívám se, že snahou MSFT v době, kdy "SMB" vznikalo, bylo primárním úkolem zlikvidovat konkurenci ztělesňovanou firmou Novell. Myslím si, že v té době, nikdo nezveřejňoval specifikace svých protokolů, protože se to prostě nedělalo, a jejich utajení a vzájemná nekompatibilita byly považovány za konkurenční výhodu (jako tomu donedávna bylo -- a leckde stále ještě je -- u instant messaging aplikací a protokolů). Od těch blažených devadesátých let se lecos změnilo, a dnes se naopak protokoly zveřejňují a velké firmy se stávají členy konsorcií, kde se protokoly a formáty domlouvají ke všeobecné nespokojenosti. Je to jako s programováním -- od rigidního stylu vše bude naplánováno, pak implementováno, nakonec otestováno, a co si zákazník nevymyslí hned zkraje, to mít nebude se postupně přechází k extrémnímu programování, které říká neplánujte nic, napište pár testů a uvidíte co z toho vzejde.

Stejně jako se za těch deset patnáct let změnila představa ideálního programovacího stylu, změnila se i představa ideálního přístupu k protokolům. Dříve nepředstavitelné zveřejňování obchodních tajemství se dnes stalo všeobecným standardem, a firmy sázejí víc na to, že nabídnou synergické řešení všech problémů, které bude zákazníky demotivovat od nákupu produktů konkurence (pravým důvodem proč používat Outlook není příjem pošty, ale propojení s Exchangem a zbytkem balíku Microsoft Office, důvodem proč nepoužívat OpenOffice.org není těch 1397 funkcí, které má Excel navíc, ale absence návaznosti na Exchange a další produkty Microsoftu).

Abych to shrnul: Vývojáři Samby v diskusi pod Chenovými příspěvky sami přiznali, že chyba nevznikla proto, že by neznali protokoly Microsoftu (který je prý už docela obstojně dokumentuje a s týmem Samby snad i spolupracuje), ale proto, že prostě udělali normální stupidní chybu (nějaký ten zapomenutý case ve příkazu switch()). Údajně zabrala oprava chyby (včetně testování) asi tři minuty. (Což mi připomíná, že, pokud jsem to správně pochopil, problém není v tom, že by listování adresáře nevyhodilo chybu. Problém je v tom, že ji vyhodí i když nemá!)

Blog Old New Thing se problémem zpětné kompatibility zabývá poměrně často. I proto ho čtu -- protože mi stále připomíná, že opravit chybu někdy nestačí...

Hlas z druhého břehu

Tento BVerův text se objevil pod přispěvkem Malinkatá chybička. Myslím, že si že zaslouží širší pozornost, takže jsem z něj udělal příspěvek. --objektivní editor-- (alias jIRI)

Jsa vhozen do jedné škatule k militantním linuxářům, nemám jinou možnost než na tento emocemi nabitý post odpovědět. Konečně, Festivalu už by po čase prospěl nějaký slušný flamewar, tak rád plním jIRImu jeho nevyslovené přání :-)

Předně: v dané kauze vystupuje všemi dlouho očekávaný operační systém od dominantní firmy na jedné straně a souborový server, jenž je k dispozici zdarma se zdrojovými kódy, na straně druhé. Dále je třeba zmínit, že oné dominantní firmě už samotná existence serverového projektu vadí -- tento software umožňuje běžným uživatelům přistupovat ze stanic vybavených operačním systémem dominantní firmy k souborům uloženým na jiných systémech (zvláště pak k souborům těch operačních systémů, které dominantní firma považuje za svoji hrozbu). Daný souborový server tím podstatně zvyšuje použitelnost a užitnou hodnotu konkurenčních systémů a dovoluje tak vzájemné soužití různých OS na jedné lokální síti a tím původně dokonalou dominanci firmy narušuje. Pro úplnost je ještě třeba zmínit, že dominantní firma detaily svých síťových protokolů původně nezveřejnila, takže serverový projekt vznikl na základě zpětného inženýrství a neúplných informací o chování a analýzou síťového provozu klientů dominantního výrobce.

Řekl bych, že toto uspořádání věcí situaci značně komplikuje, protože původně ryze technický problém je posouván do roviny obchodní, filozofické, až nábožensky fundamentalistické.

Pokusím se od vyšších rovin oprostit a hodnotit otázku na ryze systémové úrovni:

Každá jednotlivá komponenta tak komplikované věci, jakou je (jakýkoliv) operační systém, by měla dělat svoji práci v rámci celku čistě, jednoduše, logicky a bez zbytečných vedlejších předpokladů. Pokud tomu tak není, je její chování komplikované, pro ostatní komponenty obtížně předvídatelné a hůře abstrahovatelné -- bezprostřední okolí, které s komponentou komunikuje, se musí jejímu chování přizpůsobovat a to vede ke zbytečným složitostem a dalším nadbytečným předpokladům. Každá složitost pak zvyšuje šance zákeřných chyb a zhoršuje efektivitu (rychlost a paměťovou náročnost). Snahou architektů je tak samozřejmě udržet systém na všech úrovních co nejjednodušší. Proto například jedno z navrhovaných řešení "systém se postará sám o chybové hlášení k směrem k uživateli a zobrazí dialog s varováním" je vadné -- síťový subsystém by tak musel mít těsné vazby na nějaký zobrazovač událostí (jenž je zodpovědný za zobrazování GUI hlášek v daném rozlišení, barvách, jazyce, atd...) a tato vazba může být zdrojem komplikací, protože cílem síťového subsystému je být efektivní a cílem zobrazovacího subsystému je být komfortní. Je evidentní, že síťová komponenta OS má problém detekovat, obejít, hlásit a zaznamenat tuto událost co nejjednodušším zůsobem (např. návratovou hodnotou volání, zápisem do systémového logu, atd.), je pak pouze a jen věcí aplikace, jestli a jakým způsobem varování prezentuje. Tedy: model toho, jak se zachovat, je plně v kompetenci softwarové vrstvy NAD síťovou komponentou OS, tedy konkrétně souborového prohlížeče. (Poznámka na okraj: Je smutné, že i technicky orientovaní lidé už dnes nedokážou rozlišovat mezi operačním systémem a jeho aplikacemi -- slíbil jsem ale, že se nyní budu držet ryze technických aspektů, takže nechci toto téma rozvíjet.)

Tolik tedy k tomu, proč "podobné workaroundy jsou cestou do pekel, a že jakékoliv jiné řešení než to "čisté" zalogování a vrácení chyby, je projevem opravdového zla", doufám, že je jasné, proč a z jakých důvodů hájím toto stanovisko.

Nyní k vyšším úrovním problému: Operační systém je v konečném důsledku komerční produkt a jako takový vzniká díky značnému úsilí technického a obchodního týmu. Obchodníci stanovují priority, celkové zaměření, look´n´feel celého produktu, měli by dobře znát cílovou skupinu zákazníků, atd. V reálném světě jsou pak požadavky dané obchodním týmem často v rozporu s prioritami technickými -- v daném případě je obchodním požadavkem zpětná kompatibilita: síťové aplikace musí fungovat úplně stejně jako na předchozí verzi operačního systému, jenž je ale zcela technicky odlišný od vyvíjeného systému. Podobný požadavek, je-li prosazen, vede k tomu, že v nenarozeném dítěti vzniká slepé střevo (bug v serverovém projektu byl už odstraněn a za několik měsíců bude workaround v OS úplně nepotřebný, zatímco OS bude udržován dlouhou řadu let, je mylné předpokládat, že uživatelé budou vadnou verzi serveru používat dlouhodobě třeba kvůli firmware v ROM). Stručně řečeno, má být odstraněna jen původní chyba a na místě, kde vznikla.

Vybalancování technických a obchodních požadavků je nelehkým úkolem hlavních šéfů -- jen oni rozhodují o tom, zda je důležitější mít technicky dokonalý OS s drobným nekomfortem, jenž časem donuti určité procento správců serverů k upgradu, nebo to, aby současní zákazníci měli snadný přechod na operační systém, jenž je vnitřně zaneřáděn od samého začátku.

Celková politika dominantní firmy je dlouhodobě zvýhodňovat obchodní priority před technickými -- jen tak dosáhla své dominance. Tato jistě úspěšná strategie nicméně vysvětluje i fakt, proč technické parametry produktů, APIs a protokolů oné dominantní firmy jsou vždy podřízeny momentálním krátkodobým trendům, proč jsou výrobky uváděny na trh se zpožděním a proč je jejich údržba často problematická.

Tímto se dostávám k předposlednímu argumentu (pokrytectví a "dělání blbců" z uživatelů): každá úspěšná firma musí pracovat s modelem zákazníka. Obchodníci operují s tvrzeními typu "tohle uživatel snese, tohle už ne", "tohle je intuitivní, tohle už ne", "tohle vypadá jako naše chyba, to není přípustné", apod. Myslím si, že model uživatele, s nímž pracuje dominantní firma, je (zbytečně) vychýlen směrem k podprůměrnému uživateli s nižším IQ. Je to logické -- lidé, kteří konktaktují uživatelskou podporu, většinou k této skupině patří a je tak výhodné ušetřit náklady, pokud jich bude co nejméně. Ona podceňovaná "mlčící většina" je ale v průměru mnohem šikovnější a schopnější, než by dominantní firma byla ochotna připustit. Což je mimo jiné i důvod, proč vůbec vznikají a jsou velmi populární projekty jako je síťový souborový systém postavený na protokolech dominantní firmy.

Tak.

Doufám, že jsem aspoň částečně vysvětlil své "svaté pravdy", které byly autorem vyjmuty z kontextu naší dlouhotrvající diskuse a lehce osprejovány narudo.

A teď si neodpustím ti tu trošku demagogie, jIRI, vrátit ve formě malé podpásovky. Jen tak dál, časem si snad opravdu nainstaluješ nějakou šikovnou linuxovou distribuci, staneš se jejím spokojeným a nakonec i pokročilým uživatelem a budeš tak schopen posuzovat a hodnotit věci i "z druhého břehu".

Kdyby totiž platil tvůj omyl, že "Linux nemá zákazníky", neuvažovali by tvůrci Visty o podpoře staré verze Samby -- nebo snad ano?

Malinkatá chybička

Příspěvek How would you solve this compatibility problem: Network interoperability (Old New Thing) si určitě přečtěte. Je zajímavé, jak takový vcelku banální problém dokáže přesně rozdělit lidi na dvě poloviny. A je zajímavé, kolik se toho o lidech dovíte z toho, na kterou stranu se přikloní.

O co jde?

Raymond Chen z Microsoftu se táže svých čtenářů, jak by řešili tento problém: file serveru se lze na seznam souborů zeptat pomalu nebo rychle. Pomalu se ptaly WindowsXP, Windows Vista se ptají rychle. Ovšem někteří betatesteři reportují podivnou chybu, kdy s některými file servery (nakonec byla v diskusi identifikována jako provinilec Samba, včetně odkazu do bugzilly) není načten celý seznam souborů, ale jen prvních 128 položek. Chyba v sambě byla zkraje roku opravena, nicméně jistě stále zůstává dost neupgradovaných instalací, při kontaktu se kterými by se Vista jevily jako pochybný operační systém, který ani nedokáže vylistovat soubory. (Poznamejme ještě, že nejde jen o problém s Windows Explorerem, ale se všemi aplikacemi, které používají API shellu k vylistování obsahu adresáře.) Čili se Chen ptá, jak mají Vista s touto chybou (která není jejich chybou, ale chybou kopírovačů, kteří Microsoft a jeho produkty tak nenávidí, až je pod hlavičkou open source kopírují) naložit.

Mají Vista chybu detekovat, zapsat informaci o ní do logu, a API vrátit chybový kód? Nebo se ji mají snažit detekovat, a před uživatelem skrýt? A tady se právě lidé rozdělují na dva neslučitelné tábory: jedni (ke kterým patří třeba BVer) se domnívají, že jediným řešením je chybu ohlásit a nechat uživatele/administrátory ať si nainstalují novou verzi Samby. Druzí (do této skupiny patřím já) si myslí, že je nepředstavitelné, aby operační systém, který používá zhruba 500 miliónů lidí, najednou přestal fungovat tak, jak tito lidé očekávají.

BVer mi v naší vášnivé diskusi na toto téma vysvětloval, že podobné workaroundy jsou cestou do pekel, a že jakékoliv jiné řešení než to "čisté" zalogování a vrácení chyby, je projevem opravdového zla. Já si na druhou stranu myslím, že pro Microsoft, který už tak všichni upřímně nesnáší, je nepřijatelné to, že za drahé peníze vnutí svým zákazníkům nový operační systém (kvůli kterému budou muset upgradovat hardware, přistoupit na licenční podmínky, které určitě budou výhodnější než ty současné -- výhodnější pro Microsoft, atd.), a ten pak nebude fungovat.

BVer dštil oheň a síru na snahu Microsoftu "vypadat dobře", a že z uživatelů dělá blbce. Já tomu ale rozumím: když nějaká firma utratí řekněme půl milionu dolarů za upgrade na Vistu, má za své peníze určitá očekávání. Jedním z nich je, že to co fungovalo, bude fungovat bez problémů dál.

Vidím tu ten propastný rozdíl mezi uvažováním lidí od Linuxu a lidí od Windows: Linux nemá zákazníky a není zákaznicky orientovaným softwarem. Windows naproti tomu jsou komerční produkt, který se musí prodávat, aby obhájil svou existenci.

Militantní Linuxáři vám řeknou: Pokud ti Linux příjde složitý, jsi debil, který si ho stejně nezaslouží. Podlézavý Microsoft vám nabídne slevu (kterou samozřejmě nechce zadarmo).

Linuxáři hají svou svatou pravdu s otevřeným kódem. Microsoft chce všechny peníze, které jste mu schopni dát.

Co mají oba tábory společné, je ta zarputilá tvrdohlavost, se kterou jdou za svým...

PS: Kauza pokračuje (a Chen vysvětluje, proč BVerův scénář s donucením k updatu není úplně realizovatelný). Doporučuji sledovat...

Visual Driven

Takže BVer mě svou soustavnou věrozvěsteckou činností nakonec přeci jen uvrtal do Test Driven Development. (Byly časy, kdy jsem si myslel, že je to tím, že je o nějaký ten rok starší, že vždycky přivede k něčemu zajímavému on mě, a ne já jeho. Pak jsem ale sám trochu zestárl, a zjistil jsem krutou pravdu: opravdu jsou někteří lidé chytřejší než já. Někteří o dost chytřejší [sigh].) Zatím jsem ve fázi bezbřehého nadšení, které samozřejmě časem vyprchá, až budu kvůli banální změně v interfacu třídy přepisovat dvacet testů, ale právě teď mě fakt, že se v nUnit mnění kolečka z červených na zelená, naplňuje takovým štestím, že se to snad ani nedá popsat.

S tím souvisí další téma, které jsem chtěl už delší dobu zmínit: Visual Studio 2005. Tak tedy: na první pohled skvělé. Sice mi příjde, že se vizuálním vzhledem až nebezpečně blíží Microsoft Office 2003, což je samozřejmě nepříjemné, protože, jak známo, vývojové prostředí má být tak spartánské jak to jen jde... No dobrá, podobné žvásty mě iritují u vyznavačů čistých textových editorů jakožto primárního vývojového prostředku, takže si je odpustím. (Pravda je taková, že bych těch pár pixelů, které zkonzumují barevné toolbary klidně obětoval dalším dvěma řádkům kódu, ale nešť.)

Nové (teď už ne tak moc) Visual Studio z mého pohledu (tedy z pohledu v zásadě stand-alone vývojáře, sám se řídím, sám si peru, a tak dále) nepřineslo nic až tak obrovsky úžasného. Ano, C# konečně podporuje templaty (v microsoftím newspeaku generika), ano, Class designer je moc pěkná věc, která konečně umožňuje snadné XML komentování kódu, a občas i návrh tříd (a je opravdu fajn, že se prázdná třída vygeneruje automaticky), a pak jsou tu tyhle vymoženosti v Data-bindings, a spousta nových funkcí a tříd v .NET frameworku 2, ale popravdě: je to krok spíše evoluční, než revoluční, skoro nic, co by mi dneska nemohl poskytnout produkt jako je #develop, nebo v případě C++ nějaký ten front-end nad gcc.

Jelikož pořád ještě nemáme (a dlouho mít nebudeme) WinFX, nějakému tomu importování Win32 funkcí se člověk nevyhne, nové Visual Studio padá (a to tak že často -- s VS2003 jsem žádný pád nikdy nezažil, zato hned první pokus s VS2005 skončil moc pěknou chybou, kdy neinicializovaný objekt -- po importu projektu z VS2003, kde to nevadilo -- způsobil pád form-designeru, který se, po znovuspuštění a znovunačtení projektu, automaticky načetl, takže nebylo lze chybu opravit, a nakonec jsem musel smazat .suo soubor, abych se neotevíraly žádné soubory projektu), i když je teď dialog Options trochu přehlednější, nemůžu se zbavit dojmu, že z něj zmizely některé položky, které v VS2003 bylo možné nastavit.

Celkově je VS2005 (podle mého zjevně nezasvěceného názoru) pořád nejlepším vývojovým prostředím (hlavně kvůli opravdu vypečenému IntelliSense), ale nějak jsem si od něj sliboval víc...