Trendid Java-maailmas 2016 – vaade Devoxxilt

Mattias Tiitson, Proeksperdi tarkvaraarendaja

11 – 13. novembrini toimus Belgias, Antwerpenis 3500 osalejaga Java konverents Devoxx, kus sain osa esitusest kaheksal paralleelsel rajal. Millised trendid valitsevad Java maailmas? Ilmselgelt on mu nägemus pisut kallutatud ja suuresti mõjutatud ettekannete valikust, kuid mõned mustrid joonistusid välja üsna selgesti.

Selle, 2015. aasta kindel hitt on Docker. Docker on vidin, mis võimaldab rakenduse koos igasuguste sõltuvustega pakkida konteinerisse. Miks see hea on? Sest rakendus töötab nüüd, kus iganes Dockeri põhi all on. Mingisugust keerukamat seadistust polegi vaja. Konteinereid on lihtne luua, hävitada ja taasluua. Järele proovides selgub üsna kiiresti, millest selline vaimustus.

Loomulikult on endiselt äärmiselt populaarsed pilvetehnoloogiad. Teenused nagu AWS pakuvad lihtsalt skaleeritavat infrastruktuuri. Huvitava kõrvalmõjuna võimaldavad nad mõelda infrastruktuurist kui commodityst. Sellega kaasnevad omakorda uued võimalused tarkvara tarnimiseks ja sellele eelnevaks ettevalmistuseks.

Continuous Delivery on teema, mis mind isiklikult on viimasel ajal väga huvitanud. Selle peamiseks eesmärgiks on hoida rakendust pidevalt reliisitavas seisundis, mis on järgmine loogiline samm pärast Continuous Integrationit. Üsna üllatav oli näha, et tegelikult juba aastaid vana idee paistab just praegu väga tugevalt esile kerkivat printsiibina, mille kogukond on vastu võtnud kui hea tava – midagi, mille poole vähemalt pürgida. Võib-olla on teema aktuaalne just varem mainitud tehnoloogiate võidukäiguga seoses. Nii Docker kui ka erinevad platvormiteenused, millele viidatakse lühendiga PaaS võimaldavad tunduvalt hõlbustada automatiseeritud deployd.

Metoodikate valdkonnas kerkivad esile kaks tegijat: Lean ja DevOps. Lean on üldisem metoodika, mille eesmärk on vähendada väärtust mitteloovate tegevuste hulka. Eriti omab see mõtet startupide kontekstis, kus välditakse näiteks põhjalike turu-uuringute ja äriplaanide koostamist traditsioonilisel aeganõudval viisil. DevOps on spetsiifilisem metoodika, mida kasutatakse just tarkvaraarenduse kontekstis. Selle ülesanne on edendada koostööd tarkvaraarendajate ja operatsioonide üksuste vahel, millega avanevad uued võimalused, sealjuures ka eelpool mainitud tehnoloogiad. Kumbki neist meetoditest ei ole konkurendiks meile hästi tuttavale agiilsele lähenemisele, kuid pigem täiendavad seda.

Devoxxil räägiti ka Java järgmisest versioonist, mis toob meile kauaoodatud moodulihalduse. Endiselt olid teemaks ka käesoleva Java versiooni 8 pakutavad lisavõimalused, kus klassikalise objektorienteeritud programmeerimise kõrval otsitakse lahendusi teiste paradigmade kaudu, muuhulgas funktsionaalse programmeerimise võtete kasutamisega. Palju räägitakse ka Reactive programmeerimisest vahendite nagu näiteks RxJava, Akka, Vert.x ja NodeJS abil. Viimane on abstraktsioon, mis võimaldab andmetest mõelda kui striimidest, mida on võimalik transformeerida ja kombineerida.

Mitmeid neid tehnoloogiaid ja metoodikaid reklaamitakse kui võluvitsa, mis pühivad kõik mured. Kuid on ka neid, kes hoiatavad tormakaid otsuseid tegemast. “Shit happens when you put network between your classes,” ütles üks esineja tabavalt microservicete kohta, viidates sellega kaasnevale paratamatule lisakeerukusele.

Microservices

Microservice on mõiste, mida ei saa enam väga uudseks nimetada. Sisuliselt on see moodus rakenduse modulariseerimiseks, millega jagatakse rakendus väikesteks autonoomseteks teenusteks, mis omakorda suhtlevad omavahel üle võrgu. Tavaliselt paljastavad need REST-liidese, mille abil teenused üle võrgu üksteisega suhtlevad. Sellega võimaldame süsteemi erinevatel osadel areneda erineva kiirusega. Muudatus ühes teenuses ei mõjuta tingimata teiste teenuste tööd. Microservicite kontekstis pakub palju kõneainet ka süsteemide resilience ja rikete käsitlemine.

Et viia teenuste piire ületavate muudatuste hulga miinimumini, jagatakse süsteem teenusteks vertikaalset. Jagades süsteemi äridomeenide alusel saame stabiilsemad teenuste liidesed. Süsteemi kasvades võib tekkida vajadus töö jagamiseks erinevate meeskondade vahel. Vertikaalne jaotus võimaldab tiimidel saada spetsialistiks ka oma hallatavas äridomeenis. Mõnes mõttes erandina võib vaadata front-endi, mis moodustab õhukese horisontaalse kihi teiste teenuste peale.

Hea mustrina ei jaga teenused andmebaase. Jagatavad andmed peaksid teenused paljastama liideste kaudu. See on vajalik teenuste implementatsiooni detailide peitmiseks avalikkuse eest, mis omakorda hõlbustab muudatuste tegemist teenuste sees ilma seotud teenuseid mõjutamata. Kui andmebaas on jagatud mitme teenuse vahel, võib ka pisem muudatus selles nõuda mitme erineva teenuse üheaegset muudatust. Need teenused võivad aga olla erinevate tiimide arendada ja nõuda keerukat koordineerimist. Seepärast tuleks vältida tsentraalsete punktide tekkimist.

Kuid ka uuendused teenuste liidestes võivad tekitada vajaduse mitme teenuse üheaegse muutmise järgi. Selliseid olukordi saame vältida liideste versioniseerimisega. Oluline on meeles pidada, et meie eesmärk on võimaldada teenuste iseseisvat arengut.

Mitte alati ei toimi kõik teenused õlitatult. Microservicite kontekstis muutub äärmiselt oluliseks rikete leviku piiramine. Ka ebatavaliselt aeglaselt vastav teenus võib temast sõltuvate teenuste töö täielikult halvata. Vastust ootavate päringute kuhjudes ammenduvad rakendusele saadaval olevad threadid ja teenus võib hanguda. Kogu lisakoormus jaotub ülejäänud klastrile ja võib ka teised noded üle koormata. Selline stsenaarium illustreerib hästi vajadust rikete läbimõeldud käsitlemise järgi. Hystrix on teek, mis võimaldab just selliseid olukordi vältida. Nö circuit breakerite implementeerimine aitab rikkis funktsionaalsust välja lülitada ja minimeerida negatiivseid mõjusid. Teenuse arendudes tuleb alati lähtuda eeldusest, et kõik taustasüsteemid võivad maha kukkuda. Kõiki halbu stsenaariume saab muuseas simuleerida ja testida vahenditega nagu Mockwire.

Teenuste arvu kasvades muutub kiiresti oluliseks automatiseerimine. Skaleerumiseks on hädavajalik automaatne testimine ja hõlbus muudatuste deploymine. See nõuab aga investeeringut infrastruktuuri ja protsessidesse nagu Continuous Delivery. Samuti muutub keeruliseks logide haldamine. Tööriistad nagu Kibana või Splunk võimaldavad logid agregeerida ühte kohta. Huvitava trikina võib juurutuda praktika, kus igale äriloogilisele tegevusele genereeritakse oma korrelatsiooni identifikaator. See identifikaator märgitakse maha iga seotud logikande juures. Nii on lihtsalt leitavad kõik omavahel seotud, kuid erinevatest süsteemidest pärinevad logikanded.

Paljud neist printsiipidest kehtivad ka monoliitse rakenduse juures. Kuid tõeliselt kriitiliseks saavad need just microservice arhitektuuri puhul. Kui suur on sellise arhitektuuri valimise hind? Kindlasti sõltub see ümbritsevast ökosüsteemist. Hästi juurdunud DevOps metoodika võimaldab lihtsamini taolist arhitektuuri üles seada. Korporatiivses maailmas, kus asjad liiguvad suurema inertsiga, võib see aga päris raskeks ülesandeks osutuda. Nii ei pruugi potentsiaalne tulu üldsegi üle kaaluda muudatusega kaasnevat vaeva ja lisakeerukust ja seetõttu on ilmselt hea strateegia hoida valikuid avatuna võimalikult kaua viljeledes modulaarset disaini monoliitse rakenduse sees. Hüpe microservicitele on mõistlik teha alles tungiva vajaduse tekkides. Pühendumise edasilükkamine on muuseas ka üks Lean metoodika printsiipidest.

Principles Of Microservices

Six principles for building fault tolerant microservices on the JVM

Microservices and Modularity or the difference between treatment and cure!

Code Review

Code Review on praktika, kus enne koodi mainline commitimist vaatab selle üle mõni tiimikaaslane. Eesmärgiks on koodi kvaliteedi parandamine, koodibaasi tutvustamine tervele meeskonnale ja õppimine arutelude kaudu. Praktika juurutamiseks tasub aga silmas pidada mõndasid põhitõdesid. Code Review ei tohi omandada negatiivset alatooni. See ei ole meetod töötulemuste hindamiseks ega tohiks panna hinnatava koodi autorit liiga suure pinge alla. Samuti ei tohiks see panna liigset koormust hindaja õlule. Eesmärk ei ole koodile vaadates kõik vead leida, kogu hindamine ei pea kestma üle 10 minuti. Küll aga võiks hindamine toimuda aegsasti, muudatused ei tohiks selle taha takerduda. Põgus ülevaatus tekitab loodetavasti arutelusid ja ideede jagamisi, mis lõpptulemusena parandavad koodi kvaliteeti ja aitavad kaasa ka osaliste isiklikule arenemisele. Code Review aitab meeskonna liikmeid kursis hoida teiste tegemistega koodibaasis ning rakenduse erinevate osade arenguga. Tagasiside jagamise juures on äärmiselt oluline emotsionaalne intelligentsus. Arendaja suhtub alati oma koodi teatava isiklikkusega. Kriitika peab seepärast olema konstruktiivne ja mõistvalt serveeritud. Vastasel juhul ei saavuta me loodetud hüvesid vaid tekitame vaid lisatüli.

How to stop wasting your time and start performing useful code reviews

“Make jar not war” – Twelve-Factor App

Rakenduse war arhiivi pakendamine on muutumas mõnes mõttes antipatterniks. Traditsiooniliselt pakitakse veebirakendus war faili, millele tuleb seejärel leida koht mõnes aplikatsiooniserveris. Tihti sisaldab selline aplikatsiooniserver veel teisi ware. Wari uuendamine serveris aga ei pruugi olla triviaalne. Halvimal juhul tuleb server taaskäivitada häirides sellega kõigi sisalduvate rakenduste tööd. Samuti ei ole rakendusserveri automatiseeritud üles seadmine lihtne. Seepärast on populaarseks muutunud jar arhiivi pakendatud rakendused, mis sisaldavad oma enda embedded serverit. Populaarseim näide sellisest lahendusest on ilmselt Spring Boot.

Serverit sisaldava ja .jar-i pakendatud rakenduse käivitamiseks on vaja vaid Javat. Lahendus sobib eriti hästi pilvetehnoloogia konteksti, kuid on oluline ka traditsioonilisel platvormil Continuous Delivery praktika juures. Idee poolest võiks infrastruktuur olla ühekordselt kasutatav. Rakenduse keskkonna võib ära visata ja taasluua. Kuna .jar arhiiv on käivitatav kus iganes on olemas Java virtuaalmasin, teeb see keskkonna loomise tunduvalt lihtsamaks. Jar eemaldab ühe muutuja mängust – rakendusserveri. See suurendab paarsust production ja arenduskeskkondade vahel. Kaovad serverist tulenevad erinevused ja suureneb kindlus, et rakendus töötab erinevates keskkondades samamoodi.

Need põhimõtted ja mitmed teised on koondatud metoodikasse, mida nimetatakse Twelve-Factor Appiks. Pean tunnistama, et polnud sellist mõistest varem kuulnud. Midagi täiesti revolutsioonilist ei paista see mängulauale toovat. Ometi pakub see üsna head kokkuvõtet headest praktikatest, mida arhitektuuri valimisel järgida. Täpsema kirjelduse leiab 12factor.net. Saab näha, kui palju kõlapinda metoodika tulevikus saavutab.

The Twelve Factor app: Best Practices for Java Deployment

Kõigi muudatustega kaasneb teatav hind, vahel ei pruugi see hind üle kaaluda mõne uuendusliku vahendi kasutuselevõtust loodetud tulu. Vahel võib ka juhtuda, et uus asi lahendab suuresti meie tänased mured, kuid tekitab hoopis uusi muresid. Oma üsna lühiajalisele kogemusele tuginedes tundub mulle siiski, et tarkvaraarenduse maailmas on toimumas üsnagi suured muutused, millel tasub vähemalt silma peal hoida.

Miks õppida programmeerimiskeeli

Roland Tepp, tarkvaraarhitekt

Olen mitmel puhul (ka Proeksperdi siseselt) kuulnud arvamusavaldusi nagu professionaalsel tarkvara inseneril ei oleks vaja õppida enam kui kahte programmeerimiskeelt. Üks neist keeltest peaks olema tõsisem töö tegemise keel nagu C++, Java või C#; ning teine keel võiks olla mõni dünaamiliste tüüpidega skriptide kirjutamise keel nagu Ruby või Python.

Samuti olen kohanud suhtumist et programmeerimiskeele õppimine oleks just nagu väärtusliku aja ja ressursi raiskamine – miks õppida uusi või vähetuntud programmeerimiskeeli, kui nende osas puudub kliendi tellimus, kui neil puudub kogukonna tugi ja jääb vajaka oskusteabega töökäsi.

Ütlen otsekohe välja, et ma ei jaga neid seisukohti. Miks?

Sest programmeerimiskeeled on minu ameti tööriistad. Ma tahan käia ajaga kaasas ja lubada endale valida ainult parimaid tööriistu. Iga uus tööriist õpetab mulle uusi töövõtteid, laiendab minu silmaringi ja parandab minu konkurentisvõimet.

Pidevalt kasvav tööriistakast

Usun, et ei ole suur üllatav, kui ütlen et mulle meeldivad programmeerimiskeeled. Paljud, kellega suhelnud olen, on ilmselt kuulnud minu huvist Ceylon keele vastu — olen seda huvi kahel korral ka kolleegidega jagada püüdnud ning ka ise oma käe projektile külge pannud.

Samas minu programmeerimiskeelte huvi ei piirdu vaid ühe keelega. Läbi oma karjääri olen enamal või vähemal määral kokku puutunud paljude erinevate programmeerimis- ja dokumendikeeltega:Basic, Pascal, Perl, C, C++, VisualBasic, Python, JavaScript, Java, C#, Bash, PowerShell, SQL, Octave, Standard ML, Racket, Ruby, Erlang, Ceylon, Smalltalk, jne… Ja need on ainult programmeerimiskeeled — lisaks võib siia hulka lisada ka HTML, XML, CSS, LaTeX ja mitmed teised dokumendi- ja domeenispetsiifilised keeled.

Niiviisi ühes reas üles loetletuna tundub nimekiri kohutavalt pikk — tagantjärgi sellele pilku peale visates üllatab nimekirja pikkus mind ennastki — aga kui mõelda sellele, mis moel või millistel põhjustel ma neid keeli olen kasutama pidanud, siis pole tegelikult midagi imestada, suuremat osa neist keeltest on mul läinud vaja ühe või teise töö tegemiseks.

Väga vähesed keeled selles nimekirjas on õpitud ainult uue programmeerimiskeele õppimise rõõmu pärast. Enamasti on õppimise ajendiks olnud reaalne vajadus midagi ära teha.

Programmeerimiskeeled on enne kõike ikkagi peamised tööriistad. Uue programmeerimiskeele õppimine on nagu uue tööriista hankimine — sa ostad omale uue tööriista sellepärast, et sul on seda mingil hetkel vaja. Ikka üks tööriist korraga. Ja enne, kui sa märgatagi oskad, on sul neid kogunenud juba nii palju, et sellega täidab ära juba päris aukartustäratava tööriistakasti.

Ma ei pruugi kõiki tööriistu meistriosavusega käsitleda. Enamik programmeerimiskeeli minu “tööriistakastis” on näinud viimast kasutust aastaid tagasi ja tõenäoliselt võtaks mul täna paljude nendega mingi arvestatava produktiivsuseni jõudmine pea samapalju aega kui kunagi selle keele õppimine, aga mingil hetkel oli mulle neid vaja ja ma omandasin vajaliku teadmise piisaval tasemel, et “ohtlik olla”.

Käia ajaga kaasas

Isegi kui on õnn (või õnnetus) pikema aja vältel püsida sama programmeerimiskeele ja -keskkonna juures (C++ Windows development või Java EE või LAMP stack), siis ka need keskkonnad ei seisa kunagi paigal.

Nii C++, Java kui C# on läbi viimase paari aastakümne läbi elanud tohutuid muutusi. Pikad suhteliselt stabiilse platvormi perioodid on vaheldunud ajuti päris radikaalsete muudatustega nii keele kui arenduskeskkonna osas.

Java suureks murranguks oli 2004, kui saabus Java 5, koos generic’ute ja annotatsioonidega, mis muutsid tundmatuseni seda, kuidas kirjutada ja kasutada teeke ja raamistikke – Java EE pärast Java 5 erineb radikaalselt J2EEst mei oli enne seda.

Pärast kümneaastast pausi, kahte vahepealset Java versiooni, tuli eelmisel aastal välja Java 8, tuues keelde sisse funktsionaalse programmeerimise elemendid — lambdaavaldised. Nende mõju sellele, milline näeb välja uus Java kood, võib märgata juba praegu…

Samas ei saa jääda puhkama oma loorberitele ja loota, et sellega kõik piirdubki — Java 9 koos keelde sisse ehitatud moodulite toega ei ole kaugel silmapiiri taga ning selle muutuse mõjusid arendusele on väga lihtne alahinnata, kui puudub varasem kokkupuude modulaarse runtime’ga.

Kuigi ma ei ole enam aastaid aktiivselt C või C++ arendusega tegelenud, on siiski silma hakanud viimase aja C++ standardi kiirem areng. Ka JavaScript (või ECMAScript) on viimasel ajal hakanud näitama oluliselt kiiremat arengutempot tuues sisse suuremaid muudatusi keele süntaksi ja semantika osas.

Kiired ja ajuti ka üsna radikaalsed muutused muidu nii stabiilsete keelte juures ei ole juhuslikud. Need muutused on ajendatud peamiselt uute ja elujõuliste programmeerimiskeelte pealetungist — Java liidripositsiooni enterprise süsteemide arenduses on juba pikka aega noolinud C#, kuid ei saa alahinnata ka mõnevõrra uuemate tulijate nagu Scala, Groovy, Kotlini, Dart’i, Clojure, Ceylon ja Go keelte kuuma hingeõhku Java kuklas.

C++ käest püüavad vahelduva eduga püüda väänata turuosa D, Rust, Go, Nim, C#, Julia.

JavaScripti mitmeid veidrusi on siluda püüdnud nii CoffeScript, Dart, ClojureScript, Ceylon, ActionScript, Scala.js, ja paljud muud keeled.

Lisaks on hakanud akadeemikute tolmustelt riiulitelt pead tõstma ka mitmed funktsionaalsed keeled nagu Haskell, F#, OCaml, Erlang, Elixir, Racket.

Põhjalikuma suurpuhastuse on läbi teinud ka Perl, Python, PHP ja teised…

Kõik need keeled täidavad mingi lünga meie võimalikus tööriistakastis — igaühel neil on oma nišš, milles just see keel eriliselt särama lööb, võimaldades saavutada meie eesmärke kiiremini, kergema vaevaga, tehes koodi kompaktsemaks, paremini loetavaks ja/või pakkudes paremat turvavõrku tüüpiliste veaolukordade vältimiseks või olulisemat valupunktide leevendamiseks.

Püsida laineharjal

Parafraseerides tuntud vanasõna: “Kui su tööriistakastis on ainult haamer, siis valid sa oma tööpinna ja -materjali alati selliselt, et töö saaks ainult naelte ja haamriga tehtud.” Ka siis kui mõnikord piisaks liimist või akutrelli ja kruvidega saaks paremini, kiiremini ja kindlamalt.

Sa võid oma ainsat tööriista kasutada erakordse meiserlikkusega, teada täpselt, kui kõvasti millist naela millise pinna sisse lüüa, mis naelad sobivad millistesse materjalidesse ning osata 42 erinevat haamrilööki, kuid suvaline noor nolk, kes tuleb objektile oma naelapüssi ja akutrelliga, võtab sult töö käest, sest tema tööriistakast on rikkalikum ning võimaldab sama tulemuse saavutada kordades kiiremini ja kui mitte alati kvaliteetsemalt, siis vähemalt ühtlase ja piisavalt hea kvaliteediga.

Sama lugu on ka programmeerimiskeeltega. Jäädes pidama vaid ühe kindla (ja kahtlemata mugava) töövahendi juurde, piirame me oma konkurentisvõimet ja jääme mingil hetkel paratamatult ka ajale jalgu.

Mina eelistan hoida ennast kursis uute töövahendite ja töövõtetega. See tähendab lisaks teemakohaste artiklite ja raamatute lugemisele, podcastide kuulamisele (ja võimalusel konverentsidel käimisele) ka silma peal hoidmist uutel programmeerimiskeeltel.

Aegajalt kerkib teemakohasest meediast üles mingi uus teek, raamistik või programmeerimiskeel, mis lubab me elu koheselt teha kümme korda ilusamaks, lahendada maailma näljahädad ja teha lõpp sõdadega. Ei maksa palju kulutada, tund või paar selle uue asjapulgaga tutvumisele — lugeda dokumentatsiooni, uurida koodinäiteid ja vaadelda arhitektuurijooniseid. Mitte kõik ei ole kuld, mis sädeleb, aga esmase tutvuse tegemine annab piisavalt infot, et uuele tehnoloogiale mingi mõtteline koht oma tööriistakastis reserveerida.

Varem või hiljem saabub olukord, kus teadmise kogumisele investeeritud aeg kuhjaga tagasi võidetakse. Siis, kui vaja, meenub sulle töövahend või töövõte või programmeerimiskeel, mis lubab esimesed 80% lahendusest saavutada 20% vaevaga võrreldes tööga, mis oleks kulunud, et kõik algusest lõpuni ise teha, samas koodi loetavust kümnekordselt parandades.

Kui ma ei ole isegi teadlik parema töövahendi olemasolust, ei ole vähimatki võimalust seda ka rakendada.

Samuti ei tohiks unustada et ka tänased näiliselt kõigutamatu positsiooniga C++ ja Java olid millalgi uued ja tundmatud, eksootilised programmeerimiskeeled. Nende asemel laiutasid C, COBOL, Smalltalk ja Pascal.

Miks sörkida ammuste trendide sisse tallatud jalajälgedes, kui saame võtta liidripositsiooni ning aidata neid trende ise kujundada.

Õppida midagi uut

Nii nagu iga uue tööriista kasutusele võtmine paneb omandama uusi töövõtteid, nii õpetab ka iga uus programmeerimiskeel midagi uut.

Basic ja VisualBasic andsid ilmselt tugeva aluspõhja ja õpetasid, kuidas midagi lihtsalt “ära teha”. Pascal andis esmase arusaama sellest, mis vahe on interface’il ja implementatsioonil. C ja vähesel määral ka kunagine ammune ASM’i kogemus andsid mulle arusaamise sellest, kuidas kasutab mu programm arvuti ressurssi, kuhu kaob mälu ja kust tekib soojus. Java õpetas objektorienteeritud mõtlemist ja OO disaini põhitõdesid. Perl õpetas hindama loetava koodi väärtust. Python andis esmase kogemuse funktsionaalse programmeerimise elementidega ja õpetas usaldust koodi vastu ning näitas kuidas dünaamiliste keeltega saab lihtsate vahenditega ja vähese tseremooniaga saavutada suuri tulemusi.

Erlang andis esimese õppetunni sellest misasi on pattern matching ning kuidas kasutada rekursiooni. Scala ja Standard ML õpetasid mis asjad on kõrgemat järku funktsioonid ja kuidas nende abil lihtsaid ja kergesti hallatavaid funktioone kombineerides jõuda võrdlemisi keeruka funktsionaalsuseni.

Tänu Scalale tegin endale selgeks (mingil määral), mis on monaadid ja kuidas neid kasutada (ning sain ka selgeks, miks Java keeles need seni nii vähest kasutust on leidnud).

Ceylon ja Scala õpetasid kasutama staatiliste tüübi infot enamaks kui vaid tühipaljaks andmete konteineriks või sarnaste funktsioonide grupeerimiseks – staatiliste keelte tüübisüsteem võib olla sihipärase ja teadliku kasutaja käes väga terav tööriist veavabama ja kergesti loetava koodi kirjutamisel.

Erlang, Scala ja Clojure näitasid, kuidas immutable andmestruktuurid võimaldavad muuta triviaalseks paralleeltöötluse ja asünkroonsete protsesside haldamise. Ja läbi selle andsid aimu hoopis uuest arhitektuursest lähenemisest skaleeruvate süsteemide ehitamisel.

Iga keel, millega mul on olnud au kokku puutuda, on mõjutanud seda, kuidas ma pärast oma koodi kirjutan, kuidas ma oma esialgse ülesandepüstituse tükkideks lammutan ja mis moel ma lahenduse kokku kombineerin.

Usun et iga üks neist on teinud minust parema inseneri.