Minule jsme si udělali krátký úvod do historie Mac OS X, abychom si dnes mohli podrobněji popsat, proč mnohé společnosti dodnes používají staré programovací postupy.

Kolik jazyků umíš, tolikrát jsi programátorem
Parafráze starého českého přísloví je poměrně velmi výstižná a pro vývoj na OS X velmi důležitá. Jak jsme si již minule pověděli, jedním ze základních rozdílů mezi Carbon a Cocoa knihovnami je, jaký jazyk se používá při programování s jejich využitím - pro Carbon je to C++, pro Cocoa Objective-C (zkráceně označované Obj-C). Jednou si možná povíme více o rozdílu mezi nimi, pro dnešek nám bude stačit, že v obou případech se jedná o objektové rozšíření jazyka C. Ačkoliv teoretici mají proti tomuto jazyku mnoho výhrad, pravdou je, že v praxi jsou pomocí něj napsané prakticky všechny důležité operační systémy, takže programování v něm je velmi praktické. Ovšem C++ a Obj-C se zcela rozdílným způsobem vypořádali s objektovou nadstavbou čistého C. Nerad bych zde rozpoutával nějaký flame, ale i skalní příznivci C++ jistě uznají, že Obj-C šlo, co se objektovosti týče, mnohem dál - jedná se o skutečně jazyk velmi vysoké úrovně*). To jej také předurčilo pro knihovny NeXTSTEPu, jejich návrháři prostě a jednoduše potřebovali objektový jazyk postavený na jazyku C, takže sáhnout po Obj-C byla jasná volba. C++ je jazyk o něco nižší úrovně, což jej činí o něco pomalejším při psaní aplikací (programátor musí víc věcí obsloužit sám), avšak výsledný program by měl být rychlejší. Dalším významným rozdílem je syntaxe, neboli to, jakým způsobem pomocí jazyka vyjádřit, co po systému vlastně chcete. C++ používá tzv. tečkovou syntaxi, Objective-C závorkovou. Na první pohled se může zdát, že se jedná o prkotinu, ale programátoři trpí v tomto ohledu mnoha předsudky, oproti kterým je pověra, že za updaty OS X se platí, pouhým detailem… Abyste si mohli udělat představu, jaký je rozdíl mezi oběma zmíněnými syntaxemi a nemuseli prolézat Wiki, ukážeme si malý kousek kódu, kterým vytvoříme jednotku Osoba, přiřadíme jí jméno, telefonní číslo a přidáme ji do pole (= úložiště jednotek, kde každá má přesnou pozici, tzv. index) již existujících osob. Neprogramátoři si celou operaci mohou jednoduše představit i jako operaci v grafickém rozhraní - spusťte si Address Book, přidejte nový kontakt, napište jméno, telefon a klepňete na Edit; tak přesně o tohle jde, jen my si ukážeme jakousi minimalistickou variantu.

*) Pod pojmem nízko/vysoko úrovňový jazyk si nepředstavujte, že jeden je plebejec a druhý patricij. Pojmem úroveň je v programování myšleno, jak „blízko” je jazyk k hardwaru. Tzn. Objective-C je jazyk skutečně vysoké úrovně, o moc víc už ani dnes nelze jít. C++ je výrazně níže, čisté C ještě níže, pod ním je ještě assembler a strojový kód, ve kterém říkáte přímo procesoru, jaké specifické operace, s jakými daty a v jaké posloupnosti. Ve dvou posledně zmiňovaných už dnes ovšem skoro nikdo neumí psát.

Porovnání syntaxe
C++
Osoba *novacek = new Osoba;
novacek.jmeno(“Jan Novak”);
novacek.cislo(777192837);

existujiciOsoby.appendValue(novacek);
delete novacek;


Objective-C
Osoba *novacek = [Osoba new];
[novecek setName: @”Jan Novák”];
[novacek setCislo: 777192837];

[existujiciOsoby appendObject: novacek];
[novacek release];


A ještě pro srovnání čisté C, jak by bylo použito v nízkoúrovňových knihovnách OS X
CFOsobaRef osoba = CFOsobaCreate();
CFOsobaSetName(osoba, "Jan Novák");
CFOsobaSetCislo(osoba, 777192837);

CFArrayAppendValue(existujiciOsoby, novacek);
CFRelease(novacek);


Programátoři mi jistě prominou, že by všechny tři kódy šly napsat jinak (a ten v Obj-C by i jinak být měl, ačkoliv by i takhle fungoval). Zvolil jsem tento příklad právě proto, že bylo možné napsat takřka přesně to samé, jen jinou syntaxí. A všimněte si i chybějící diakritiky u C++. Ne, že by C++ neumělo pracovat s diakritikou, ale knihovny Carbonu jako takového si prakticky neporadí s Unicode, což je důvod, proč i Photoshop s tím měl dlouho problémy (a proč třeba v Prismu od GraphPadu nelze diakritiku použít vůbec, ačkoliv jinak je to moc šikovný, a bohužel i moooc drahý, program).
Jak vidíte, rozdíl je zásadní. A když k tomu přidáte, že většina programátorů umí ještě i Javu, která by byla takřka k nerozeznání od C++ (ačkoliv logikou se blíží víc k Obj-C ), začíná vám být jistě jasné, proč je jednodušší a tudíž i levnější sehnat programátora v C++. Naštěstí poslední dobou se zdá, že počet programátorů v Obj-C utěšeně roste. Je to dáno také tím, že dnešní mladá generace již nevyrůstá (jen) na C/C++, ale je zvyklá používat Javu, Phyton, Ruby, PHP…… Takže kromě toho, že požadují výrazně objektově orientované jazyky, nemají problém se přeučit na jinou syntaxi. A z vlastní zkušenosti můžu potvrdit, že pokud člověk přistoupí k Obj-C s alespoň elementární znalostí čistého C a hlavně bez předsudků, může za odpoledne nejen pochopit většinu základních vlastností jazyka, ale může si i nastudovat základní třídy knihoven Cocoa (třída je zjednodušeně popis, podle kterého se vytváří jednotky/objekty - kupříkladu „novacek” byl objektem vytvořeným na základě třídy Osoba, odborně by se řeklo, že byl její instancí).

Uf, tak to bychom měli jeden důvod, proč velké firmy upřednostňovaly ještě donedávna Carbon.

Multiplatformnost
Hned zpočátku se musím přiznat, že tenhle argument je mi osobně špatně pochopitelný, ale holt každý máme svůj pohled na věc.
Častým způsobem psaní multiplatformních aplikací je naprogramování si vlastních knihoven v jazyce, který lze bez problémů použít na více operačních systémech. Takovým jazykem je zpravidla kombinace C/C++. Pomocí těchto tříd se naprogramuje tzv. model aplikace - tedy skutečný výkonný kód, který něco „dělá”. V případě Photoshopu si pod tímto lze představit kód, který pracuje přímo s obrazovými daty, upravuje je, přepočítává atd. Tento model se použije shodný pro všechny platformy, pro každou zvlášť se navrhne grafické rozhraní a obojí se spojí tzv. kontrolérem (proto se tento způsob tvorby aplikací nazývá MVC - Model-Viewer-Controler, nehledě na to, jestli se programuje pro jednu nebo více platforem). Model tedy máme (skoro) stejný pro Windows, Linux i OS X. Ale kontrolér i rozhraní musíme naprogramovat pro každou platformu zvlášť. A ty právě u velkých programů jako Photoshop jsou v Carbonu. Kromě historického důvodu je vtip v tom, že programátoři se striktně nedrží MVC modelu, takže se jim kód různě prolíná a podobně (ano, je to fuj ). A najít v tom všem „bordelu” místa, která by se při přepisování aplikace do Cocoa musela měnit, je nadlidský úkol. Je totiž jednodušší kód prakticky celý přepsat (rozuměj překopírovat, projít a u/opravit ).
A proč že tomu nerozumím? Když pominu fakt, že i model by bylo možné napsat v Objective-C (tady ovšem chápu, proč tomu tak není - kupříkladu Photoshop potřebuje v případě modelu rychlý kód, a to mu C++ zajišťuje lépe), tak mi není jasné, že se Adobe vyplatí sedm let udržovat kontrolér a rozhraní v Carbonu. Věřte mi, že je to oproti Cocoa o tolik víc práce, že kdyby v době Pantera jakožto prvního skutečně použitelného systému (navíc Apple se teprve v jeho době vyhrabal ze dna) přepsali tuto část z Carbonu do Cocoa, máme dnes krásný Photoshop, který si nejen poradí s Unicode, ale bude mnohem lépe integrovaný do systému a nebude vypadat, jako kdyby ho navrhli pro XP (aspoň doufám). Problém je zřejmě ve více věcech. Kromě asi ne úplně čistého MVC návrhu to bude i konzervativnost programátorů. A pravděpodobně i neochota managementu Adobe zaplatit v jednu chvíli víc peněz, pozdržet o pár měsíců vydání nové verze a nechat programátory na tom zapracovat (krátkodobá hlediska jak u politiků, ale to je bohužel tak, když nám vládnou ekonomové s myšlenkou, že co se nezaplatí do 3 let, jako by nebylo).

Tak to by byly hlavní důvody, které vedou některé společnosti k udržování programů psaných v Carbonu ještě v době, kdy Cocoa v Leopardu poskytuje ohromné možnosti, jak urychlit jak vývoj tak samotný běh programů; o pohodlí a chybovosti raději nemluvě. A raději také ne o tom, že z Cocoa můžete pohodlně volat Carbonové funkce. A dokonce existuje možnost mixovat kód v Obj-C a C++ v jednom souboru (označuje se Objective-C++, což se mi osobně ukrutně nelíbí).

Podraz
Nikoliv však v podání Paula Newmana a Roberta Redforda nýbrž Steva Jobse a Applu. Když totiž chlapci z Cupertina představovali vývojářům v roce 2006 na konferenci WWDC první verzi Leoparda, hovořili jasnými slovy, že 64 bitové programy bude možné vytvářet v Cocoa i v Carbonu. Jenže sešel se rok s rokem, iPhone s iPodem… a vlivem zdržení při vývoji OS X došlo k rozhodnutí zmrazit práce na vývoji 64 bitových technologií pro Carbon. A osobně tipuji, že nejen k tomu, mám totiž dojem, že Apple konečně učinil rázný krok k zaříznutí Carbonu jako takového. Aby toho nebylo málo, vývojáři se o tom dověděli skutečně až na konferenci WWDC 2007, takže mnozí z nich již rok pracovali na 64 bitových aplikacích pro Carbon. Mezi ně patřil i vývojový tým Adobe, který má na starosti Photoshop pro Macintosh. A právě proto nebudeme mít 64 bitový Photoshop v Creative Suite 4 - u Adobe by prostě již nestihli celou aplikaci přepsat do Cocoa. Zbývá nám totiž už jen asi rok do dalšího výpalného za evropské verze CS.
Jedna pikantnost na závěr: o tom, že Apple zařízne vývoj 64 bitového Carbonu, nevěděli do poslední chvíle ani mnozí jeho vlastní programátoři! Ještě pár dnů před WWDC 2007 tak na Leopard Sesions (malé výukové kurzy, které Apple pořádal pro externí vývojáře zdarma různě po světě) vysvětlovali, jak na 64 bitů v Carbonu. Ale kdyby něco, tak všechno zapřu, neb na tuhle informaci se vztahuje NDA

A jak je to tedy s těmi 64 bity
Skutečně jsou tak moc potřeba, zrychlí nám dvakrát aplikace, je to spása a čekají nás s nimi světlé zítřky? Osobně se domnívám, že ne. Častým omylem je domněnka, že 64 bitové programy jsou dvakrát rychlejší než 32 bitové (a já bych tak musel upgradovat na hrocha64 ). Jenže v případě počtu bitů nejde ani tak o rychlost, jako spíš o schopnost programu pracovat s určitým množstvím operační paměti. Neklame-li mne paměť, tak jde o velikost dat, která je procesor schopen zpracovat v jednom kroku. Neboli s jak velkými čísly umí pracovat. V případě starých 16 bitových procesorů to bylo 2 na 16, tzn. asi 65.5kb (čísla od 0 do 65535); 32 bitové procesory naproti tomu jsou schopné adresovat přes 4Gb, což je skutečně zásadní rozdíl. A teď se podívejte na obsah svých pevných disků a sečtěte, kolik vašich souborů má přes 4Gb (tedy spíš o něco méně, jelikož třeba právě Photoshop je schopen bez potíží zvýšit při otevření velikost dat v paměti i čtyřikrát oproti zdrojovému souboru). Nevím jak vy, ale já jsem po náročných matematických operacích dospěl k číslu 0 (jen doufám, že jsem to někde špatně nezderivoval ). A to je ten důvod, proč přechod od 32 k 64 bitovým procesorům a aplikacím (které umí adresovat neskutečných 18 exabitů; ačkoliv Apple na svých stránkách uvádí jen „up to 128TB”) není ani zdaleka takový rozdíl jako mezi 16 a 32 bitovými. Takže pokud potřebujete pracovat se skutečně ohromnými soubory, nezbude vám asi nic jiného, než si počkat na CS 5 (možnost pracovat pod Windows nedoporučuji, mohli byste utrpět ošklivý kulturní šok ). Respektive, ani to není tak žhavé, on nakonec Photoshop umí i dnes zpracovávat velké soubory, jen mu to déle trvá. Nakonec i u Adobe odhadují, že 64 bitová verze pomůže jen 8-12% uživatelům, kterým se práce urychlí o 8-12%. Osobně bych byl ještě o něco skeptičtější, zvlášť co do počtu uživatelů. Když vezmu v úvahu, že skutečně velkou základnu tvoří weboví grafici a „polo-profesionálové”, dost pochybuji i o těch 8%.

Takže žádný strach, Macintosh neumře na odložení 64 bitové verze Photoshopu. Ale na druhou stranu si přiznejme, že je to tak trochu trapné. Navíc různí pomatenci a jiní faktoři budou mít v ruce nezpochybnitelný argument, proč že je ten OS X tak špatný. A jelikož většina uživatelů netuší, jaký je skutečný rozdíl mezi 32 a 64 bitovými programy, tak na ty nesmysly i skočí. Proto šiřme osvětu, jak jen to jde!

--
Nezbytná poznámka pod čarou: Mám nápad na několik témat, o kterých bych rád něco napsal. Naschvál nebudu říkat, jaká to jsou, abych vás neovlivnil, ale požádám vás, abyste případně navrhli, co by nejvíc zajímalo vás. Samozřejmě v rámci tématu, já toho o počítačích moc nevím