Emergence: Helheden er mere end delene

Nogle af de mere interessante nyskabelser indenfor softwareudvikling de sidste par år er relateret til emergence. Jeg ser flere og flere systemer i hvilke man kan definere elementer på en sådan måde, at de tilsammmen udgør en større helhed end "summen af delene". Jeg går og prøver at forstå hvad det er der sker, men her er lige et brain dump.

Emergence i relation til software kom først for alvor til min opmærksomhed i forbindelse med Wiki'er for måske 5-6 år siden. En wiki er emergent fordi bare det at man skriver et ord i CamelCase, altså med blandede store og små bogstaver betyder at der opstår en reference melllem den aktielle wiki-side, og den wiki-side der hedder det som ordet i camel case angiver.

Nu er emergence noget der kan forstås på mange måder, og det fremgår tydeligt af Wikipedia, at emergence er svært at definere. Det er faktisk sjovt at læse denne wikipedia side om emergence, som er et godt eksempel på hvordan wikipedia skabes.

Siden har jeg så gået og observeret emergence komme mere og mere i kontekst af de systemer jeg omgiver mig med i min dagligdag.

Tag nu fx Eclipse platformen. Her tænker jeg ikke på Eclipse som programmeringsomgivelse, men platformen og de abstraktioner og møstre der ligger nedenunder. Platformen er fantastisk, og repræsenterer så absolut en af mine store »aha!« oplevelser de sidste par år. I Eclipse definerer man »plugins«, som noget der kommer ind i forskellige sammenhænge. En given plugin kan bidrage sin opførsel i en eller anden situation (som den selv definerer i abstrakt form), og når denne situation er til stede fremkommer (emerges) sammmenhængen mellem situation (kontekst) og denne plugin's opførsel. Helt konkret kunne det fx være en plugin der bidrager et kontekstmenu-element. Plugin'en kan sige, at den bidrager et kontekstmenu element når selektionen er af typen IFile (en fil), eller når selektionen opfylder et givent predikat (angivet ved en funktion der kan returnere sand eller falsk). En anden plugin kan så tilbyde en type-konvertering, der således implicit betyder at førstnævnte kontekstmenu-element nu også virker i flere sammenhænge. Eclipse-maskineriet sørger for at denne emergence opstår.

Med en sådan fundamental struktur opstår pludselig helt nye muligheder for at lave afkoblet design, der i langt højere grad kan genanvendes. Sammenhængen mellem systemets dele bliver mere implicitte, og derved opnås en ny form for fleksibilitet. Præcis som i en wiki.

En anden form af emergence er ved at ske i databaser. Med en passende løs fortolkning kan man sige at et Excel regneark er "emergent": hvis rækker opfattes som »objekter« fremkommer et nyt objekt blot ved at skrive noget tekst forneden, og »attributter« fremkommer når man benytter en ny kolonne. Hvis denne model holdt vand i alle tilfælde skulle Mogens nok lede efter et nyt job. Det er nu ikke helt tilfældet, men der er mange "små databaser" hvor man kan have glæde af det. Disse ideer er ført helt ud det ekstreme i en række spændende nye database-agtige systemer som fx dabbledb og lidt mindre velafrundet på openrecord.org. Det kan anbefales at se de små videoer de har på disse sider. Specielt den fra dabbledb.

Og endeligt er der programmeringssprogene. Og det er jo det jeg brænder for, og det er derfor jeg skriver denne blog. Ruby er nemlig emergent, og det er det der adskiller Ruby fra så mange andre programmeringssprog. Relationer mellem forskellige program-dele er i Ruby mere implicitte end i så mange andre programmeringssprog. Og det sammen gælder for mange af de libraries og frameworks (fx Rails) der benyttes sammen med Ruby.

Som eksempel, er instans-variable ikke noget man erklærer i Ruby. Man bruger dem bare, og så opstår de efter behov. Hvis to forskellige dele af programmet refererer samme instans-variabel, så refererer de til samme logiske ting uden at kende hinanden apriori. Det samme gælder for metoder, klasser, og rigtigt mange ting. Jeg er ved at arbejde mig igennem Ruby sproget, så det kommer der nok nogle flere blogs om inden længe...

Emergence er naturligvis også farlig. For med emergence opstår jo muligheden for at der sker uforudsete ting og sager. Så derfor vil det jo altid være en afvejning af, hvor "sikker" man vil være på hvordan systemet opfører sig.

Jeg tror du at emergence er kommet for ar blive.

Kommentarer (6)
Peter Makholm Blogger

Kresten Krab Thorup betragter en anvendelse af Excel-regneark som en model for databaser og forudsiger at Mogens skal se sig om efter et nyt job.

Jeg er ikke helt klar over hvad Mogens har som ekspertise, men jeg frygter lidt holdningen at eksperter bliver overflødiggjort. Desvære er tør jeg ikke kalde forudsigelsen naiv, for folk tror tilsyneladende at værktøjer og "smarte" metoder gør eksperter unødvendige. Men i virkeligheden bliver der større og større behov for folk der ikke bare kan klikke lidt rundt, men rent faktisk forstår hvad det er de laver.

Jeg ser to trends: Det reelle behov for eksperter stiger og forbruget af eksperter falder. Resultatet er systemer der sagt på en pæn måde højst bliver suboptimale.

Poul-Henning Kamp Blogger

Der er mindst ét dansk firma der kan fortælle os, hvor meget det kan koste, at en medarbejder sidder og udvikler en database i et regneark, uden at have den fornødne basisviden.

Jeg kan ikke tillade mig at røbe historien, men hvis ham jeg tænker på læser dette og giver mig lov, så skal jeg gerne give beretningen i anonymiseret form.

Indtil da kan jeg kun røbe at vi taler om et regneark der kostede "nogle millioner" inden alt støvet havde lagt sig, men underligt nok ikke et eneste job.

Poul-Henning

Poul-Henning Kamp Blogger

Et af Frederick P. Brooks helt centrale påstande i "The Mythical Man-Month" er at man skal lave en prototype og så smide den væk.

Hvis ikke man gør det, kommer man til at gøre det alligevel, men prototypen får navnet "release 1.0".

Det er helt ok at lave prototyper, mockups og andet efter det forhåndenværende søms princip, men det tangerer kriminel uansvarlighed ikke at gøre sig klart at det er en prototype.

Det er også en naturlig ting at man gerne vil slippe lidt nemt om ved tingene når man starter på et nyt produkt eller nyt marked og hvis det bliver en fuser er det fint at man ikke har brugt for mange penge på det.

Men der er jo risikoen for at produktet bliver en success, og hvis ikke man i det mindste har en plan for hvad man så vil gøre ved den IT-støtte der skal bruges, så er man inkompetent.

Om planen så er klog eller endsige realistisk eller ej er en anden sag der må afhænge af konkrete vurderinger, men den skal sku' existere.

Men vi ved jo allesammen at EDB bare er en uvæsentlig stabsfunktion og lidt ligesom receptionisterne og viceværten kan man jo bare råbe højere hvis de siger man har dummet sig.

Poul-Henning

Flemming G. Jensen

I den kommende version af Java SE 6.0, der netop er kommet som release kandidat, endda i Open Source, understøtter et API scriptingsprog. Python og Ruby kan køre direkte i 6.0 JVM'en.

Kan du ikke skrive mere Java 6.0 og scripting API'et. Jeg har aldrig været den store tilhænger af typeløse sprog eller kunnet se den store fordel i at erstattet et rigtigt objekt-orienteret sprog som Java med et look-a-like sprog som Javascript. På den anden side kan man jo lave coole sager i f.eks. Google Web Toolkittet. Det er jo i øvrigt også Java, der ligger bag det.

Jeppe Sommer

Jeg vil tro de fleste af os kan blive enige om, at det er fint at bruge høj-produktive "emergence-agtive" teknologier, når der skal laves en hurtig demo.

Det centrale spørgsmål er snarere, om vi er eller bør være på vej til at basere vigtige og kritiske applikationer på disse teknologier. Guderne skal vide at der er opfundet og markedsført et væld af teknologier, der har været møllesten om halsen på software-udviklere, ved at kræve vedligeholdelse af de samme begreber på tværs af adskillige mere eller mindre redundante abstraktionslag (er der nogen her, der har prøvet at tilføje en knap til en struts/j2ee applikation?). Selvfølgelig vil vi gerne være mere produktive, men tør vi tillade den "emergence", der giver produktiviteten, når det virkelig gælder?

Tangerer det kriminel uansvarlighed at skrive et homebanking-system i Ruby?

Kresten Krab Thorup

Som du skriver, Jeppe, så er der sandt at sige skudt mange gråspurve med kanoner i vores verden. Java EE er jo fx et godt eksempel på sådan en kanon, hvis vi skal gribe til egen barm.

Det vi har opdaget siden Java EE kom på banen for godt og vel 6 år siden er jo at der er mange interessante, vigtige og forretningskritiske applikationer der ikke nødvendigvis er særligt store. PHP er jo fx big business; men vi ville jo nok ikke skrive kontrolapplikationen til et atomkraftværk i PHP.

Jeg tror at man skal se lidt indad, og se realistisk på hvad business-casen i et givent system er, specielt i forhold til time-to-market og udviklingsomkostningerne. Selvom vi måske går og bilder os ind, at et givent system skal leve mange år; så oplever jeg i hvert fald en tendens til at levetiden er hastigt faldende. Ikke fordi vi laver ringe systemer, men fordi verden drejer hurtigere og hurtigere rundt.

Log ind eller Opret konto for at kommentere