Jussunk 5-ről a 6-ra
AVAGY A MÁSODIK ORSZÁGOS PERL TALÁLKOZÓ
Augusztus 28-án került megrendezésre Budapesten a második Országos Perl Találkozó. Idén az előadók között volt Leo Tösch, a Parrot VM egyik vezető fejlesztője is.
Mi lehet érdekes egy PERL konferenciában? Tömören a kívülállóknak – vagyis azoknak, akik nem foglalkoznak a nyelvvel – gyakorlatilag semmi. Ennek megfelelően magáról az eseményről, a Perl-specifikus előadásoktól megpróbálunk egy kicsit elvonatkoztatni. Inkább arra helyezzük a hangsúlyt, amit az ember a világ különböző részeiről (Magyarország, Ausztria, Izrael) érkező, az ipar különböző területein tevékenykedő progamozóktól, szakemberektől egy-egy korsó sör mellett megtudhat, és amilyen következtetéseket ezekből a beszélgetésekből, az előadások értékeléséből levonhat.
A papagájról
Bár személy szerint minden előadás érdekesnek és hasznosnak találtam, engedtessék kiemelni közülük egyet: Leo Tösch a Parrot-ról szóló, "A Papagáj nevelése" című agytágítását. Leo – akit a Perl társadalom egyszerűen csak "Parrot Pumpkin" néven ismer – volt olyan kedves, és barátjával, a CPANTS alkotójával, Thomas Klausnerrel Ausztriából érkezett a rendezvényre, hogy Budapesten fecsérelje el hétvégéjét (lásd még: kommunista szombat). Leo igazi hardcore figura, amolyan woodstock típusú hippi, aki kézzel sodorja a cigit – egyiket a másik után –, de a farmer mellé elegáns "bankárcipőt" visel. Őt övezte szemmel láthatóan a legnagyobb tisztelet: aki képes egy programnyelv magját (szabadidejében) fejleszteni, az az ördöggel cimborál.
De mi is a Parrot? Kezdetben egy április elsejei beugratásnak indult, amikor megjelent a később számtalan szakmai oldalon szindikált (ál)hír, miszerint a Python és a Perl programnyelveket Larry Wall (Perl) és Guido van Rossum (Python) rövidesen összeolvasztja. A később mindössze fél tucat szívinfarktust okozó bejelentés végül is nevet adott a Parrot projektnek, és mint utólag kiderült, annyira nem is áll távol a vicc a valóságtól...
A Parrot egy VM, vagyis Virtual Machine – egy olyan program, melynek feladata egy, jellemzően assembly-közeli, és jellemzően byte-kóddá fordított nyelv programsorainak futtatása. A VM-ek közül legismertebb egyértelműen a Java VM, vagyis – kissé obszcénul – maga a "java.exe", melynek fordítója a "javac" névre (Java Compiler) hallgat. A dolog tehát működik: az a megközelítés, hogy egy nyelvet nem közvetlenül "assemblyre", tehát a célprocesszorra fordítjuk, több előnnyel is jár. Először is a nyelv fordítójának felépítése leegyszerűsödik, végső soron a fordító "modulárisabbá" válik. Másodszor egy nagyságrenddel növeli a hordozhatóságot, hiszen elég a VM-et portolni, a program illetve a byte-kód már fut elvileg bárhol, ahol a VM is létezik –fordítsd otthon, futtatsd bárhol, a "piackész" szoftver egyetlen verziója terjeszthető, és mindehhez a forrást sem kell kiadni. Harmadszor a VM-ek nyelve lényegesen bővebb, mint az átlagos assembly-ké, így a felsőbb szintű fordítóknak kevesebb gondjuk van – nem kell például regiszter-allokációval, garbage collection-nel, memóriafoglalással stb. foglalkozniuk.
A Parrot regiszter alapú, ami – kissé talán vitatható módon – szakít a "hagyományos" VM-ekkel, melyek jellemzően verem alapúak. Elsősorban az eljövendő Perl6 futtatására lett kitalálva, de nem meglepő módon már elkészülte előtt kinőtte magát ebből a szerepből. A Parrot-ot jelenleg nagyon aktívan alakítják, fejlesztik, portolják – érdekes módon magánál a Perl6-nál a nyelvi specifikáció az, ami a legtöbb időt elveszi.
Leo a Parrot felépítésének bemutatása mellett sebességteszteket is előkapott a kalapjából, továbbá érdekességképpen prezentációját egy Parrot-ban írt program futtatta. Ez mutatja, hogy 0.0.10-es verziószáma ellenére a Parrot már egész jól működik. Aki szereti az assembly-t, valószínűleg nagyokat fog csodálkozni, mikor a Parrot assembly-jét vizsgálva szembe találja magát a "print" utasítással, vagy netán az öröklődést(!) megvalósító kulcsszóval. Hiába, ez egy virtuális gép, itt már nem csak az van, hogy MOVE D1, D2.
A Parrot talán legnagyobb vívmánya az, hogy kifejezetten nem egy nyelvhez, hanem általános értelemben scriptnyelvekhez (jellemzően "gyengén típusos" nyelvekhez) készül. A forrás már jelenleg is tartalmazza Ruby, BASIC, Python és társaik jobbára működőképes megvalósításait, illetve készül a Ponie, a Perl5 Parrot alapú változata. Mindezek meglepően gyorsan születtek: állítólag aki ért hozzá, néhány nap alatt összedobhat magának egy saját nyelvet, amit aztán Parroton futtathat. (Azért csak állítólag, mert én nem igazán tartozom ezek közé az őrültek közé.) Nagyobb problémát ilyen tekintetben talán csak a Java és – nem meglepő módon – maga a Perl5 okoz: előbbi erős típusossága, míg utóbbi rettenetes, kontextusérzékeny szintaxisa miatt.
És hogy ez miért is jó? Elsősorban azért, mert a Parrot-ra épülő, vagy azon is megvalósított programnyelvek így képesek egymás moduljait használni. Bár a "sima" Perl5 már most is tartalmazza az "Inline" modult, amellyel például C és Java kód forrás szinten ágyazható Perl programokba, a Parrot kínálta megközelítés sokkal mélyebb együttműködést tesz lehetővé. Egy előremutató dologról van szó, amiből sok következtetést lehet levonni: vajon a jövőben a "cél szentesíti az eszközt" alapon tényleg összemosódnak a programnyelvek határai? Ha igen, akkor mit jelent ez a programozóknak: elég lesz-e egy-két nyelvet profi szinten ismerniük, vagy a jövő a sok nyelven "beszélő" szakembereké? Esetleg a közös futtató engine miatt éppen hogy kihalnak a kevésbé sikeres nyelvek? Nehéz megmondani.
A téma óriási – most mégis ennyit róla. Akit jobban érdekel a Parrot, esetleg szeretne játszani vele, az látogasson el a nyelv honlapjára (http://www.parrotcode.org/). És ha valami nem tetszik, vagy nem működik: "patches are welcome"!
Perl5, Perl6 – ipar és marketing
Újabban divatossá vált, hogy egyes Open Source cégek – csak úgy példaképpen a MySQL AB-t említve – úgynevezett "sikertörténeteket" adnak közzé. "Itt az XY Rt-nél lecseréltük az XXX adatbáziskezelőmet MySQL-re, és most a megtakarított pénzből vettünk két Ferrarit, meg cigit. Ja, és ez nem fagy" – ilyenekre kell gondolni. Mint ahogyan azt a rendezvény egyik szervezője, Szabó Gábor is elmondta, ez a Perl esetében sajnos nem így működik: mivel a nyelv reputációja eléggé rossz – sokan ezt hiszik, nem több, mint egy bonyolultabb AWK vagy BASH – hiába érnek el sikereket ismert, neves cégek a használatával különfélébb helyeken (például akár Windows alkalmazások automatizált tesztelésénél), nem merik azt bevállalni, mert ellentmond üzletpolitikájuknak. Gondoljunk bele: a Gumimaci Rt. közli, hogy márpedig ő Perlt használ, erre esnek a részvényei. Miért van ez így, és lehet-e, érdemes-e ellene valamit tenni?
A nagyok, elsősorban a Sun és a Microsoft marketinggépezete mára sikeresen a managerek fejébe verte, hogy "mi a jó": így fordulhat elő, hogy a szakmailag teljesen képzetlen megrendelő ma már gyakran megmondja, hogy szoftverét milyen nyelven fejlesz-ék ki. Ez az alapvetően "totálgáz™" szituáció lassan mindennapossá válik, és az egész iparágat érinti. Sok fejlesztőcég vált alapvetően kevésbé hatékony, gyakorta költségesebb technológiára azért, mert a nagy halakkal az open source technológiát képviselő cégek, közösségek nem tudnak versenyezni. Márpedig a piac, vagyis a pénz diktál, és nem az elkötelezettség: ha a megrendelő X nyelvért fizet, akkor Y nyelv megy a kukába.
A helyzet nem katasztrófális, de mindenképpen aggasztó, és ez messze túlmutat a Perl sikerességén vagy sikertelenségén. Míg mondjuk a dokumentum-formátumok, protokollok és a hozzájuk kapcsolódó szabványok számának alacsonyan tartása hasznos cél, ugyanez nem mondható el a szoftverekről és a programnyelvekről. Egész egyszerűen más célra más való. A Perl5 csökkenő népszerűsége és elterjedtsége – melyet open source irányból talán csak a PHP ért el – a sötét jövőt vetíti elénk: egy bizonyos szoftver vagy architektúra indokolatlan egyeduralmát egy adott piaci szegmensen belül. Ugye ismerős ez valahonnan máshonnan? Java-ban írjuk majd a CRON scripteket? Hát mind meghalunk!
Itt egyébként a Perl6 esetleges bukása is felmerül. Ki fogja vajon használni? Hiába lesz ez az új, mellesleg a Perl5-tel teljesen inkompatibilis nyelv talán az egyik leghatékonyabb és legmodernebb, ha pozícionálása elriasztja a programozókat. A PHP esetén megvan az utánpótlás, hiszen a kezdő, amatőr programozó is tud vele kezdeni valamit – aztán amikor már nem kezdő, akkor meg már sok mindent. A Perl6 hatékony használatához viszont komoly programozáselméleti ismeretekre is szükség van, ami azt jelenti, hogy a Perl5 kezdő-gyilkos szintaktikája után itt megérkezik a szemantikai halál. Ellenben nem várhatunk profi programozókat sem, hiszen a profi az jön valahonnan: mondjuk C++-ból vagy Java-ból. És ő miért éppen a Perl6-ra tenne? Hiszen Java-ban, C#-ban varázsolva valószínűleg százszor több munkahelyen kapnak majd utána. Pénz beszél, kutya ugat.
Ámen
Miközben mindenki az operációs rendszerek és technológiák harcára figyel, a programnyelvek területén komoly változások készülődnek. A 90-es évekre a hardver, míg a XXI. század első évtizedére a szoftverek és architektúrák forradalma jellemző. Megeshet, hogy a következő évtized a nyelvek forradalmát hozza majd. Érdemes erre figyelnünk, hiszen közvetlenül érinti a szakmát. És bizony ezért érdemes egy ilyen "geek" konferenciára elmenni: az ember hiába böngészi naphosszat az Internetet, bizonyos dolgok csak ilyenkor válnak számára világossá. Lehet, hogy tévedtünk, és az előadás mégis többet ér, mint a jegyzet? :)
- Inyl
A találkozó résztvevői köszönetet mondanak a szervezőknek és a Pentaschool-nak.