Egy kis történeti háttér

Az R nyelv az S nyelven alapul amit John Chambers 1975-ben a Bell Labs keretein belül fejlesztette ki. Az informatika területén 35 évesnek lenni matuzsálemi kornak számít, viszont egy stabil és igen hozzáértő kör alakult ki a felhasználókból ez idő alatt. Az R 1993-ban tűnt fel, és létezik még egy S-Plus nevű testvére, amely kereskedelmi szoftver.

Aucklandi atyákat az eredeti S nyelv mellett a Scheme egyszerűsége inspirálta, aminek én mint Scheme rajongó nagyon örülök. A nyelv hamarosan nagyon népszerű lett a statisztikusok körében, így a nyelv egymást követő verziói általában nagyon stabilak.

A kilencvenes évek végén elkezdődött az adatok forradalma. Egyrészt az informatika világa egyre több adatot produkál, (talán ennek hatására) másrészt a humán és társadalom tudományok is egyre jobban a kísérleti és begyűjthető adatok felé fordultak. Egyre többen kezdték el használni különböző statisztikai programcsomagokat ismerték fel azok korlátait is. Az R felhasználói tábora valamikor az ezredforduló körül hirtelen megugrott és azóta is folyamatosan bővül.

Ez a történet csak tovább erősíti a nyelvet. A kemény mag továbbra is szinte változatlan és egyre jobb rendszert fejleszt. A speciális területek művelői egyre több csomagot írnak és publikálna. Az így létrejött nyilvánosság az esetleges hibák felfedezését meggyorsította, a fejlesztők közötti együttműködést elősegítette és még jobb csomagokat eredményezett. Az online fellelhető dokumentáció igen magas színvonalú, habár nagyon technikai jellegű. Úgy tűnik hogy még várnunk kell hogy a “kocka” fejlesztői mag észrevegye ezt és lépjen az érthetőség irányába.

A hosszú történet azzal is jár hogy sok jó könyvet találhatsz (habár ezek általában drágák) és rengeteg publikációt olvashatsz. Könnyű kommunikálni eredményeidet és nem kell sokat magyarázkodnod közben.

Hátrányok

1. Az R nem egy egyszerű nyelv
2. aki nem ismeri a lisp dialektusokat annak az R szintaxisa nagyon idegen lehet
3. nehéz egyszerre statisztikát és R programozást tanulni

Hogyan tovább?
Ha szeretnél még többet megtudni a nyelvről, esetleg kipróbálnád és tanulnád érdemes elolvasnod Valószínűség, statisztika és nyelv című korábbi posztomat, ami segít eligazodni hogy hol érdemes kezdeni.

Via: R, de miért is használjam? – II.

Az nltk dizájn hátrányai
Eddig a legjobb cikk amivel találkoztam az nltk mögötti dizájn filozófiáról Edward Loper NLTK: Building a Pedagogical Toolkit in Python című írása. Érdekes milyen követelményeket vettek figyelembe a rendszer tervezése során:

• könnyű használhatóság
• konzisztencia
• bővíthetőség
• dokumentáció
• egyszerűség
• modularitás

Nyilván ezeket minden rendszernél szeretjük látni. De ne feledjük hogy gyakran kell kompromisszumokat kötnünk hogy az elkészült rendszer pl gyors legyen, vagy “állja a sarat” nagy igénybevétel esetén is. Azonban az nltk egy pedagógiai céllal készült eszköz. Loper éppen ezért emeli ki írásában hogy milyen követelményeknek nem kell megfelelnie az nltk-nak. Nézzük mik is ezek:

• nem kell mindenre kiterjedő, átfogó rendszert alkotni
• a teljesítményt épp annyira kell optimalizálni hogy diák projekteket lehessen kivitelezni vele
• okoskodás, a fenti ponthoz kapcsolódva nem trükkös hack-kek sorával kell tuningolni a programokat, hanem tiszta átlátható implementációt kell készíteni (hogy a diákok láthassák a forráskódban miképp valósítottak meg egy-egy elképzelést)

Szerencsére az nltk annyira jól sikerült hogy nem igazán vesszük észre “hiányosságait”, sőt egyes moduljait az iparban is felhasználják (habár itt figyelembe kell venni hogy a nyílt forráskódot módosítják néha a jobb teljesítmény elérése érdekében).

Milyen követelményeknek kell megfelelnie egy számítógépes nyelvészetben használt programozási nyelvnek?
Erre a kérdésre mindenki máshogy válaszolna nyilván, sőt úgy tűnik az ipar letette a voksát a Java mellett (követve az IT egész világát). Természetesen akadnak kivételek és sok számítógépes nyelvészeti feladatot egyszerűen túl bonyolult Java-ban elvégezni. Ha a mesterséges intelligencia felől közelítjük meg a kérdést (hiszen tekinthetjük kedvenc tudományunkat az AI egy részterületének is), akkor sokaknak rögtön eszébe jutnak az olyan egzotikus nyelvek mint a LISP, Scheme, Prolog. Nem véletlenül, a mesterséges intelligencia programozás klasszikusa, Norvig PAIP-ja kora ellenére még ma is kötelező olvasmány ezen a területen, még ma is hatással van a kezdőkre és profikra egyaránt. Ebben nagy érdekes követelményeket fogalmaz meg a szerző egy AI programozásban hasznos nyelvvel szemben:

1. built-in support for lists
2. automatic storage management
3. dynamic typing
4. first-class functions
5. uniform syntax
6. interactive environment
7. extensibility
8. history

A listára ma is rábólintunk, talán két dolgot tennénk hozzá. Egyrészt nem szégyenkezzünk, számít a gyorsaság. Másrészt már a könyv publikálásakor is feljövőben volt a sztochasztikus megközelítés amely mára az uralkodó paradigmává vált, így joggal kérhetjük ideális nyelvünktől hogy tegye könnyűvé életünk és támogassa a különböző statisztikai függvényeket (ne kelljen már annyit gépelnünk) és adatstruktúrákat.

A Python nyelv az eredeti nyolc pontból hét és félnek megfelel (lehet hogy egy csak az én személyes véleményem, de a 4. pontnak csak részben felel meg a pythonos lambdázás). A további két kritériumnak is megfeleltethetjük a kígyós nyelvet, de ehhez ki kell használnunk bővíthetőségét. A statisztikai elemzéshez és bonyolultabb adatstruktúrák létrehozásához szükségünk lehet a numpy/scipy csomagra, ezek használata kezdő kezekben bizony nagy teljesítmény csökkenéshez vezethet, nem beszélve hogy a nyelv “magján kívül” egy új csomagot kell elsajátítanunk.

Összegzés
Mind a Python, mind az nltk hasznos és sokoldalú eszközök, de dizájnjukból fakadóan nem felelnek meg az általunk felállított kritériumoknak. A következő részben végre rátérünk arra hogy az R miért is ideális nyelvészeti elemzésekre, de persze semmi sem tökéletes, az R-nek is vannak hátrányai!

Via: R, de miért is használjam? – I.