Vala.. Proč jsem se vlastně páral s tím Pythonem tak dlouho?

Posledních pár dní si hraju s jazykem Vala, který se zdá být ideální náhradou Pythonu ve spojení s GTK+ toolkitem. Vala nabízí o něco méně komfortu, než PyGObject, ale výsledkem je nativní kód, který umí přímo využívat knihovny psané v C. Vala je totiž ve výsledku C, protože kompilátor valac nejprve převede program do C a ten pak zkompiluje pomocí gcc. Jazyk je to oproti C objektový a oproti Pythonu typový, což je pro líného skriptonistu mého formátu, jehož vývoj prošel etapami ZX BASIC > ASM Z80 > deset let nic > BASH, AWK > Python, trochu opruz. Dobrá, současně s ASM Z80 jsem se ještě seznamoval s Pascalem, ze kterého si pamatuju jen otravné BEGIN - END, ale C a jeho odnožím jsem se úspěšně bránil, připadal jsem si na to příliš hloupý. Nebo líný, to vyjde na stejno. Ještě minulý týden se mi při pohledu na slovo 'void' dělalo nevolno a představoval si, jak můj mozek vybuchuje a usazuje se po stěnách místnosti. ...

A proč vlastně obětovat trochu toho pohodlí? V aplikacích, které píšu já, nepotřebuju rychlost, čekání na vstup uživatele (poslední dobou tedy spíš na vstup programátora), nebo jiné události, je tu základ, tady mě Python rozhodně neomezuje. Co mě ale dlouhodobě štve, je nenažranost PyGObject (dříve PyGTK, žere to furt stejně) co se paměti týká. Když napíšu triviální aplikaci typu Svátkový applet/indikátor na panel, vezme si po startu 6,5MiB na 32bit systému, na 64bit s dostatkem RAM je to přes 12MiB. Mně osobně se z toho dělá šoufl, do toho se sakra vešel celý Flashback, nebo Duke Nukem a to byla jiná zábava! Nerad to říkám, ale poslední verze mého SGTimeru umí sežrat i 30MiB, když si s tím člověk na 64bit systému trochu pohraje. Každé menu, každý objekt, žere jako zjednaný. Sice za to nemůžu, ale stejně se za to stydím. Vlastně můžu, Python jsem si zvolil sám, kurnik..

Zkrátka je frustrující, když si v monitoru systému seřadíte aplikace podle využití paměti a ta vaše pidiaplikačka je hned za ... a před ... No však se na to podívejte:

SGTimer po provětrání na 64bit systému

To je šílený.. Podívejte se na update-manager, také napsaný v Pythonu, který v tuto chvíli představuje jen okno, které vybízí k restartu systému po úspěšné aktualizaci. Dobrá, paměti je dost, není třeba vynášet odpadky tak často, ale PyGObject má odpadků více, než je zdrávo a zcela zjevně není schopen efektivně likvidovat nepotřebné GTK objekty, stejně jako PyGTK. Jistě, tohle není problém Pythonu, ale té vrstvy mezi ním a GTK, ale prostě to tak dlouhodobě je a asi to o moc lépe udělat nejde.

První, co jsem začal do Vala přepisovat a na čem se učím, je svátkový indikátor, jakožto to nejjednoduší, co se dá rovnou využít. Takový hloupý indikátor po spuštění binárky z Vala sežere necelé 2MiB na 32bit 3,4MiB na 64bit systému, což sice také není až tak málo, ale po použití GTK tolik sežere každá aplikace a o moc méně to již nejde. Oproti PyGObject aplikacím je to ale třetina a bobtná to o poznání méně, protože není třeba žádných vrstev navíc. Běží to skoro jako byste to psali přímo v C. Vlastně to běží daleko lépe, než kdybych to psal v C já sám, a hlavně daleko dříve.

A nakonec, krom Vala tu máme i jakýsi dialekt, další programovací jazyk, zvaný Genie, který využívá stejný kompilátor (valac), ale jeho syntaxe je bližší Pythonu, tedy především je jejím základem odsazování bloků kódu, místo složených závorek a středníků. Osobně jsem dal přednost Vala, který má pro mě, krom lepší dokumnetace, plus v tom, že mě nutí osvojit si do jisté míry syntaxi většiny od C odvozených jazyků, což pro mě znamená především neustálé doplňování zapomenutých středníků. Možná se nakonec podívám i na ten hnusný JavaScript, co na něm frčí GNOME Shell :)

Pokud tedy hodláte vyrábět aplikaci s použitím GTK+, zamyslete se i nad tím, zda má plýtvání pamětí opodstatnění ;) A nebo naopak, zda by vám Vala neušetřil drahocený čas při psaní GUI..