Where Are Programming Languages Going? October 03, 2008 12:06 3 months ago
Jeg kender svaret men desværre ikke spørgsmålet. Det var min indgangsvinkel til dette års JAOO. Denne holdning er i høj grad præet af titlen på keynote speaken på dag et. Ca. 20 foredrag og tre bufs senere forstår jeg bedre spørgsmålet men til gengæld forsvandt svaret ud i morgendisen men det essentielle står alene tilbage endnu mere tydeligt end før. Softwarebranchen har problemer og de kommer fra en uventet kant.
Med udgangspunkt i “hvor er vi på vej hen” synes det naturligt at udforske hvor vi kom fra. Det foredrag som gav mest mening var derfor 50-50 af Guy L. Steele og Richard P. Gabriel. De leverede varen i et formidabelt show hvor der blev kigget tilbage på 50 års udvalgte klassikere bland programmeringssprog hvoraf de bedste og mest betydende egenskaber blev riset op og sat i perspektiv for vores dages sprog.
Man kan diskutere form og udtryk på en session, denne var ironisk og fyldt med statements, musik og underlige indslag. Jeg kan ikke gennemskude om alle brød sig om sessionen men for mit vedkommende var det perfekt og jeg kunne se at de selv nødt hvert sekund. De to ældre herrer sluttede af med at dedikere et øjeblik til de store mennesker som har lavet en række programmeringssprog men nu ikke længere er iblandt os. For mig var det et stort øjeblik og en stræk oplevelse.
Ifølge JAOO keynote speaker Anders Hejlsberg har vi ikke lært ret meget gennem alle de år. Som programmører er vores input til systemerne stadig på et lav niveau. Han illustrer dette med en lille test med henholdsvis Pascal og C#. Andres skrev selv Pascal og har stor andel i C# og det viser sig at Pascal koden til hallo verden kun fylder ca. 50 procent i forhold til C#. Så hvad har vi vundet? Anders påtaler at et sprogs omverden har ændret sig drastisk grad i forhold til programmeringssprog og hvis man udelukkende beholder fokus på input metodik er det helt galt.
I det hele taget har programmeringssprog en stor rolle i dette års JAOO og det er godt for mig som elsker den slags. Selv JavaScript har sin egen session hvilket ikke er underligt når man ser JavaScript V8 motoren bliver præsenteret af Lars Bak. V8 spiller med sine muskler og fortolker koden signifikant hurtigere end alle konkurrenter.
Men der foregår også noget andet! Det får mig til at tænke på den Japanske metode til at introducere nye problemer, den går ud på at splitte problemet op i størrelser som kan håndteres enkeltvis men sammen giver de en naturligvis en showstopper. En slags just in time princip for virkelige problemer.
Andres udtalte ordet “funktionel programmering” ca. 29 gange under sit foredrag men måske er det et tilfælde? Senere samme dag viste Erik Meijer betydelige samtidighedsproblemer med LINQ i forbindelse med multicore teknologi og sen binding. Dette er kun en personlig observation men jeg kan mærke noget ulme.
Som sædvanlig er der positive keynotes og supersmarte salgs gimmicks der indikere de vanlige forbedringer indenfor programmeringssprog men der er også dommedags profetier som forsøger at gøre os teknonørder klar på store udfordringer i fremtiden. Vi som udviklere og programmører er ikke kommet længere de sidste 50 år og vores metodik er stadig simple kode konstruktioner for at udtrykke selv helt simple ting for forretningen.
Hvilket bringer mig til en anden trend i tiden som har taget udspring hos folk fra rails comunitiet. Hvad betyder ordet at skrive i kode? Hvorfor skriver vi i koder og i så fald, hvem kan aflæse dem? Som udgangspunkt burde det være alle der deltager aktivt i et projekt. Er den kode vi skriver til mand eller maskine? Sam Aaron udtaler at vi må til at betragte kode som noget andet hvis vi skal over den barriere hvori vi lever i dag. Sam fortæller om Aesthetic programming with Ruby, og hans bud er at betragte kode som digte eller poesi og dermed øge den menneskelige intervention.
Flere og flere talere giver udtryk for at funktionel deklarativ programmering er fremtiden. Ruby on Rails bliver ofte brugt som model når det gælder eksempler på deklarativ programmering. ActiveRecord benytter en deklarativ metode til at fastsætte relationer mellem modelobjekter. Ideen bag deklarativ programmering er at nøjes med at beskrive problemet frem for hvordan det løses.
Hvorfor spiller funktionel programmering stadig en rolle? Vi må erkende Moore’s lov og adoptere nye krav i en stigende frekvens og dermed får funktionel programmering sin plads på den baggrund som renhed og foranderlighed håndteres i forbindelse med funktionelle konstruktioner og bivirkninger. Fx renhed, der betyder at en metode/funktion, givet et input ikke laver et state eller forandring, en effekt. Side Effects and Functional Programming.
John Davies bruger ikke tid på databaser. Hans kunder vil have svar her og nu. Investment bankning lever i reentrant memory og persisterer(måske) sine komplekse data strukturer i XML format efter lukketid. Denne metodik er mentalt svært at adoptere for mange men vi er noget stykker som i mange år har talt om at fjerne databasen og i den forbindelse er det ligefremt. Andre personer som fx Emil(the grat neo) mener at tiden er inden til nye former for stores fx den graf baserede model hvilket henvender meget bedre til en dynamisk adaptiv verden. Neo4j er enkelt at bruge og indkoorporere fra start en objekt orienteret tankegang.
Klassen er død, længe leve grænseflader! Qi4j bringer den nye idé om Composite Oriented Programing, hvor der ikke findes adfærd på en klasse, men i stedet bliver klassen et “composite” af grænseflader. Objekterne bygges af Mixin moduler der angives på klassen via annotationer. Rickard Öberg forslår at vi bruger Neo4j og klasse løse objekter for at undgå repeterende kode.
Selv klasserne er objekter. Neal Ford Neal Ford befinder sig godt med ruby objekter. Man kan kun en ting med disse objekter, nemlig sende en besked til et andet objekt. Man kan også reflektere på objekter, ændre dem eller måske fjerne en metode hvis den er ubelejlig. This is the real NEO. Metaprogramming in Ruby for fun and profit. And fun it was.
Ola Bini går han klædt som det passer ham. Og han er skrap som en barberkniv. Jeg er fuldt af respekt den knægt. Denne session starter han med at sige at der nok er lidt for mange slides og sætter tempo fra start. Mit gær er at han sætter ca. halvdelen af de fremmødte på de første 10 minutter men det er sgu sjovt. Jeg har set hans demo før men de virker altid godt på nye medlemmer i ruby klubben. Især er det cool at vise det intermix med både ruby og Java kodet i samme linjer.
Frank Buschmann afholder reviews. Området interesserer mig ikke men jeg må sige at Frank kan formulere de essentielle ting i en grad så indholdet alligevel bliver vedkommet for mange. Hvor ofte høre man ikke en projektleder iværksætte et review uden mål eller retning. Frank sætter spørgsmålstegn ved hele problemstillingen og mere end antyder at vi ikke lægger vægt på denne proces. Og det er synd, man må huske på at formålet ved et rewiew er at hjælpe arkitekter og udviklere samt at videregive information om kvaliteten i projektet til ledelsen. En af de store problemer ved review er at definere hvornår nok er nok. Alting har en grænse og specielt i forbindelse med en bestemt egenskab er det vigtig at man ikke blot udføre et review i blinde men at det i review specifikationen tydelige fremgår i hvilken egenskaber som ønskes afklarede. En anden vigtig paramter i et review er at definere hvornår man skal stoppe med at reviewe. Hvad betyder godt nok og hvad måles der på? Hvis et review bliver iværksat i forbindelse med performents er det vigtigt at man specificere hvor voldsom en performance test man vil have.
Stefan Tilkov er en af mine helte. Måske fordi jeg selv har arbejdet meget i en serviceorienteret verden. I serviceorienteret design findes der meget få tjenester men hver af dem promoverer en lang række operationer. Hver service har sit eget interface og tjenesten i sig selv udgør ikke nogen enhed. Man identificerer enheder gennem oplysninger der sendes som dokumenter som gerne tunnel POST’tes over HTTP og derved misbruger applikationsprotokollen.
I en ressource-orienteret verden (REST) bliver de vigtigste ressourcer er identificeret, og disse kan være enheder, samlinger, eller noget andet designeren synes fortjener at have sin egen URI. Standard metoderne, i dette tilfælde HTTP verberne – bliver lagt til den ressource-specifikke semantik. Alle ressourcer har det samme ensartede interface. Repræsentationen er det output som ressourcerne returnere styres af content-type og kan indenholde mange forskellige gengivelser af ressourcer fx XML, HTML, JSON, Yaml, PDF, ATOM, osv. Det er vigtigt man husker at hypermedia sine repræsentationer. Hybermedia udgør den måde som internettet er interconnected.
Hvis vi byggede flere applikationer som var interconnected på en ægte løs facon kunne vi skalerer de enkelte software dele efter deres individuelle brug. Det er faktisk tragisk at vi er ved at kunne købe hardware med 32 eller 64 cores men vi kan ikke udnytte dem. Java gør sig parat til denne nye verden ved at udvide de trådede muligheder i deres API, MS vil ha os til funktionel programmering igen hvilket ikke harmonere med meget røre om domain specifikke sprog og mere kunde interaktion. I begge tilfælde bliver det ikke letter at være programmør.
Hvor går programmeringssprogene hen?
Stenalderen sluttede ikke fordi der ikke var flere sten!
By Frank Vilhelmsen - 2 tags: conference jaoo - Add comment