Ennek az írásnak az ötlete már jó ideje motoszkál bennem. Mindig is érdekelt a programozás – magas szinten. Azaz érdekelt, hogyan lehet nagy rendszereket tervezni, érdekelt, hogy ezek a rendszerek hogyan használhatóak az egyszerű felhasználó szemében. Érdekelt, hogyan lehet megcsinálni, de valahogy sosem csináltam meg. Egyszer ki kéne próbálni, de erre a közeljövőben ismételten nem lesz időm.
Ez persze nem akadályozott meg abban, hogy utánaolvasgassak a témának. Illetve azon oldalak ajánlásait kövessem, akikre már amúgy is feliratkoztam. 🙂 Így találtam rá az Ars Technica cikksorozatára, ami a fejlesztési eszközöket, nyelveket, APIkat veszi górcső alá. Korábban már volt szerencsém az Ars Technicahoz, ők képesek voltak korábban például a Leopardot tizenegynéhány oldalban elemezni, elvárásokkal, hiányokkal és hasonló dolgokkal. Szerintem tanulságos volt, ezért érdemesnek láttam a cikksorozatba is belekóstolni.
Az írás alapvető példája, mint mondtam, az volt, hogy összevesse a lehetőségeket. Előrebocsátom, hogy az ő írásuk is (az enyém meg pláne) az Apple megoldását preferálja a Microsoftéval szemben, ezért aki ebből flamet csinálna, az inkább most hagyja abba. Annak semmi értelme sincs (mondom ezt én 🙂 ).
Na, ideje belevágni a témába. A vonatkozott cikksorozat engem leginkább egy vonatkozásban fogott meg: a második részben feszegette azt, hogy a Microsoft APIk mennyire nem kifinomultak – valószínűleg ez lehet az oka, hogy szerte a cégen belül is a “kerék újra feltalálása” a divat. Ezt talán a mellékelt kép is szemlélteti (a kép eredeti változata a http://arstechnica.com/articles/culture/microsoft-learn-from-apple-II.media/vista.png címen érhető el).
A helyzet rossz. Nagyon. A képen szereplő ablakok a Visual Studio 2005 kivételével az aktuálisan elérhető legfrissebb változatok. Érdemes megfigyelni, hogy vannak alkalmazások menüvel és menü nélkül (utóbbi esetben szalaggal vagy rejtett menüvel). További érdekesség, hogy az Office család szereplő tagjainál alapvető eltérések vannak szerkezetben (szalag nézet a Wordben, hagyományos nézet a Visioban, és az Outlook mindig is egyedi volt). Másik érdekesség az előre-hátra nyilak az Intézőben, az Internet Exporerben és a Windows Media Playerben. Pontosabban a mellette levő lefele nyíl, ami a listát jelenítené meg: minő véletlen, ebből is van háromféle változat.
Biztos, hogy van még különbség, de ezek felderítését az unatkozó olvasókra bízom. 🙂
Azzal semmi bajom sincs, hogy a Vistában a felület máshogy néz ki, mint korábban. Lehet vitatkozni rajta, hogy jobb lett vagy rosszabb, mint a korábbi, én nem teszem meg, mert csak képernyőképeken láttam a rendszert. De ez így katasztrófa. Az Ars Technica sorozatában még mondott egy érdekes példát: a Vista kezdeti változatában azért voltak gondok a hangkártyadriverekkel, mert a Microsoft a fejlesztés végső szakaszában módosította a hangrendszert. Az ok: leültek multimédiában érintett emberekkel, és azok jelezték, hogy a lejátszóprogramok feleslegesen terhelik a gépet, ha pollozzák a hangbuffer állapotát, jobb lenne, ha az értesítené őket, hogy fogyóban az adat. Felmerül a kérdés: ez miért nem került a cég multimédiás programjának, a Windows Media Player fejlesztésekor? Például mert nem használja a saját APIt?
Ezzel szemben OSX-en az Apple szinte minden programja (nem állítom, hogy minden, mert azért az sem lenne igaz) egy közös megjelenítési APIt használ, és ez az API elérhető a fejlesztők számára is. Ezen felül elérhető még [[http://developer.apple.com/documentation/UserExperience/Conceptual/OSXHIGuidelines/|Apple Human Interface Guidelines]] című dokumentum is, ami egyfajta szakácskönyvet ad a fejlesztők kezébe, hogy az Apple milyen elvek szerint építi fel a programjait (többé-kevésbé). Eredmény: ha jön egy programozó, aki OSXre szeretne szoftvert írni, megnézi ezt a dokumentációt, és ez alapján tervezi meg a felhasználói felületet, és a beépített APIt felhasználva valósítja meg. Következmény: a 3rd party programok is hasonlóak lesznek a beépítettekhez. Ez a Microsoftos káosznál elérhetetlen állapot…
Persze a dolog messze nem ilyen egyértelmű: a http://www.neopoleon.com/home/blogs/neo/archive/2008/03/17/29941.aspx oldalon például a szerző azt részletezi, hogy miért nem szereti az OSX APIjait. Ez érthető is. Ahogy az Ars Technicas cikk harmadik részében szerepel, az Apple által erőltetett Objective-C nyelv alapvetően különbözik a megszokott objektum-orientált nyelvektől, csak OSX-en lehet használni, az XCode nevű program semmi különöset nem nyújt egy Visual Studiohoz képest, sőt, az extrák tekintetében le is van maradva. Szintén ebben a cikkben szerepel, hogy OSX-en meg hiányolja a .NET bizonyos részeit vagy éppen az Office 2007-et. Más szóval a helyzet messze nem egyértelmű, érdemes a továbbiakban is figyelni a témát, milyen változások lesznek.
Frissítés: Az Ars Technica cikksorozatára való hivatkozásokat pótolom.
- [[http://arstechnica.com/articles/culture/what-microsoft-could-learn-from-apple.ars|Áttekintés, történelem]]
- [[http://arstechnica.com/articles/culture/microsoft-learn-from-apple-II.ars|A Microsoft megoldásainak összegzése]]
- [[http://arstechnica.com/articles/culture/microsoft-learn-from-apple-III.ars|Az Apple APIk ismertetése]]
Érdekes kérdést feszegetsz.
Mióta Microsoft rendszerekre is írok programokat (a monokróm kijelzős WinCE PDA-tól (C++) a PC-ig (C#.NET)), úgy érzem, picit jobban átlátom a Microsoft elképzeléseit a programfejlesztésről és az API-król. Amin kapásból meglepődtem, az a rettenetesen sok “deprecated” megjegyzés volt, amivel találkoztam: jól láthatóan a Microsoft elég gyorsan módosítja az API-kat. Ahhoz viszont, hogy a Microsoft termékek enterprise környezetben is életképesek maradjanak, szükséges a visszafelé kompatibilitás megőrzése. Szerintem ez, illetve ennek nem feltétlenül tökéletes implementációja állhat az anomáliák egy részének hátterében. Nem szép megoldás, de úgy néz ki, hogy a Microsoft ezt az utat választotta a modernség és az enterprise alkalmazhatóság kompromisszumaként.
Örülök a hozzászólásodnak – én próbáltam nem a saját véleményemet írni – mert azt nem tudom tényekkel alátámasztani. Amit láttam, attól még lehet tökéletesen jó és tökéletesen rossz is. Ugyanakkor igyekeztem odatenni a túloldalt is – hogy vannak, akik pl. a Macét szidják. A helyzet messze nem egyértelmű.
Az én korlátozott fejlesztési dolgaim php (meg hozzá némi html, css, sql), illetve java nyelvhez kötődnek, ezek egyike sem passzol túlságosan a most említett témákról.
Kompatibilitás: én az Apple kapcsán láttam egy szép kompatibilitási megoldást, és nekik erre szükségük is volt. Egyszer, amikor Mac OS9-ről Mac OSX-re váltottak, akkor elég aggresszív API-frissítést hajtottak végre. Ekkor gyakorlatilag virtuális gép jelleggel csináltak visszafelé kompatibilitást (ez a Classic környezet), azaz a régi programok nagyobb erőforrásigénnyel futottak az új rendszeren. Ugyanezt a megoldást eljátszották a PPC-ről Intelre váltáskor is, az Inteles gépekre adtak egy Rosetta nevű programot, ez megint emelt erőforrásigénnyel ugyan, de futtatta a régi programokat. A koncepciónak két előnye van: egyrészt egyáltalán nem kell a régi döntéseket hosszú távon követni, másfelől a csökkenő teljesítmény miatt erőlteti a fejlesztőket, hogy váltsanak a frissebb APIkra. A hátránya meg nyilván az, hogy nagyobb a teljesítményigénye, illetve ha nem tartják meg elég hosszú ideig az emulátort, akkor lehet, hogy túlerőltetik a fejlesztések tempóját (lásd még a Drupalról írt írásomat.
És most látom, hogy az Ars Technicas linkeket kihagytam a cikkből. Pótolom.