»Udviklere er mentalt dårligt fungerende mennesker«

Udvikler og teknisk direktør Greg Young har et vigtigt budskab til alle udviklere, som – ifølge ham – har mange mentale problemer: Stop med at gøre dumme, irrationelle ting.

»Udviklere er totalt irrationelle mennesker. Vi har virkelig mange mentale problemer. For vi er mere interesserede i at bygge obstruktioner end i at løse rigtige problemer og bygge noget, der faktisk virker. Det er det, man kalder udvikler-pornografi.«

Citatet kommer fra Greg Young, der udtalte ordene mandag på Goto-konferencen i Aarhus. Greg Young er amerikaner og medstifter af software-udviklerhuset Imis, hvor han er teknisk direktør. Og så har han ikke meget tilovers for de dumme beslutninger, som udviklere ofte tager helt uden at skænke det en tanke.

Hellere en filosof end en programmør

En af Greg Youngs kæpheste er, at man i udviklerverdenen har så meget fokus på at lære alverdens værktøjer.

»Hvorfor taler vi om værktøjer, når vi lader os styre af irrationelle beslutninger? Vi glemmer at se på softwaren, men koncentrerer os om at lære så mange værktøjer som muligt,« siger han.

Skaden i tankemåden sker allerede på uddannelsen, hvor udvikleren 'programmeres' til at tage et problem og udtrække det til et andet problem, der er lettere at løse, i stedet for at tænke over det oprindelige problem.

»Hvis jeg skulle ansætte en softwareudvikler i mit firma, vil jeg hellere have en filosofiprofessor til at udvikle softwaren end en udvikler, for de er skadet i deres tankegang,« siger han med et glimt i øjet.

Derfor mener Greg Young, at man som udvikler ikke bare skal stræbe efter at lære flest mulige værktøjer, men også blive dygtig til at bruge værktøjer korrekt. For ens hjerne kan ikke rumme det hele alligevel.

»Jeg har erfaret, at hvis jeg bliver ved med at lære nye værktøjer, som kommer ind ad det ene øre, flyver der barndomsminder ud ad det andet.« siger han, og salen griner højlydt.

Gentager du også dig selv?

Tag for eksempel Don't Repeat Yourself (DRY) – et princip, som mange udviklere siger, at de lever efter, men som de fleste alligevel ikke efterlever i det daglige. Greg Young taler højt, hurtigt og med en passion, som er sjældent set.

»Jeg havde en chef, som sagde, at hvis du skriver den samme kode to gange, skal du begynde at overveje, hvad du laver. Jeg har en udfordring til jer: Slet al den kode, du har skrevet, som du ikke har brug for. Hvis noget i systemet tjekker en parameter, du allerede har tjekket, så slet den.«

Java-udviklere er værst

»Hvor mange .Net-udviklere er der i salen,« spørger han?

Nogle hænder ryger op.

»Java-udviklere?«

Mange flere hænder ryger op.

»O.k., min favorit mentale dysfunktion kan findes hos Java-udviklere. Hvorfor har I mere XML-konfiguration end Java-kode? 'Det er smart', er argumentet, for det er smart at kunne konfigurere i runtime. Men hvad er det, der skal konfigureres? Vi elsker at løse problemer, der ikke eksisterer,« siger han og tilføjer:

»Vi elsker at løse problemer med matematiske værktøjer, men din arbejdsgiver vil bare have, at det skal fungere.«

For mange frameworks

Greg Young har også set sig sur på frameworks, for der er for mange af dem, og de løser ikke nogen problemer.

»Hvor mange har skrevet et framework?«

Mange hænder ryger til vejrs i auditoriet.

»Hvorfor? Hvor mange frameworks har vi dog brug for? Vi vil gerne lave generiske løsninger, der kan alting, men hvor mange af jeres systemer har brug for at kunne alting?«

Hans budskab er, at mange vælger at bruge frameworks eller arkitekturer, fordi det er sejt eller kompliceret – ikke fordi det giver det bedste resultat.

Jeg har brugt alle verdens designmønstre, derfor er min arkitektur bedst

Greg Young fortæller, at en af hans venner skulle tjekke en software-arkitektur i et firma.

Arkitekterne virkede forurettede over at blive set efter i sømmene, for de uden at blinke kunne meddele, at de havde lavet den bedste arkitektur, fordi de havde brugt alle designmønstre, der findes – overhovedet.

»De havde endda brugt nogle desig-mønstre, der er svære at få ind i arkitekturen,« siger Greg Young, og salen griner over ironien.

Han slutter sin tale af med dette:

»Vi gør virkelig mange dumme ting, og vi har virkelig mange mentale dysfunktioner, men jeg håber, at vi kan få lidt perspektiv på tingene.«

Og at dømme efter salens klapsalver har publikum fået netop det.

Tips og korrekturforslag til denne historie sendes til tip@version2.dk
Kommentarer (25)
sortSortér kommentarer
  • Ældste først
  • Nyeste først
  • Bedste først
Casper Bang

Han sætter tingene lidt på spidsen, men man kan ikke være uenig om at der i Java er for mange frameworks og for komplekse teknologier. Men dét er vel et resultat af at udgangspunktet fra Sun Microsystems har været så ringe. Jeg mener, det har nu taget 5+ års diskussion, og vi har stadig ikke closures i Java endnu!

  • 0
  • 0
Lars Dam

Tada...

Der bekræftede du lige Greg Youngs påstand... "Vi elsker at løse problemer, der ikke eksisterer"

Java har klaret sig fint uden Closures indtil nu, så lad os endelig opfinde en ny løsning til noget der (tilsyneladende) ikke er et problem.

vh. ld

p.s. Læs min kommetar med et smil.

  • 0
  • 0
Casper Bang

Jeg har såmænd smilet på, men vil bare lige påpege at grunden til at closures ikke er kommet til endnu netop skyldes de tidligere halvhjertede implementationer man ser med anonyme klasser og erasure generics, for slet ikke at tale om det fejlslagne eksperiment checked exceptions. Man må tage hatten af for Anders Hejlsberg og den noget mere homogene samt innovative stak .NET trods alt er, hvor design mønstre der har vist sig nyttige, gradvist bliver inkorporeret i sproget (properties, events, asynkronitet etc.).

  • 0
  • 0
Peter Makholm Blogger

Det er selvfølgelig sat lidt på spidsen, men grundlæggende vil jeg nikke genkendende til observationen.

Men den interessante del af foredraget må være udeladt: Hvad hjælper observationen os? Hvad er det underliggende problem han har observeret et symptom på? Hvordan løser vi det egentlige problem?

Eller set fra en anden vinkel, kan vi forklare det observerede symptom ud fra vores generelle viden om personlighedstyper? Hvad er det der tiltrækker os til at fokusere på (igen og igen) løse generelle metaproblemer istedet for at lave dagens arbejde?

  • 0
  • 0
Casper Bang

Altså, udover at optimere, så er det klart at der er en del personlig og professionel tilfredsstillelse ved at generalisere! Dette vil dog påstå skyldes den menneskelige stræben efter at skabe orden i rod, mere eller mindre formaliseret af folk som Fowler osv. Der kan jo ikke være nogen tvivl om at entropien i et system stiger som en funktion af tid og funktionalitet, for at overkomme dette træder vi et skridt op i abstraktionsniveau.

Som jeg hører Greg Young, kommer han i virkeligheden bare med en pendent til David Wheelers berømte budskab:

All problems in computer science can be solved by another level of indirection... Except for the problem of too many layers of indirection!"

...dog på en noget mere kluntet facon. Det er selvfølgelig muligt Greg Young i virkeligheden ønsker os tilbage til VB6 dagene hvor man ganske vist hurtigt kunne smide noget sammen der løste et problem, men med alle muligt andre problemer tilgængæld - I donno, jeg var desværre ikke tilstede.

  • 0
  • 0
Morten W. Jørgensen

Det har Alan Cooper beskrevet paa fineste vis i "Inmates Are Running the Asylum". Baade de indledende observationer og hvordan man udnytter de omtalte personlighedstraek.

I oevrigt er bogen fra 1998 saa for, i det mindste nogen, er det ikke ligefrem ny viden der her laegges for dagen. Men det er godt at der er fokus paa vores milde form for autisme.

  • 0
  • 0
Peter Makholm Blogger

Der er selvfølgelig en personlig og faglig tilfreds til at løse et større problem end det man er blevet sat til at løse. Men med et sundt forhold til generaliseringer skal man balancere DRY-princippet med YAGNI-princippet (You ain't gonna need it).

Problemet er nå generaliseringen tager sygelig overhånd og vi fokuserer alt for meget på generaliseringe, frem for opgaven der skal løses. Det er dér det skifter fra en sund balance til at være et problem.

Jeg er enig med Morten i at det både er kendt viden og at det er relateret til autismefænotypen.

  • 0
  • 0
Michael Lykke

...dog på en noget mere kluntet facon. Det er selvfølgelig muligt Greg Young i virkeligheden ønsker os tilbage til VB6 dagene hvor man ganske vist hurtigt kunne smide noget sammen der løste et problem, men med alle muligt andre problemer tilgængæld

Tja, er der i virkeligheden den store forskel på software vi lavede dengang og det software vi laver idag? Jeg mindes at have brugt meget software "dengang" som løste opgaverne til fulde uden nogen problemer. Det software jeg støder på idag er ikke et hak bedre - Det gode software løser fortsat problemerne og resten overkomplicere tingene som Greg nævner.

Software bliver ikke bedre af at vi får det inddelt i en helvedes masse lag og services som benytter 15 forskellige sprog og teknologier med en hør af designpatterns smidt oven i hatten og det er vel netop pointen. IT branchen har så helvedes travlt med at overkomplicere tingene og finde på nye smarte buzzwords konstant og som regel er tingene ikke mere effektive end de var "dengang".

  • 0
  • 0
Christian Wikström

Det er tankevækkende at så mange ser det fra udviklerens perspektiv. Alle udviklere vil gerne lave en løsning, der er professionelt tilfredsstillende. Og dermed bliver det udvikling for udviklerens skyld. Ikke hvad forretningen er bedst tjent med. Hvis man ser på mange projekter rundt om i firmaer, så bliver der brugt forholdsvis mange timer på at "lære" nye frameworks, tools, etc. Personligt, så har jeg udviklet større og mindre "tools" til virksomheder, som er blevet til på kortest mulige tid. Dermed har virksomhederne fået det de ville have, og ikke det jeg gerne ville lave til dem.

  • 0
  • 0
Tidligere bruger

et hurtigt kig på denne artikel - enig med overskriften jeg har sagt til mange udviklere at de skal sørge for både den logiske og kreative side af sig selv, og ikke mindst træne sanserne. desuden træne evnen til at se dynamik og arbejde dynamisk med tingene. det er vigtigt at undgå procedure-tænkning og dumme vaner som intet formål har. Et problem kan også være hvis man "kun" koder og ikke skal være med til at designe, teste, ideudvikle og integrere. udviklerjobbet har helt sikkert nogen "fælder" som man kan undgå ved at arbejde med sig selv. Men det kan til gengæld også være et hammer spændende job :o)

Mit bidrag må være: TÆNK DYNAMIK

  • 0
  • 0
Casper Bang

Tja, er der i virkeligheden den store forskel på software vi lavede dengang og det software vi laver idag?

Ja det vil jeg da påstå, problemerne er meget mere komplekse og til dét benytter vi værktøj. Der sidder mindst 8 CPU'er i de maskiner jeg deployer software til, ligesom emnet "distribueret system" er gået fra at være et abstrakt fag til en konkret allestedsnærværende opgave hvor man pludselig skal skalere til mange hundrede tusinde, ikke må have nedetider, bruger mange forskellige præsentationsmedier så som papir, skrærm og smartphone osv. osv. Hvor mange systemer havde sådanne krav for 10-15 år siden?

Det er tankevækkende at så mange ser det fra udviklerens perspektiv.

Nja det er vel ligeså tankevækkende som at høre håndværkere diskuttere taglægningsteknikker, eller tandlæger diskuttere bro vs. implantat.

Forhåbentligt løser programmørene problemer fra forretnings perspektiv, incl. de langsigtede perspektiver de som fagmænd måtte have bedre overblik over. Synes mere det er tankevækkende at alt ting skal være sort eller hvidt istedet for at anerkende at der er brug for flere/alle perspektiver.

  • 0
  • 0
Per Olsen

Problemet er ganske enkelt at OOP er objektorienteret altså idealet er dermed et autopoetisk system! Dette fører helt naturligt til en løsning som giver præcis de 'menneskelige' symptomer som Greg peger på. (Opstår når man tænker oo!)

Hvis der skulle være en af jer der forstår denne sammenhæng har jeg et lille programmerings projekt, som netop sigter på at løse denne problematik på en lidt anderledes måde! Vh Per

  • 0
  • 0
Michael Lykke

Ja det vil jeg da påstå, problemerne er meget mere komplekse og til dét benytter vi værktøj. Der sidder mindst 8 CPU'er i de maskiner jeg deployer software til, ligesom emnet "distribueret system" er gået fra at være et abstrakt fag til en konkret allestedsnærværende opgave hvor man pludselig skal skalere til mange hundrede tusinde, ikke må have nedetider, bruger mange forskellige præsentationsmedier så som papir, skrærm og smartphone osv. osv. Hvor mange systemer havde sådanne krav for 10-15 år siden?

Multikerne maskiner er altså ikke nogen ny opfindelse og noget der har eksisteret i lang - Tænk fx mainframes m.m. Eneste forskel er at vi nu har fået billigere adgang til disse så de er placeret på vores skrivebord.

Jeg er uenig i at de problemer vi forsøger at løse er mere komplekse i dag end de var for 10 år siden. For 10 år siden havde du også websites med millioner af besøgende, du havde også multikerne maskiner, du havde også virksomheder som forsøgte at effektivisere deres forretning igennem IT. Største forskel er vel at vi idag har smartphones/tablets også som en ny måde at tilgå apps på.

Så selvom der er små forskelle så er der intet der bevirker at vi har behov for de sindsygt mange komplikationer vi opfinder i IT branchen - Tværtimod så ser vi jo bare gang på gang hvordan disse overkompliceringen bevirker at vi ikke løser de oprindelige problemer og ofte er med til at skabe nye/flere problemer.

Løsningen på en virksomheds problemer er ikke at sidde og spekulere i en ny måde at lave flertrådet exception handling eller hvordan vi kan agile scrum kanban prince 2 styre det næste projekt. Løsningen er som regel at bruge sund fornuft og stoppe med at konstant finde på løsninger til pseduo problemer vi udviklere "finder" på.

  • 0
  • 0
dennis iversen

Hvis du ser på kildekoden vil du se at version2 er lavet i Drupal version 7 (i skrivende stund) skrevet i PHP5 (Mere eksakt: PHP/5.3.3-7+squeeze1). Drupal er primært funktions baseret kontra objekt orienteret mens PHP er at betragte som en blanding. Om det er det ene eller andet (eller helt 3. som fx mere "rene" objekt orienterede sprog såsom Python eller Ruby) har dog ingen betydning for om din tekst i et textarea huskes når du trykker "gennemse".

I øvrigt vil jeg mene at det er et smags spørgsmål (grænsende til det religiøse for nogle personer) om det er funktions eller klasse baseret programmering der er bedst.

  • 0
  • 0
Lars Tørnes Hansen

om OOP,Objekt Orienteret Programmering.

Jeg synes ikke altid at OOP er særlig fantastisk, det samme kan jeg også sige om XML.

Jeg kan bedre lide funktionsprogrammeringssprog. Det er som om de har nogle sprogkonstruktioner der gør det nemmere at få arbejdet lavet. Closures er en af dem.

Jeg tror at mit næste fritidsprojekt bliver med XULrunner: https://developer.mozilla.org/en/XULRunner så jeg slipper for at rode rundt med low-level kode der skal tegne en GUI.

Det handler om at få jobbet gjort.

  • 0
  • 0
Per Olsen

Så må det altså være en OO programmør der koder PHP.. og så går det igen i ring. IRONI hvis du skal være i tvivl.... :-)

HELT enig der er i højgrad tale om et spørgsmål om "psudo-religion", skal vi kode autopoetisk eller proceduralt. Spørgsmålet er nu, hvem er reelt mest 'spirituelt' orineteret den ene eller den anden gruppe?

  • 0
  • 0
Casper Bang

Multikerne maskiner er altså ikke nogen ny opfindelse og noget der har eksisteret i lang - Tænk fx mainframes m.m. Eneste forskel er at vi nu har fået billigere adgang til disse så de er placeret på vores skrivebord.

Jo men er det ikke det samme som at sige "global opvarmning er altså ikke noget nyt, den eneste forskel er at der nu er flere mennesker der mærker det". Og for lige at hive gode gamle VB6 tilbage på bordet igen, så understøttede den kun apartment threaded objects og ikke multi-threading. Det er jo ikke for ingenting at samtlige nye sprog har så meget fokus på samtidighed!

Jeg er uenig i at de problemer vi forsøger at løse er mere komplekse i dag end de var for 10 år siden. For 10 år siden havde du også websites med millioner af besøgende

Javist, men de var i langt højere grad baseret på en simpel stateful model 2 arkitektur (JSP) og vertikal skalering, frem for RIA/MVC med horizontal skalering.

Løsningen på en virksomheds problemer er ikke at sidde og spekulere i en ny måde at lave flertrådet exception handling eller hvordan vi kan agile scrum kanban prince 2 styre det næste projekt. Løsningen er som regel at bruge sund fornuft og stoppe med at konstant finde på løsninger til pseduo problemer vi udviklere "finder" på.

Klart nok. Vi kan sagtens blive enige om at man må tilgå ny teknologi med en del skepsis og undgå NIH, men dérfra og så til at konkludere at udviklere er "mentalt dårligt fungerende mennesker" er der nu alligevel et stykke vej. De fleste større virksomhedder har iøvrigt arkitekter eller CTO'er til netop at styre dette aspekt af HR arbejdet.

  • 0
  • 0
Per Olsen

Så kan vi jo også komme til at jage hianden og det kommer der heller ikke noget godt ud af. Se fidusen er at jeg mener at den producurale tilgang hjælper os lidt til at undgå de negative konsekvenser. Hvorimod OOP kan forstærke det negative - procedural tilgang kan naturligvis ikke forhindre fejl... men det er lidt lettere at finde dem.

Et blandings produkt ville måske være at foretrække, hvor OOP typisk ville gavne hvor der er konkrete 'fysiske'' objekter... fx GUI, men dermed er vi også ud i at der er en øvre grænse for behovet.

At sige at en spirtuelt-begavet person er mentalt tilbagestående er lige så religiøst som det modsatte, så den hopper vi heller ikke på.. vel

  • 0
  • 0
Michael Lykke

Jo men er det ikke det samme som at sige "global opvarmning er altså ikke noget nyt, den eneste forskel er at der nu er flere mennesker der mærker det". Og for lige at hive gode gamle VB6 tilbage på bordet igen, så understøttede den kun apartment threaded objects og ikke multi-threading. Det er jo ikke for ingenting at samtlige nye sprog har så meget fokus på samtidighed!

Kan vi ikke hurtigt blive enige om at droppe tåbelige sammenligninger med global opvarming, race issues, biler, hitler og hvad der ellers er populært for at trække en debat af sporet. Nu argumentere jeg ikke specifikt for VB6 men at multikerne systemer har eksistere i flere årtier og at der eksistere teknologier til at udvikle løsninger til disse.

Det er fint med fremskridt men det er spild af tid og ressourcer at vi skal have flere hundrede forskellige sprog som alle sammen gør næsten det samme - Bare med forskellige buzzwords.

Javist, men de var i langt højere grad baseret på en simpel stateful model 2 arkitektur (JSP) og vertikal skalering, frem for RIA/MVC med horizontal skalering.

Buzzword alert! Præcis med den sætning beviser du jo netop min påstand - Vi har så fandens travlt med at overkomplicere det og strø om os med "fancy" ord. Faktum er at vi fint kunne lave websites der kunne håndtere millioner af besøgende og med en mere simpel arkitektur end idag hvor det hele helst skal ligge i så mange lag som muligt, fordelt på x antal servere, kerner, webservices, databaser som igen skal tilgåes via x antal forskellige sprog og frameworks som er fyldt med pseudo teknologi der fokusere på at løse problemer med teknologien istedet for at løse forretningens problemer.

De fleste større virksomhedder har iøvrigt arkitekter eller CTO'er til netop at styre dette aspekt af HR arbejdet.

Ja, flere lag til at "komplicere" arbejdet! Ja, det er sat lidt på spidsen men løsningen på mange problemer er altså ikke mere kompliceret teknologi med flere fancy pseudo begreber og en hær af "arkitekter", projektlederere og alt muligt andet smidt oven i hatten.

  • 0
  • 0
Casper Bang

Det er fint med fremskridt men det er spild af tid og ressourcer at vi skal have flere hundrede forskellige sprog som alle sammen gør næsten det samme - Bare med forskellige buzzwords.

Ja lad os holde fast i ASM og C (håber ikke jeg har brugt for mange buzz-words). Jeg kan ikke helt regne ud hvad det egentligt er du argumenterer for, kun en masse modargumenter.

Buzzword alert! Præcis med den sætning beviser du jo netop min påstand

Men igen, det er fint nok at du har en påstand du åbentbart synes jeg beviser. Men hvon' skal vi komme viddere fra påstand til løsning? Hvad er det egentligt du argumenterer for? Hvilke kvalitetskriterier er så rent faktisk gangbare i dit univers? Det ville være rart hvis du ville forholde dig lidt mere konkret til tingene, frem for blot at komme med frustrationsudbrud.

Ja, flere lag til at "komplicere" arbejdet! Ja, det er sat lidt på spidsen men løsningen på mange problemer er altså ikke mere kompliceret teknologi med flere fancy pseudo begreber og en hær af "arkitekter", projektlederere og alt muligt andet smidt oven i hatten.

Nej, for der er som bekendt ingen "silver bullet". Hvis det er dét du er ude efter, bliver du slemt skuffet. Jeg kan kun udlede af dine vage sure opstød at du har dårlige erfaringer med software arkitekter og ønsker os tilbage til en tid hvor brugerne selv kunne sætte software sammen på hobbymanér. Som professionel programmør der har prøvet at overtage et hav af legacy kode skrevet af ikke-programmører, må jeg bare ryste på hovedet.

  • 0
  • 0
Nicolai Møller-Andersen

Debatten om at moderne computere er mere komplicerede er efter min mening lidt afsporet. Allerede i 1975 eksisterede der dansk udviklede multibruger systemer med tråde, sepaphorer, delt hukommelse og harddisk og masser af brugere på hver deres skærm - det hele kørende på een eneste delt 10MHz 8085. Tekstbehandling, spil, regneark m.v. At en simpel multikerne PC skulle være væsentligt mere kompliceret eller anderledes end en unix fra de tidlige halvfjerdsere, - det er simpelthen en grov overdrivelse.

  • 0
  • 0
Morten Andersen

Jeg synes Greg Young lyder som en oplæst nar. Jovist, jeg har da også mødt udviklere der har brugt mere tid på at beskæftige sig med frameworks, processer, metoder osv. frem for at "fucking lave arbejdet". Jeg ser det som en form for overspringshandling - hvis man ikke kan kode, kan man altid fokusere mere på værktøjerne og processerne. Og den slags vinder fint indpas i projektlederlaget som typisk ikke har forstand på koden, men synes det er meget interessant med de sociale aspekter af de forskellige udviklingsmetodikker de har lært på diverse kurser.

Når det er sagt, så er der altså også mange dygtige udviklere, der fint er i stand til at se igennem al den megen fluff, og som laver arbejdet på den - ifølge dem selv - mest rationelle måde, og så bare får det til at passe ind i den udviklingspolitik virksomheden eller kunden nu engang har. Så er der også udviklere der ligger lidt midt imellem. Med dette in mente virker det lige lovligt frisk at påstå at udviklere, som helhed, skulle være mentalt dårligt fungerende mennesker. Man kunne også starte med at spørge: Sammenlignet med hvad? Hvordan er det med projektlederne som fokuserer på alle mulige smarte projektstyringsværktøjer? Eller hvad med ledelsen, som også ofte er forfalden til alt det nye smart (kanindræberkurser, coaching, personality types eller endda astrologi). Er disse grupper så også mentalt dårligt fungerende? Er det ikke i næsten alle professioner man vil kunne genfinde analoger til disse fænomener?

  • 0
  • 0
Morten Andersen

Jeg er fuldstændig enig - faktisk synes jeg det er sket skræmmende lidt. Prøv at hent et SDK til Windows eller Mac fra f.eks. 1993-1995. De funktioner der stilles til rådighed til håndtering af processer, grafik, lyd m.m. er stort set uændrede. Dels kan du genfinde præcis de samme funktioner i de moderne systemer, og dokumentationen er ofte baseret på dokumentationen fra dengang (dog er f.eks. QuickDraw i Mac nu deprecated). Og "nyere" sprog som Java samt nye frameworks til smartphones, Canvas elementet i HTML5 osv. er de forskellige frameworks bygget op på stort set samme måde som dengang. Tingene hedder noget lidt andet "Et graphics-objekt i stedet for et DeviceContext handle osv.) men er præcis det samme. Jeg er sikker på det samme vil gøre sig gældende hvis man går endnu længere tilbage.

En sjov ting er dog, at mange "nyere" udviklere slet ikke kender de helt fundamentale ting der foregår på maskinerne, fordi de kun har arbejdet i de højereliggende frameworks. Det kan måske forklare hvorfor folk tror maskinerne er mere komplicerede i dag - når de graver ned i fundamentet så ser det nyt ud - for dem - selvom teknologien er min. 20 og ofte 30-40 år gammel.

  • 0
  • 0
Log ind eller Opret konto for at kommentere