oktoober 19, 2014

Programmeerimise paradigmadest: Millist korvi valvama hakata?





















Vita brevis,
ars longa,
occasio praeceps,
experimentum periculosum,
iudicium difficile.

Elu on lühike, kunst selle mõistmiseks
võtab kaua aega,
juhus libiseb käest,
katsetamine ohtlik
ja otsustus keeruline

Meie keeleruumi on lugu munadest ja nende paigutamispõhimõtetest jõudnud peamiselt
ühe tubli Kilpla naise kaudu, kes teel turule äriplaani valmis mõtles:
müüa mune, osta kanu, müüa veel rohke mune ja saada pururikkaks.
Rõõmust hakanud ta aga tantsima ja kõik munad purunenud katki. 
Ehk oleks pool korvitäit targem olnud koju jätta ja alustada äri poole korvitäie munade müügi edulooga.
Ma ei mäleta täpselt, mis sellest kanast sai, ilmselt sai tal munemise isu otsa, kui sellisest oma ihuvilja raiskamisest kuulis.

"Ärgem pangem munasid ühte korvi!", nii võiks seda lugu refereerida.

Inglased üritavad selle elutarkuse sündi seostada Cervantese kuulsa tegelase Sancho Pancha-ga.

Naljakal kombel ei ole Cervantesel selle vanasõna sünniga suuremat pistmist:
Käibesse läks lause Cervantese bestselleri lohaka ümberpanemise tõttu - kusagil 1700 avaldatud esmatõlkes pandi üks lause inglise keelde sedaviisi ümber. Pärast seda ei leia te mitte ühestki Don Quijote tõlkest sellist rahvatarkust. Aga dzinn oli pudelist välja lastud ja mitte ühegi valemiga ei ole Hippokratesel ega Cervantesel, juhul, kui nad taaskehastuksid, võimalik maailmale selgeks teha, et nad ei mõtelnud neid asju päris nii. Et tahtsime paremat, aga välja tuli, nagu alati.
Sancho originaalse mõtteavalduse leiate te Don Quijote eestikeelse väljaande 186-ndalt leheküljelt:

"Teie heldus", vastas Sancho, "taganemine ei ole põgenemine, ja kohalejäämine ei ole mõistlik, kui hädaoht on suurem lootusest ja kes on tark, see hoiab end homseks ega pane kõike mängu ühel päeval . Ja teadke, et kuigi mina olen ainult harimatu talupoeg, taipan ma ometi veidi, mis on mõistlik talitusviis. Ärge siis kahetsege, et te mu nõu vastu võtsite, vaid asuge Rocinante selga, kui te suudate, ja kui ei, siis ma aitan teid, ja tulge mulle järele, sest mu nupp ütleb mulle et meil läheb praegu jalgu rohkem tarvis, kui käsi

Jänkid vormisid lause munade jagamisest Mark Twaini / Carnegie abiga soovituseks, et rikkaks saamiseks tuleks
"kõik munad ühte korvi panna ja seda hoolega valvata!…"
Hippokratese mõtte juurde tagasi tulles aga nii ongi, vähemalt vaese mehe puhul. Meil ei ole neid mune nii palju, mida korvide vahel jaotada, kui üldse. Munemise aeg on lühike. Tehnoloogia õppimisele kulub aga aeg, mis sageli on pikem, kui selle tehnoloogia enda elutsükkel võib olla.
Eriti tähelepanelik tasuks olla praegu täies elujõus tehnoloogiate osas.

Mida siis võiks ühele kompuutria ala tudengile ekspert soovitada? (btw, ma ei pea ennast sääraseks, aga ma refereerin siin teiste arvamisi)
Mis keelt uurida? Mis paradigmasse süveneda? Mida toob tulevik?


Elukogemus teeb paratamatult ettevaatlikuks, nii olen sunnitud süüvima enne (taas)vettehüppamist üsna põhjalikult teemasse. Ühes võib olla kindel - elame huvitaval ajal ja endiselt on arvutiala perspektiivikas, mitte hääbuv tehnoloogia.

Praeguste trendide kestes ollakse endiselt kohas, kus toimub "ristumine peateega", ainult et milline tehtud valikutest võiks olla see "õige"?
Äkki aitaks tutvumine ajalooga. Miks mitte eruditsiooni lisada seda käsitlust järgides?
James Iry programeerimise ajalugu
Parim selles vallas.
Pisut pikemalt ja tõsisemalt asja üle mõeldes - miks ikkagi kuldsed kuuekümnendad ja 70-ndate algus pani kõik peamised paradigmad paika?
Vaadake üle - 
Bret Victor: Tuleviku programmeerimine
ja lisamaterjalid:
Bret Victor, lisamaterjalid
Eriti selle esitluse lõpus väljatoodud küsimused panid mõtlema:
See oli aeg, kus teadlased "ei teadnud", millest räägivad. Sellised
ajad on kõige viljakamad, võrreldes aegadega, kui äkki teatakse (ja tegelikult
selgub, et ikkagi ei teata), millest räägitakse.
Üks nüanss lisandub veelgi: ARPA-st sai DARPA ja alates 1973 finantseeriti vaid neid ettevõtmisi, millel oli otsene seos sõjandusega. Ja lisandus kõik muu bürokraatia - tuli hakata projekte vorpima, et üldse raha saada. 

Praegu aga on aasta 2014 ja kompuutriteooria on endiselt arendamas neidsamu ideesid, mis 50 aastat tagasi. Tehnoloogia tikub muutuma kiiresti, inimesed aga võtavad need muutused omaks aeglaselt. 

Vaatleks siis mõningaid meie praeguse kompuutriajastu märksõnu lähemalt, ehk muudab see minu praeguseks hetkeks arvutitega tegeleva blogi veidi vaheldusrikkamaks. Selle blogijutu lõpetuseks alustaksin andmebaasidest, mille vahest kõige kujundlikumaks märksõnaks on kurikuulus
COBOL 


I COBOLI NEEDUS

Sageli määrab tehnoloogia olemasoleva  taseme meie … soovmõtlemine.

Üheks selliseks soovmõtlemise osiseks on ka instinktiivne viha bürokraatia vastu. Pisut leebem võiks ju see tunne olla selle bürokraatia "leevendamise" ühe vahendi - arvutiprogrammi osas, mis seda bürokraatiat haldab.
Võib ju juhtuda, et ametnik  teie fenomenaalse programmi mõjul muutub äkki valgustunuks?

Selliste asjadega aga ülikooli ajal vaevalt, et tasub tegelda ja ilusam ja popim on uurida objektide maailma (mida juhatatakse värvikalt sisse mingite simulatsiooninäidetega ei tea mis planeedi ökosüsteemist). Veel võimekamad võivad oma ajud murda lambda arvutuse sügavustes.
Ühel ilusal päeval tuleb teil ikkagi lahendada mõni selline probleem: persooni käest on vaja teada saada, mis on tema nimi või isikukood ja saadud andmed kuhugi üles kirjutada.
Eriti kerkib selline vajadus päevakorrale, kui otsite tööd ja leiba, sest mingite oleste tegemised teie väljamõeldud mänguökosüsteemis millegipärast seda ei kindlusta, kui mõned eriti õnnelikud ja talendikad mänguloojad välja arvata. (tõsi, meil siin Tartus vist saab mängude loomisega koguni leiba teenida).  Ja siis selgub, et teie käest tahetakse mingit kodulehte, mis müüb näiteks mingisuguseid torujuppe ja kõik ilus piirdub kliendiandmete kogumisega, kliendi krediidikaardi tühjendamisega ja veel mõne sarnase pudi-ludiga.
Aga akadeemilisel mesinädalate perioodil sellega tegelema ei pea ja siis äkki peab seda tegema päris palju, koguni nii palju, et need akadeemilised uudsused ununevad üldse. 
Ja nii nagu 10 või 30 aastat tagasi jäävadki need akadeemilised uudsused vaid akadeemia nelja seina vahele ja kodeerijad visataks tänavale tööd ja leiba otsima ikkagi eluks üsna ettevalmistamatult, sest kihvtide objektide maailma ja funktsionaalse maailma vahele on akadeemikutel ära ununenud kõige tähtsam asi, mida arvutid praegu teevad - see on ANDMETÖÖTLUS. 
Alguses on ANDMED. Kogu selle IT revolutsiooni väga lihtne eeldus on inimeste (mitte ainult bürokraatide) soov oma andmetega hakkama saada. 
Ja ometi õpetatakse arvuti eriala praegu enamasti nii, nagu oleks andmete töötlemine kõige teisejärgulisem asi, mis tuleb iseenesest. 
Keegi ei taha tunda pärmi maitset taignas, mis tänu pärmile on kerkinud 
Ja andmed ei ole selle kõige juures mitte kuhugi kadunud, vaid neid tuleb järjest juurde.
Aga andmed ei ole esimese klassi kodanikud selles süsteemis, vaid mingi tüütus, millega tegelemiseks ehk enam sobilik on rekursiivne kustutamine. Arvuti saab sellega imelihtsalt hakkama.
Vastupidise operatsiooniga aga arvuti enam hakkama ei saa. 
Ja iga päev toimuvad ikkagi täpselt samad väikesed tragöödiad personaalsetes arvutites, kord läheb kõvaketas katki, siis ebaõnnestub mingi install, siis jälle kasutaja ise on liiga hoolas olnud mõne kustutamisega. … See toimus ja toimub aastast aastasse ja mingi Moore seadus ei päästa, vaid on pigem nuhtluseks, sest seda nodi, mida varundada, on järjest rohkem ja mõnikord võib mõni varundus võtta päevi aega.
Äriloogika sellist korralagedust ei võimalda taluda ja seetõttu on välja arenenud andmebaasisüsteemid. 
Üheks esimeseks kõrgtaseme keeleks, kõrvuti Fortraniga, sai selle loogika haldamisel COBOL.
Hoolimata akadeemikute leiutatud ALGOList, rääkimata muudest kõrgtaseme saavutistest, kirjutati 60-ndatel, 70-ndatel, 80-ndatel ja 90-ndatel aastatel endiselt ärirakendusi COBOLis.
1997 tehtud ülevaatest järeldub, et enamik ärirakendusi on endiselt kirjutatud COBOL-is.
200 miljardit rida koodi - umbes samas suurusjärgus on Hiina müüris telliseid. 80 % ärirakendustest .
COBOLI järel tulid aga teised andmebaasikeeled, näiteks minulegi "ad nauseam" tuttav Foxpro.

Kuid COBOL, see polnud veel kõik. Selleks, et andmetega viisakalt ümber käia, tuli leiutada andmebaasi mõiste ja eraldada kaks asja teineteisest: programmid, mis selle andmebaasiga tegelesid ja andmebaasisüsteem. 
See võimaldas andmetega tunduvalt viisakamat ümberkäimist, sest andmebaasisüsteem ei lubanud programmidel enam igat asja teha ja hoolitses oma terviklikkuse eest ise. Et andmebaasile ligi pääseda, tuleb teha päringuid ja lisamise ja uuendamise käske ja seda käsitleb SQL nimeline keel.
Andmebaasi andmete loogikat aga käsitleb relatsiooniliste andmebaaside teooria, üks õnnestunumaid leiutisi programmeerimise ajaloos kõrvuti funktsionaalse programmeerimisega.
Matemaatikageenius Edgar Codd on selle taga seisev isiksus ja ma arvan, et ilma selle inimeseta oleks maailma andmekäsitlus oluliselt teistsugune ja vaevleksime endiselt samade hädade küüsis, mis 60-ndatel. Siis olid ka andmebaasisüsteemid, kahjuks mitte nii arenenud, üks selline andmebaasisüsteem kujunes välja ameeriklaste Kuu vallutamise käigus, et kuhjunud dokumentidega hakkama saada 

Mingist ajast alates, tinglikult  2005 algas aga järjekordne "revolutsioon" või vähemalt algas järjekordne revolutsiooni katse, et  jagu saada 
COBOL-i needusest, andmetest ja sellele lisandunud relatsiooniliste andmebaaside teooriast, millest kahjuks põhjani ei olnud palju võimelised aru saama. Revolutsiooni põhisisuks võiks olla relatsiooniliste andmebaaside ranguse leevendamine, et paremini toime tulla "suurte andmemahtudega", ("big data").
Üheks revolutsiooniliseks tõukejõuks sellele pöördele on kahjuks usk, et kõik siin maailmas on taandatav objektidele. See objektiusk sai alguse 80-ndatest ja kuigi ta tõi suhtelist edu, ei allunud relatsioonilised andmebaasid sellele mitte. Aga kui andmed objektidele ei allu, siis häda …
andmetele. 
Teooriakse nimetatakse seda objektide ja relatsiooniliste andmete impedansi 
probleemiks. Relatsioonilised andmebaasid selles on aga küllaltki rangelt defineeritavad nähtused (objektideks neid ei anna ümber lõikuda, kui mitte kasutada üldobjekti "andmebaas", mis jälle midagi ei lahenda). Andmete puhul saab järeldada enam-vähem selgelt, milline on selle andmestruktuuri "normaalkuju". Puhh.
 Seevastu objektide maailmaks lahutamise jaoks mingid üldised juhtnöörid puuduvad. See loob olukorra (katsun sellest rääkida järgmises teoreetilises loos OO kohta), kus õnnetut õppurit hurjutatakse sageli sellega, et tegemist ei ole "tõelise" OO-ga. 
Mis aga on see "tõeline", jääbki sageli saladuseks.
Protseduuriliste programmide puhul seda probleemi väga ei tekigi. Asi on lihtsalt selles, et protseduuriliste keelte paar põhistruktuuri, if, while, for ongi peaaegu kõik, mida alustaja peab teadma…
Lisaks see siis muidugi ka, et GO TO on kahjulik.
See on aga  täiendav pluss vanale protseduurilisele maailmale, sest täna ei ole väga selge, mida ikkagi programmeerija peab teadma või mis stiili eelistama.

Olen üsna kindel, et relatsioonilised andmebaasid kahjuks või õnneks on  selleks välja mõeldud, et jääda.
Et revolutsioonide ja manifestidega matemaatilist loogikat ei võida… 
Ja seetõttu tasub pigem panustada andmebaaside loogika uurimisse, kui seda eirata. Moed tulevad ja lähevad, andmebaas alati jääb … ja kunagi ehk jõuab ka operatsioonisüsteemide tegijate teadvusesse tõsiasi, et ka kõik andmed, mis seal arvutisüsteemis olemas on, moodustavad andmebaasi ja peaksid olemas sama kaitstud, kui tänapäevane korralik äriandmebaas.
Näiteks võiks kasutajal olla võimalus taastada oma kustutatud faile, unistus, mille täitumist olen oodanud nüüd vist juba 25 aastat. Ja uue arvuti ostmise järgne kolimine võiks olla midagi väga lihtsat, mitte tüütu, ja vigaderohke isiklike arhiivandmete kopeerimine, mida M$ vaid raskendab…

Andmebaaside teema lõpetuseks aga tekkis kiusatus uurida, kes ikkagi on selle COBOL-i "needuse" taga, mis akadeemikutel ja "tõelistel" programmeerijatel meele nii kibedaks teeb.
Teame tõenäoliselt päris hästi või oleme vähemalt kuulnud, et Alan Turing leiutas Turingi masina, või et John McCarthy LISPI. 
Niklaus Wirth-i loominguks on programmeerimiskeel Pascal ja nii edasi…
… Mõnikord aga saab kuulsaks lihtsalt sellega, kui GO TO kuulutada kahjulikuks:
(Edsger W. Dijkstra).

Seevastu Grace Hopperi, COBOLi looja nime tõenäoliselt teavad vähesed. Ka mina kuni viimase ajani ei  teadnud, kuni lõpuks tuli mõte värskendada oma mälu relatsiooniliste andmebaaside osas. 



















Jutus tuginen põhiliselt Kurt Beyeri käsitlusele (vt. Kurt Beyer, loeng Grace Hopperist).
Grace Murray Hopper sündis 9 detsembril 1906, nii, et põlvkondliku kuuluvuse mõttes ei oleks temal tulnud arvutitega mingit pistmist teha.
Aga elu tahtis teisiti. Ta lõppetas Vassari kolledzi, ning seejärel Yale ülikooli, 
kõik suurepäraste tulemitega ja õpetas Vassari kolledzis matemaatikat, kuni algas sõda. Pearl Harbori järgselt taotles ta kolledzist töölt vabastist ja astus mereväkke, saades ohvitseri väljaõppe. Sõjaolukord tingis selliste võimaluste tekke ka naisterahvastele, kuigi siin oli probleemid - Grace Hopper oli juba 38 ja kaalus normist vähem. 
Kuid mereväes leiti temale siiski rakendus arvutite alal, sest just siis oli koostöös IBM-ga Howard Aikenil valmis saanud kolakas nimega Mark I.
Nii et küberlaevaks, kuhu Grace määrati, sai Mark I ja teda loetakse 3-ndaks persooniks ajaloos, kellel oli võimalus seda kolakat "programmeerida". 
Tänapäevast arvutit see asi siiski ei meenutanud. Mõõtmed aga olid vägevad, 16 meetrit pikkust, 2.4 meetrit kõrgust, 800 km. kaableid …
Arvutil ei olnud "if" võimekust ja tsükliks tuli programmeeriv paberlint otsipidi kokku kleepida. 3 lihtoperatsiooni sekundis, korrutamine võttis mitu sekundit, jagamine 15 sekundit, logaritm terve minuti. 
Ometi arvutati selle aparaadiga välja aatompommi käimapanekuks vajalikud ülesanded (implosiooni modelleerimine). 
Howard Aiken ehitas valmis Mark järgmised versioonid, Mark II, Mark III.
Mark II jäädvustus arvutiajalukku peamiselt reaalse putukaga, mis tema releede vahelt välja õngitseti, selleks oli üks õnnetu koiliblikas.
Grace Hopper oli tollal Mark II-ga ametis ning tõenäoliselt ehk ei oleks ilma tema populariseerimiseta see termin nii laialdaselt kasutusele tulnud.
Mdx, termin  "bug" oli siiski ka varem raadio- ja telegraafiaparaatide puhul kasutusel. Aga siin on siis selle originaalse putuka foto:




Sõja lõppedes Hopperi teeneid mereväes enam ei vajatud. Grace leidis enesele rakenduse UNIVAC arvutite programeerimisel. Need masinad said üsna populaarseks pärast seda, kui UNIVAC kompuuter suutis ennustada päris hästi presidendivalimiste tulemeid 1952, kus masin ennustas Eisenhoweri suurt võitu. Esialgu ei julgetud sellist ennustust isegi avaldada, see tuli ilmsiks PÄRAST valimisi, et UNIVAC ennustas valimistulemeid täpselt.
Grace Hopperi üks suurimaid leiutisi aga tekkiski sellel ajal. Ei, seda ei teinud von Neumann ega teised matemaatikageeniused. Nendel inimestel ei tulnud tollal pähegi mõtet, et suure kolaka aega võiks raisata millegi nii banaalsele, kui näiteks …assembleri käskude ümberpanemisele bitijadadeks. Inimesed sobisid selleks tööks vägagi hästi. 
Ja kolakate endi juures toimetavatel kodeerijatel, nii imelik, kui ka pole, ei olnud ka erilist vaimustust selliseks pöördeks. Omamoodi uhke tunne on olla nende releede ja vaakumlampide peremees, maag või mustkunstnik, kellest sõltub õige koodi ja õige tulemi väljavõlumine…
Grace käsitles aga asju teistmoodi - tema jaoks oli väga tähtis mõte, et ka tavaline surelik võiks neid arvuteid kuidagi programmeerida.
Ise ta väidab, et 1952 lihtsalt ei mahtunud ühelegi inimesele pähe mõte sellest, et arvuti ise võiks koostada enesele programmi. 
Aga 1952 oli tema esimene, kellel oli olemas töötav kompilaator. 
Selle kompilaatori keele elementidest aga pandigi kokku programmeerimiskeel nimega COBOL, seda juba aastal 1959, kõrvuti FORTRANI ja LISP-ga. 
Aga sellega see lugu veel ei lõppenud. Grace teeneid vajas Ameerika Merevägi ja nii leiame ta töötamas mereväes 1966-1986 (läks erru 80. aastasena) ning välja teenimas koguni kontradmirali tiitli.
Teisi selliseid väljapaistvaid admirale-programmeerijaid arvutiajalugu tänaseni ei tunne.
Muuseas, tema seinal oli selline kelle, mis käis teisipidi, mitte päripäeva.
Äkki ongi väljapaistvus üks saladusi võime ja soov asju panna teistmoodi käima, mitte nii, nagu seda "alati on tehtud".