II Objektid kuulutatud kahjulikuks

Koodimaailmas natukenegi asju uurimas käinu teab, et koodiususõjad on siin igapäevane asi.
Ja mida vagam ja üllam on bitirüütlite kood eemalt vaadates, seda sügavam võib olla põhi.
Ja igal priiuserüütlite sektil on erinevatel aegadel käigus olnud erinevad reliikviad. Tänane jutt on siis praegusest koodireliikviast nimega Objektorienteeritus.
Kuid selleks, et selle reliikvia ümber toimivate vana- ja uususuliste vahelist vaidlust mõista, peab teadma eelnevate ristisõdade ajalugu ja selleks peab jätkama COBOL teemat.
Eelmises loos rääkisin põgusalt ühest varasest koodirüütlite kantsist nimega masinkodeerimine. Seal elunev kogukond oli üsnagi häiritud Grace Hopperi kompilaatorist, mis mitte ainult et ei saanud aru müstilistest assemblerikäskudest, mis oleks veel olnud kuidagi talutav, aga ta sai aru "puhtast" inglise keelest. See "puhas" inglise keel oli siiski väga, väga kaugel sellest, mis on meie mõistes inimkeel, aga masinkodeerijad olid sunnitud sellele alla vanduma ja möönma, et see oli tunduvalt lihtsam, kui nende kokkupandud bitijoru. Masinkoodis programmeerimine siiski ei hävine iial. Olemuslikult on alati tarvilik kellelgi kirjutada valmis näiteks kompilaator või vähemalt osa sellest masinkoodis, küsimus on vaid selles, et kui on võimalik oma elu lihtsustada, siis seda tasuks ka teha.
Miks selline praegu mõistusele adumatu vastuseis ikkagi tekkis?
Selleks peab mõistma kultusepreestri loogikat. Kui oled ise ikkagi istunud mingi sarnase sisuliselt 0 ja 1 välja ajava masina taga, on ehk see veel paremini mõistetav, aga sama tunne valdab kõiki, kelle käes on mõne võimsa tehnilise imevahendi rool….
 Sina oled see maag, võlur, kes toimetab muu maailma ja võlukasti vahel ja keegi teine ei jaga seda loogikat (ja ei tohigi jagada) ja siis tuleb üks vanaldane energiline daam (kes hoiab oma seinal kella, kus osutid käivad tagurpidi) ja ütleb, et preestrite asemel saab iga firma oma kontorisse palgata mõned blondiinid, kes lihtsas keeles kirjutavad üles, mida arvuti peab tegema.
Selleks keeleks sai COBOL ning ime küll, masin kompileerib pärast mõningat mõtiskelu kokku koodi, mis … üllatus üllatus, tegigi seda, mida blondiin õpetas.
Pisut hilinenult võttis arvutimaailm selle mõtte üle ja …. üritas unustada COBOL-i.
Kordan veel üle - keegi ei taha tunda pärmi maitset taignas, mis tänu pärmile on kerkinud. Pärmiks sai äriloogika, vajadus andmeid töödelda ja midagi toimivat arvutitest kätte saada mõistliku hinnaga.
Ja veel on üks asjaolu, mida akadeemilised koodipreestrid ei taha tunnistada: LIHTSUS, tõsi, sügavate puudustega lihtsus… analoogiks ehk vene tehnika. Toimib, robustne, teada head ja vead … aga toimib.
COBOL ja tema järglased (näiteks dBASE keeled) olid ja on lihtsad keeled. Nende "lihtsate" keelte abiga saab kahtlemata tekitada väga segast koodi, kuid keskmiselt oli iga keskmine blondiin võimeline koodi omandama mõne nädalaga ja asjad … toimisid.
Kuigi jah, paljud tööd ja vaeva jäi ja jääb selle koodi käimaajamisega.

Akadeemikud aga taastasid oma reputatsiooni kiiresti.
Loodi grupp, mis pani kokku arvutikeele ALGOLi standardi, mis kajastas tolleaegsete arvutiteadlaste parimaid püüdlusi. Seetõttu see keel ja eriti tema järglased saidki tunduvalt paremad kui "esimesed vasikad" nimega FORTRAN ja COBOL.

Ja ma rõhutaks veel: säilis suhteline lihtsus.
Keda sisuliselt huvitab - programmeerima saab hakata, teades vaid paari põhikonstruktsiooni:
if else …elseif lausung ning for …. ning ongi kõik.
Kes tahab hakata kodeerima, unustage preestrite manitsused ja hakake kohe pihta. Enamik moodsaid keeli sisaldavad endiselt neid põhilisi konstruktsioone ja kõike ülejäänut võib ka ignoreerida.
Näites JavaScript on üks selline keel, millega võib igaüks kohe pihta hakata, aga ka Python. JavaScripti tohutuks eeliseks on see, et iga tänapäevane sirvik sisaldab seda keelt ja seetõttu võib igasse HTML dokumenti selle keele skripte sisse kompileerida.

ALGOL-i aluseks aga keeleteadlase  Noam Chomsky artikkel
"On certain formal properties of Grammars"
Selle põhjal osati kirja panna oma loodava keele "grammatika" ning programmeerimiskeelte loomine sai lihtsaks tegevuseks.  Märkigem, et Chomsky ei ole arvutiteadusega seotud ja ometi põhinevad tema ideedele kaasaegse programmeerimise alused.
Varasemates keeltes FORTRAN ja COBOL, pärandina masinkeelest, kus teisiti ei saanudki mingit otsustuste järgset hargnemist teostada oli aga veel olemas GOTO.
Koodilasu tekitamisest FORTRANI ja COBOLI järglased meid ei säästnud ja tänaseni ei ole olemas võlukepikest, mis seda suudaks. Ükskõik, mis reliikviatest käib jutt, need on ainult reliikviad. Viimseks ei jää ükski neist.
Ja nüüd tuligi akadeemikutele appi maagiline GOTO, kogu kurja juur.
"GO TO statement considered harmful"
on artikkel, mille järgi praegune põlvkond arvutiteadlast Edsger W. Dijkstrat parimini tunneb ja see on tõenäoliselt ajalooliselt üks tsiteeritavamaid artikleid üldse arvutiteaduses.
Mitte sisu poolest, see on sama lihtne, kui vana ja uueusuliste vaidlus ristilöömise üle. Vanausulised toetasid kahesõrme kommet, uueusulised kolme sõrmega ristilöömise kommet.
See artikkel oli GOTO ususõja manifest ja … selle tagajärjel naudime nüüd GO TO vabasid programmeerimiskeeli.
Ega seda õnnetut GOTO-d tõesti polnudki vaja, aga meil ei ole üldse vaja läinud paljut muudki. Ei ole üldse selge, kas programmid ilma selle GO TO-ta läksid natuke paremaks.
Mingeid märkimisväärseid uurimistöid selle kohta ei ole tehtud. See alandaks usutunnistuse tavaliseks väiteks, mida see aga ei ole. Praegu on see tees kooliõpikutesse sisse raiutud ja häda õppurile, kes julgeb kahelda selles väites. Võimalik, et see ususõda, nagu järgnevadki, valmistas pinda ette sellele veel  saabuvale kaunile päevale, kui mingi kaval doktriin teeb programmeerimise tõesti meeldivaks ettevõtmiseks.

Ja nüüd täiesti tavaline asi ususõdade puhul: näidishukkamine. Kuigi COBOL ärimaailmas, nagu eelmiseski postituses mainisin, omas kaalu vähemalt 20 sajandi lõpuni, ei räägitud akadeemias sellest enam sõnagi.
Halastuslasu sooritas  Dijkstra:

COBOLI kasutamine invaliidistab mõistuse. Seetõttu tuleks selle õpetamist vaadelda kriminaalkuritööna.

Nojah. Seebiooperite vaatamise kohta ei ole mul õnnestunud välja selgitada, mis seisukohta Dijkstra omas. Põhja Koreas oli asi aga ühene - Lõuna Korea seebikate vaatamisega vahelejäänud hukati. Aga ELLUJÄÄNUD VAATAVAD edasi. "Elo lätt iks edesi ummamuuudu"… ütleks lõunaeestlane sellepeale.
 
Kuid lohutame kõiki COBOLI sõpru: sama Dijkstra on ütelnud objektOrienteerituse kohta nii:
 Objekt-orienteeritud programmeerimine on erakordselt halb idee, mis sai pärineda ainult Californiast...

Siin Dijkstra küll eksis - objektOrienteeritus mõeldi välja NORRAS ja selle asja autoriks olid Kristen Nygaard koos Ole-Johan Dahl-ga.
Esimeseks objektOrienteeritud keeleks oli SIMULA 67 ja selle kavandamist alustati 1961. 
See keel oli ette nähtud reaalse maailma asjade simuleerimiseks. (Algselt tegeles Kristen Nygaard Norra esimese tuumareaktori parameetrite rehkendamisega)
Palo Altosse tõi objektOrienteerituse idee Alan  Kay, 
keda loetakse programmeerimiskeele Smalltalk loojaks. 
Kahjuks Smalltalk ei ole omaette programmeerimiskeelena leidnud suurt rakendust.
Selleks aga, et OO saaks valitsevaks paradigmaks, lausa kultuseks, tuli leiutada programmeerimiskeel C, et sellele saaks lisada kaks plussi.

C keele tekkepõhjuseks sai vajadus vahepeal arvutikolakatele tekkinud operatsioonisüsteeme paremini kirjutada. 60-ndatel kirjutati neid assembleris.
Esimene kaasaegne operatsioonisüsteem, tänini kõikide normaalsete operatsioonisüsteemide esivanem, oli aga UNIX.

Visandan siin C ja UNIX tekkeloo, võin detailides olla ebatäpne:
1972 tekkis operatsioonisüsteem UNIX, selle põhiautoriks või kodeerijaks oli Ken Thompson ja ta kasutas omatehtud keelt B, mis enam ei olnud assembler.
1972 lõi Dennis Ritchie B keelest keele C, mis B-d kõvasti täiendas ning kompileeris põhilise osa operatsioonisüsteemist UNIX oma C keeles. Koos Brian Kerninghamiga kirjutasid nad valmis uskumatult igava pealkirjaga bestselleri
The C Programming Language, mis autorite järgi sai lühendi K & R ja mida kuni 90-ndate lõpuni iga reaalprogrammeerija käsitles oma piiblina, k.a mina oma füüsikukarjääri ajal 80-ndate lõpus. 
Brian Kerningham sai eriti kuulsaks oma programmiga "Hello World", mis nüüdseks on tirazheeritud kõikidesse programmeerimiskeeltesse ja mida üritavad taastekitada oma arvutis/mobiilis/tahvlil miljonid, äkki varsti juba miljardid algajad arvutihäkkerid, olgu nende valitud õpikeeleks mistahes 10000-st praegu kättesaadavast programmeerimiskeelest.
C keel murdis eelarvamuse, nagu peaks arvutite operatsioonisüsteemi kirjutama  assembleris. See idee on  nüüdseks jõudnud igale poole - isegi mikrolaineahju või pesumasina juhtprogramm on nüüdseks on kirjutatud C-s või mis veel hullem, C ++ -s. Tollal oli see tohutu edusamm ja murrang süsteemiprogrammeerijate teadvuses. C stiil (äärmiselt kompaktne, sageli suhteliselt raskesti loetav, kuigi vanad C tekstid on tänapäeva krüptikaga võrreldes siiski kukepea) sobis süsteemiprogrammeerijate mõttelaadiga, kelle arvates 1 rida koodi on alati parem, kui 2 rida ja kokkuhoitud sümbol on kokkuhoitud mälu ning kõige kriteeriumiks on praktika - s.t. masina kulutatud aeg millisekundites ülesande peale. 
Endiselt on C asendamatu töövahend seal, kus määravaks on programmi täitmise aeg ja seetõttu süsteemprogrammeerijaks pürgijatele vältimatu asi selgeks saada koos C++, C# või mõne muu C OO dialektiga.

OO ajastu alguseks aga

tuleb lugeda aastat 1979, kui Bjarne Stroustrup  sai ülesandeks oma doktoritöös tegelda Simula programmeerimiskeelega.
Bjarnel tekkis mõte vana head C-d laiendada. Esialgu sai ta valmis C keele koos klassidega (C with Classes), mille peagi nimetas ümber C++. 
Esimene C ++ alane bestseller 
"The C++ programming language" ilmus 1985. Uusim C++ kehtiv standard nägi ilmavalgust 2011.
Võib julgelt öelda, et iga sügavamalt progammide hingeelusse tungida tahtev isik ei pääse C -le ühe juurdeliitmise operatsioonist kuhugi (++ tähistab C keeles ühe juurdepanekut).
Stroustrup sai hakkama sellega, millega Alan Key ei saanud - keel ja seejärel objektorienteeritus muutus valdavaks paradigmaks.
C++ on tunduvalt rikkam igat sorti raamatukogude/ teekide poolest. Paljud asjad, mis senini oli vaja teha käsitsi, läksid automaatseks, tuleb üles leida vastav teek, objekt või klass ja kasutada seal kirjapandut alamprogrammi / funktsiooni. Keel läks rangemaks, vigu tuli ka vähem ja lisatööd oli ka vähem. OO sobib suurte süsteemide kokkupanekuks, väikeste programmijuppide puhul võib kasu olla täiesti puudu või marginaalne (minugi poolt tehtud väike Trips-traps-trull ei tundu OO-sse ümberpanekust midagi võitvat).
Ka mujal, isegi nendes keeltes, kus ei räägitud väga palju objektidest, tekkis kasulikke teeke, graafilisi objekte j.m.s., mis elu lihtsamaks tegid.

Ometi on täna, anno 2014 tekkinud ka igati põhjendatud kriitika OO paradigmale. Nii nagu "struktureeritud" programmeerimine püüdis ilma GOTO-ta välja näidata, et nüüd on asjad väga hästi, programmid palju lihtsamad, kui varasemal (ütleme siis COBOL-i või FORTRANI ajastul), vaadeldakse OO-d tänapäeval kui võluravimit, millega iga programmi saab muuta tunduvalt paremaks, kui enne OO-d. 
Võib isegi väita, et OO oli ehk natuke vale valik ja "õigem" valik oleks olnud 70-ndatel panustada Funktsionaalsesse Programmeerimisesse (FP). Isiklikult ma kaldun kahe suure pesapallimeeskonna, FP ja OO duellis FP poolele, aga FP peab oma eelised panema maksma. Selleks peab aga FP omandama kõik OO kasulikud nipid ja tegema ennast laiale publikule arusaadavamaks. Ikkagi tuleb kirik lõpuks ehitada keset küla. Ja veel üks prognoos - lõpuks sekkuvad mängu andmebaasid, oma relatsiooniliste tabelitega, millega võitnud paradigma peab hästi hakkama saama (ja omandama andmebaasidele vajalikud mängureeglid ja nipid). Otsustavaks kaalukeeleks aga saab kõigele paralleelsus - OO ei suuda sellega piisavalt hästi hakkama saada, FP programmid suudavad.

Mis on OO?

Esitan siin oma, referatiivse tegevuse tagajärjel kujunenud esialgse visiooni.

Lähtun õpikutest ja oma teksti alguses visandatud joonisest. 
OO lähtub objektidest. Sageli saab objektidest moodustada puukujulise süsteemi, nagu joonisel kujutatud: koer ja lammas on mõlemad loomad.
Koer ja lammas on loomad klassi alamklassid, kellel võivad olla omad alamklassid.
Igasse klassi kuuluval objektil on hulk omadusi. Osasid omadusi nimetatakse andmeteks - koeral siis tõug, kaal, peremees ... ja nii edasi ...
Osad omadused on tegevused, mida saab objektiga teha, neid nimetatakse meetoditeks. (protseduurid protseduurilises paradigmas, funktsioonid funktsioonaalse programmeerimise paradigmas). Meetodite eripära on see, et neid saab rakendada ainult sellele objektile, mille alla need meetodid kuuluvad.
Varem või hiljem leiutas iga OO keel sellele reeglile erandid, sest muidu ei saaks üldse elada ....
Matemaatik olevat ühe definitsiooni kohaselt automaat, mille ühest otsast antakse sisse kohvi ja teisest otsast tulevad välja teoreemid.
OO programmeerijale joodetakse samuti sisse kohvi, välja tulevad aga objektiklassid. Selleks tuleb eeldatavalt kasutada teiste (ülem)programmeerijate poolt loodud superklasse.
See, kuidas OO programmeerija seda teeb, peab olema pimedas ja varjatud, s.t. privaatne. Selleks on olemas ka privaatsed andmed ja privaatsed meetodid.
Aga väljapoole peab paistma pakend või liides - mingid kindlad meetodid ja mingid kindlad andmed, mida teistel programmeerijatel võib ka vaja minna.
Objekte on võrreldud nimisõnadega. Kõik tegevused peavad olema mingi nimisõnaga seotud. See on mõnikord hüve, näiteks vispel kuulub ju kööki ja praetakse midagi köögis, mitte elutoas. Aga praadida võidakse mitut sorti "objekte" ja on kohe näha, et kõik asjad OO-s ei ole roosilised, sest kartul.praadi meetod objekti liha jaoks jälle ei sobi , aga põhilises on ju kõik sama... 
Siin tuleb appi superklass, teeme superklassi toiduained ja sinna üldise protseduuri praadi.  
Toiduained.praadi olemasolul kartul.praadi ja liha.praadi võtavad oma protseduuri superklassist. Selline protseduur päritakse superklassilt.
Siin me näeme ka OO positiivset poolt - selleks, et köögiasjandust programmeerida, tuleb asju klassifitseerida või korrastada ja korralikul perenaisel peavadki asjad olema süsteemis. Nii et selline jäikus on toonud natukenegi korda muidu kaootilises progemise maailmas … diktatuur on halb, aga keegi ei ole midagi paremat ka välja mõelnud...
Mõnikord aga viskab (eriti meestel) ära, kui selleks, et muna praadida peab kurat teab mis super ja alamklassidega jamama ...
(superklass toiduaine, superprotseduur toiduaine.praadi, köök.sealOlevadAsjad.köögiRiistad.vispel.vispelda(munad, piim).... ja nii edasi...)
Hästi toimib OO sellises heas konveiersüsteemis, kus tegevused on üsna selgelt seotud objektidega ja objektid ongi kesksed tegelased.
Kinnisvarahaldus on hea näide ehk. 
Meil Eestis on OO mõtlemine väga levinud, näiteks ÜLIKOOLIS. Kõige tähtsamad on majad. Näiteks on meil 2 väga suurt ja küllalt pompöösset raamatukogu: Tartus ja Tallinnas. Aga raamatuid ei ole (näiteks ei ole OO keele Java kohta mitte midagi, v.a. 10 aasta tagusest perioodist).
Järjest ehitatakse pompöösseid klaasist õppehooneid (vanad müüakse maha või lammutatakse ära, peahoone ehk jääb). Oma inimesed aga ei ole mingi väärtus - küll kusagilt uued saab. 
OO puudused tulevad ilmsiks, kui esiplaanil on tegevused, mida ei saa seostada 
objektidega - näiteks kontoritöös nii tavalise tooli, kohviautomaadi või arvutiga - ja hierarhiline jäikus ei toimi. 
Siis on OO nagu viies ratas vankri all.
Keerukamate struktuursete suhetega on ka raske hakkama saada. Kui suhted on puukujulises süsteemis, on kõik OK, aga kõige tavalisema relatsioonilise andmebaasiga jääb OO hätta.
OO alternatiivi - Funktsionaalset programmeerimist  aga võrreldakse verbides mõtlemisega. See on sageli loomulikum, sest programm on enamasti mingi tegevus, objektid seal vahel tänapäeval on ka olemas, aga neile ei tohi anda niivõrd tähtsat rolli, kui OO-s on välja kukkunud.
Tegevused on paindlikumad, häälestatavamad ja üksteisega paremini kombineeritavad. Tegevuste sisse on juba programmeeritud paralleelsus, aeg, üheaegsus. 
...
btw: kui tekib maht, tahaks ka FP kohta samaväärselt kriitilist ülevaadet kokku panna, sest ususõdade puhul leiab piisavalt ka neid, kes on FP kohta huvitavalt öelnud. 


Aga aitab lobast, jõuame autoriteetide tsitaatide juurde:

"Objekt orienteeritud programmeerimine on erakordselt halb idee, mis saab pärineda ainult Californiast."

Edsger Dijkstra

      

"Objektorienteeritud disain on sama, mis Rooma arvud arvutamises"

 Rob Pike

      "Fraas 'objektorienteeritud' tähendab palju asju. Pool on ilmsed, teine 

       pool aga koosneb vigadest."

Paul Graham 

       "Objekt orienteeritud mudel teeb kergeks programme konstrueerida juurdelisamise meetodil. Mida see sagli praktiliselt kaasa toob, on see, et ta võimaldab struktureeritud meetodil kirjutada spagetti koodi."

Paul Graham 

Pärimise realiseerimine põhjustab samasugust põimumist ja rabedust, mida on jälgitud goto avaldiste kasutamisel. Tulemina kannatavad OO süsteemid keerukuse käes ning ei ole taaskasutatavad.

 John Ousterhout

Sageli on elegantseks realisatsiooniks lihtsalt funktsioon. Mitte meetod. Mitte klass. Mitte raamistik. Lihtsalt funktsioon.

 John Carmack

Probleemiks objekt-orienteeritud keeltes on see, et nad saavad kaudselt kaasa kogu selle keskkonna, mida nad endaga kaasas tassivad. Sa tahad banaani, aga sa said gorilla, mis hoiab käes banaani ja koos temaga kogu dzungli.

Joe Armstrong

Kunagi armastasin objekt-orienteeritud programmeerimist. Nüüdseks kaldun arvama, et see on vandenõu, mis on kavandatud selleks, et hävitada nauding.

Eric Allman

Väga tähtis ObjektOrienteeritud koodi omadus on see, et see võimaldab väikestel, lihtsatel probleemidel näida suurte ja keerukatena. 

 tundmatu anonüüm

Aga nüüd üritan teid säästa lõpus toodud linkide läbijäramisest ja natukene ise kokku võtta, mida OO kohta on olnud öelda, järjestades neid asju enda järgi.

 I  OO haip ja reaalsus.

Kuigi ülikoolide õppeprogrammid esitlevad OO-d kui mitte just ainumõeldava, siis siiski valdava paradigmana koodinikerdamise vallas.
See ei ole nii. 
Näiteks andmebaaside programmeerimises ollakse endiselt hädas OO rakendamisega. Selle taga on lihtne asjaolu - andmebaaside loogika ei allu OO loogikale üldse.
vaadake [3]. Seal nimetatakse probleemi näitlikult "Vietnami sõjaks". Üritus andmebaase hakata programmeerima OO stiilis on seni läbi kukkunud. Ja juba möödunud sajandi 80-ndatel aastatel tehti manifeste, kuidas kõik andmebaasid hakkavad varsti OO välja nägema. 35 aastat võiks olla piisavalt pikk aeg, et manifeste realiseerida. Selgub aga, et suuremat pole välja tulnud. 
On tekkinud soov relatsiooniline andmebaaside teooria nurka visata ja teha omamoodi, OO andmebaase. Või vastupidi, visata mõte andmebaaside korral OO koodi kirjutada nurka ja teha rahulikult nii edasi, nagu kogu aeg on tehtud.
Ka veebiprogrammeerimine ei hiilga väga OO-ga. On küll olemas DOM, Document Object Model, aga selle muutmise ja näitamise koodid väga ei ole OO. 
Räägitakse, et javaScript on OO keel. Lähemalt analüüsil aga selgub, et ka see on natukene ülepakutud, et javaScriptil on küll võimalused OO programmeerimiseks, aga neid väga ei rakendata ja kui rakendatakse, siis igaüks teeb omamoodi - ei ole ühtset objektimudelit, ei ole klasse ja palju muud, mida OO vajaks (Veel vähem on PHP puhul OO-d rakendatud).
Võimaluste paljusus ja nende kohmakus tähendab aga, et ühest meeskonnast tulnud võib kasutada javaScirpti hoopis ühel moel ja mõelda OO-st javaScriptis omamoodi ... ja nii edasi.
Ühesõnaga - Veebiprogrammeerimine ei ole eriti OO praegu.
Kindlalt OO alla liigitatakse Java ja C uuemad derivaadid, C++ ja C#. Nii et nendes keeltes progejad võivad küll ennast OO programeerijateks kutsuda. Teistega pole see nii selge. 

II OO efektiivsus on endiselt mõõtmata.

Selle juurutamise ajal märgiti vaid, et vana, protsduuriline meetod tegelikult oli kiirem ja efektiivsem, aga see vist ei olnud oluline - Moore'i seadus tegi võimalikuks järjest ebaefektiivsema koodi kirjutamise, nii et see kedagi oleks väga häirinud.
Ok, tänapäeval ei ole see enam nii tähtis, aga tähtis võiks olla see, kui kiirelt programmeerija oma tööga hakkama saab. 
Ja siin on endiselt mõõtmata, kas mingi ütleme vaid protseduuriliselt töötama harjunud meeskond teeb valmis halvema koodi, võtab oma töös rohkem aega, teeb rohkem vigu või nende töö tulemus on halvemini loetavam, muudetav ...
Programmeerimise vallas on selliste asjade mõõtmine endiselt vaid helesinine unistus ja kõik otsustused tehakse kõhutunde põhjal, või üksikute näidete põhjal, mille puhul väga vabalt võib olla tegemist lihtsalt haipimisega.
Järelikult on see üldine probleem ja muudab vaidluse ka natukene mõttetuks, sest tuginema peabki vaid kaudsetele argumentidele, mitte otsestele.
Ometi on märgatud, et OO kood on MAHUKAM, s.t. rohkem ridu sisaldav.
OO kood ei ole samas kergemini muudetav. Pigem vastupidi, klassidesse sisseraiutud andmestruktuurid ja meetodid on raskesti muudetavad.
Veel hullem - superklassides tehtavad muudatused (isegi positiivsed) võivad kaasa tuua laviini - alamklasside kood jookseb kõik täiega pange.
Ka vigade avastamine on keerukas, sest viga võib peituda kusagil superklassis, mille puhul võib olla isegi puudu algtekst - on ette antud objekt, mis mingitel imelikel asjaoludel teeb imelikke asju. Ja juuniorprogejad peavas sellega lihtsalt leppima.
Hoiatatakse ka, et OO programmeerijad võivad hakata kirjutama massiliselt klasse, millest mingit kasu ei ole (koodi taaskasutatavuse eesmärgil).
Ja seda tõesti tehakse ja OO gurud ise ka hoiatavad selle eest...
Aga ikkagi ei saa väita, et OO oleks olnud viga või vale tee, sest selliseid asju ei ole osatud või tahetud mõõta.
Aga ei saa ka väita, et oleks õige tee ja ei saa vältida selliseid paradigma vigu tulevikus. 
Kui nüüd tuleb varjusurmast välja seksikam FP, võime olla 30 aasta pärast sama tõdemusega  - äkki FP oli viga.

III OO õppimine on raskem, kui vanema, protseduurilise raamistiku omandamine.

Lisaks kõigele on OO väga erinev erinevate keelte puhul, erinevad koolkonnad ja jüngrid mõistavad OO-d erinevalt. 
Võimalik, et praegune koodnikerdajate defitsiit on sellega seotud.

IV OO meetod ei ole toonud kaasa revolutsiooni ja uusi algoritme. 

Põhilised algoritmid on vaja realiseerida vanas, protseduurilises maailmas. Pigem on tegemist koodi korrastamise filosoofiaga, mis aga kahjuks eriti hästi ei toimi.
Seetõttu ei saa seda meetodit nimetada ka kuigivõrd revolutsiooniliseks.
Ka ajafaktor näitab seda - 35 aastat oleks piisav aeg enese tõestamiseks.
Süüdistatakse isegi autoreid, kes püüavad Donald Knuthi "Art of Computer programming" tekste ümber panna OO -sse. 

V OO-d praegusel kujul ei saa hästi paralleelseks teha

FP meetodid alluvad sellele hästi - siit ka minu panus selle paradigma kasuks.

.....
ja nii edasi ja nii edasi, nagu Kurt Vonnegut tavatses kirjutada...
Võtan nüüd pärast sellise diatriibi kirjutamist OO suunal ette Java keele ja küllap pärast näeme, kas minust on saanud OO jünger, kelle põhjamaine iseloom on halastamatu igasuguste kõrvalekallete suhtes OO -s sätestatud käitumisnormidest, või vastupidi - FP adept.
Ilmselt tõe tempel kerkib kusagile vahepeale või leiutatakse pärast Moore seaduse lõppu tõesti midagi uut ka programmeerimise vallas ...
Selle prognoosimiseks, mis aga saab, tuleb endiselt vaadata kohviube või edasijõudnutel kasutada
Math.random() funktsiooni.
FP suunal võtan mõttepausi. Aeg ei võimalda FP kriitikute ja pooldajate sõnasõda refereerida...

Linke OO kriitika kohta:

1) http://harmful.cat-v.org/software/OO_programming/


2) http://www.softpanorama.org/SE/anti_oo.shtml


3) http://blog.codinghorror.com/object-relational-mapping-is-the-vietnam-of-computer-science/

4) http://pivotallabs.com/all-evidence-points-to-oop-being-bullshit/

5) http://c2.com/cgi/wiki?ArgumentsAgainstOop