SAS?

.
BME Választható tárgyak a big data világából

Végtelen szomorúsággal és értetlenkedéssel olvastam a fenti blogposztot. Annak is főleg az első felét: Alkalmazott adatelemzés-Applied Data Analysis. A második kurzus - 'Big Data' elemzési eszközök nyílt forráskódú platformokon - tanterve is tudhat kérdéseket generálni, de az legalább koncepcionálisan betonbiztos alapokon nyugszik.

Nagy csalódottságomban - humoros formában - feltettem céges belső slack-en, hogy mi a kakukktojás az alábbiak közül:

shell script, sed, awk, r, SAS, python, hive, pig

Az első azonnali reakció az volt, hogy az awk, mondván, hogy annak semmi értelme, míg a többinek van.

Egy következő reakció: SAS, mert az cégnév. :)

Nekem magamnak semmi bajom az AWK-kal, egy olyan legfrissebb  kdnuggets-es data sciences-felmérés után, ami a negyedik helyen hozza ki. Mondom ezt úgy is, hogy én sose fogom használni nyilván (bár sose mondd, hogy sose, mint tudjuk).

Analytics, Data Mining, Data Science software/tools used in the past 12 months
* Python, 30.3% share (837 votes)
* Java, 14.2% (392)
* C/C++, 260 (9.4%)
* Unix shell/awk/gawk, 8.0% (221)
* Other programming languages, 5.1% (140)
* Scala, 3.5% (96)
* Perl, 2.9% (79)
* Ruby, 1.2% (33)
* Julia, 1.1% (31)
* F#, 0.7% (18)
* Clojure, 0.5% (13)
* Lisp, 0.4% (10)

Azonban a SAS az egy teljesen másik sztori, többszörösen is. Ugye nem kell külön hangsúlyoznom, hogy nálam ez volt a kakukktojás.

1.
Az én világnézetemben, még ebben a felpörgött mai világban sem fér el a sed és a sas egy féléven belül, maximum filozófia-oktatás keretén belül (nem konkrétumok szintjén, hanem magasabb szinteken). Ahogy nem férne el a közgázon a mikróökonomia és makróökonómia, a műegyetemen a newtoni mechanika az atomfizikával. vagy matematikusoknál a funkcionálanalizis a szimplex-módszerrel.

Mondom ezt úgy, hogy SAS-on kívül a többi megfér egymás mellett elvi síkon (arányokon lehet vitatkozni persze).Egészen egyszerűen nem látom azt a közöst, amire felfűzhető a sed és a SAS, néhány előadáson belül.

2.
A következő problémám a visual flow tanítását én minden másban jobban el tudom képzelni, mint a SAS-ban (tematika szövege mondjuk nem említi explicit, de nem tudom elképzelni az elkerülését), még RapidMinerben is ezerszer inkább, pedig a SAS után ők vannak leginkább bögyömben, ideértve a legfrissebb licence-húzásukat (két free edition választásának lehetősége). Számomra a SAS semmi extrát különöset nem nyújt visual flow szinten, cserébe ott van viszont a SAS végtelen arrogáns, inkorrekt, extraprofit hajhászós túlárazós céges hozzáállása, ami oly sokat ártott és árt a data science világnak. Egészen egyszerűen a SAS rossz üzenet régóta és egyre inkább (az én felfogásomban). Bármilyen többi nem kakukktojáshoz hasonló visual flow-s open source cucc jobban megdobogtatná az olyan öreg szíveket, amilyen az enyém.

3.
A harmadik problémám,hogy mi a nemzetgazdasági haszna a GNI-ből (szándékosan nem GDP-t írok) finanszírozott SAS tanításának, preferálásának? Ki fog itthon SAS-t használni, hol, mekkora itthoni GNI nemzeti jövedelmet termelve (más kérdés, hogy a nemzeti jövedelem elköltése is bőven megérne egy misét, de ez itt most offtopik)?!

Számomra a SAS maximum az agyelszívás folyamatát tudja támogatni konstruktív értelemben.

Kontra: programozási nyelvek és adatbányászat kölcsönhatásai

.
Pár napja írtam egy pozitív-konstruktív megközelítést a témában. Ma olyanom van, hogy egy negatív destruktívat fogok írni  ;)

Azonnal felmerülő triviális kérdések:
- Lehet-e mérni egy programozási nyelv megválasztásának hozzáadott értékét a feladathoz (hogy miben oldjuk meg a feladatot)?
- Lehet-e összehasonlítani a programozási nyelveket értelmesen? Az biztos, hogy jó lenne, az is biztos, hogy nehéz feladat a megfelelő mutatók korrekt összevetése.
- Van-e valós tartalom új programozási nyelvek kreálása mögött, ha már 8.000+ programozási nyelv és ~dialektus van? Mekkora a hype-faktor a történetben? Nem kicsi, szvsz.
- Hogy néz ki az egész történet a data science kontextusában.Azt gondolom az adaton, az algoritmuson, hozzáálláson jóval több múlik.

1.Axióma:
Nem vagyok hajlandó aszerint minősíteni egy programozási nyelvet, hogy van-e utasítások mögött pontosvessző vagy nincs, vagy honnan indítja a tömb-indexelést 0-tól vagy 1-től. Ezek olyan finom felbontású dolgok, hogyha ezen a szinten dőlne el érdemben bármi is statisztikai relevanciával, akkor ezt egy másik blogposztban kell tárgyalni. ;)

2.Axióma:
Kizárólag profitcentrikus aspektusból vagyok hajlandó tárgyalni a kérdést, minden nem megoldott problémát ennek rendelek alá. Durván fogalmazva, érzelmek nem játszanak, ha Cobol a jó választás, akkor Cobol-t kell választani, rühelljem bármennyire is.

3.Axióma:
Nem vagyok hajlandó száműzni az embert a feladatmegoldásból, azaz feltételezem, hogy szükség van emberre, szakemberre, a kreativitásra, a gép önmagában nem elég 100%-os mértékben, jelen állás szerint.

4.Axióma:
Legfontosabb támadási pont, hogy miben alapítok a felhalmozott közösségi tapasztalatra, és miben alapítok a saját (vélt) remélhetőleg minél tartósabb lokálspecifikus lépéselőnyőmre. Minél jobb a szétválasztás, minél jobban/gyorsabban azonosítom őket, annál kisebb a költségem, annál nagyobb a profitom.

1.állításom:
Önmagában a programozási nyelv megválasztásával a legnehezebb valós tartós gazdasági előnyt kovácsolni, a teljes projektet nézve.
* kvázi minden programozási nyelvben kvázi minden megoldható, kvázi összevethetően.
* programozási nyelv mögötti közösség tömeg brutálisan jó indikátornak néz ki (inkább a közösségi tapasztalat előnyét hangsúlyozza az individuum zsenialitásával, lokálspecifikumával szemben).
* programozási könyvtárak legacy-hátrányai folyamatosan csökkenek, eliminálódnak
* nehéz tartósítani az esetleg megszerzett versenyelőnyt a kérdéses ismeretlen programozási nyelv használatával.
* nehéz felfelé skálázni az esetleg megszerzett versenyelőnyt
* az új programozási nyelv használatával implementált gazdasági előny feszültsége nagyon instabil, külső tényezők hatóereje miatt.
* sok kompromisszumot kell kötni minden egyes programozási nyelv használatával
* előbbit megfordítva nehéz azt mondani meglévő két programozási nyelvre, hogy "jobb" az egyik, mint a másik.
* nincs nagy léptéke a fejlődésnek, ugyanazt a*/@&#-t paszírozzuk 1950-es évek végétől, még a funkcionális nyelvek esetén is.
* lehet, hogy létezik nagy kiugrásra lehetőség, de ez nagyon nem látszik 60-70 év tapasztalata alapján.

2.állításom:
Egy (új) programozási nyelv kiváló eszköz lehet az agilis fejlesztő gyors pontos megméréséhez, minél könnyebb hadrendbe állításához. Mondom ezt akkor is, ha én elvéreznék egy ilyen teszten.
Tesztelhető, mérhető:
* Szövegértés gyorsasága, pontossága
* Kreativitás
* (Tapasztalat)integrálás készsége
* Prototípus-készítés minősége.

3.állításom:
Egy projekt áll ugye adatokból és algoritmusokból. Mindkettőnél komoly lokálspecifikus versenyelőny kovácsolható, miközben a közösségi tapasztalat jóval kisebb mértékben integrálható. Algoritmusoknál jóság, optimumközelség, overhead éppúgy, mint az adatoknál a zajtalanság, korrektség, teljeskörűség, minimalitás, konzisztensség, pontosság, dqm, tartósság terén.
Az egész pénzben számszerűsíthető (idő, költség, overhead, hiba tényezőkkel együtt is).
Analógia: Egy Oracle DBA max 10%-ot tud tekerni a rendszeren, azt is csak akkor, ha el van rontva előzetesen, míg egy alkalmazásfejlesztő nagyságrendekkel többet. Ugyanígy egy megfelelő programnyelvválasztás hozhat összességében a konyhára, de várhatóan nem az extraprofit kategóriában.

Tényezők, amik alapján összehasonlítanám a programozási nyelveket:
* Funkcionalitás, ökoszisztéma gazdagsága; hiszen az 50.000 Python-Library jobban hangzik, mint a 8.000 R Library, közösségi tapasztalat perspektívájának szempontjából.
* Integrálhatóság, Library, Kód, tapasztalat szintjén
* Script interpreting és Native compiling egyidejű megléte
* Általánoscélú, univerzalitás: SQL-ben nem megcsinálható feladat nem létezik, ugye ;), de azért általános célú nyelvnek nem mondanám.
* Programozási nyelv terjedésének rapiditása, kiterjedtsége, új további programozási nyelvek generálódásának fékeződése,
* Szakirodalom megjelenés gyorsasága, kiterjedtsége
* Releváns előny megléte a többi programozási nyelvvel szemben és/vagy kevés lehetőleg jelentéktelenebb kompromisszum.
* Prototípus-készítés könnyedsége
* Csoportmunka támogatása
* Párhuzamosítás/skálázás támogatása, könnyedsége, "hibataszítása"
* Set-at-home típusú lokális projektkezelés lehetősége.
* Continuos Integration minősége
* Szükséges processzor-erőforrás igénye a feladatvégrehajtáskor (mennyire kevés az overhead)
* Gépi kód minősége fordítás után (legyen minél kisebb, jobb)
* Mekkora távolság a magas szintű nyelv magasszintűsége és a gépi kód között. Minél nagyobb annál jobb, hiszen annál többet lehet elvégezni a géppel, annál több erőforrás jut az emberi kreativitásra
* Overhead magában a programozási nyelvben: egy Cobolban sokkal több a felesleges körítés. For ciklus hegyeknél egy lambda-kalkulus jóval elegánsabb.
* Mennyire örömteli más kódjának módosítása, hiszen nemcsak zöldmezősen kell fejleszteni. Gondoljunk bele, hogy ez még az SQL-nél is mennyire tragikus.
* Anyagi haszon, összevethetőség miatt, adott konstans projektnél, wing-to-wing számolva.

PS: Az "én" programozási nyelveim, amiket szeretek a sokezerből (Pascal és Python után, SQL-t nem számítva), erősen performancia-centrikus világnézettel:
- D (javított C) és ezerszer inkább, mint egy C++.
- Go
- Julia
- Clojure vagy Elixir