Programmeerimise paradigmadest: Millist korvi valvama hakata?
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.
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".
0 Comments:
Postita kommentaar
<< Home