Hvad vi taler om, når vi taler om programmering

Til den netop overståede GOTO-konference fik jeg pludselig en tanke: alle der lærer at programmere taler om, at det føles som at lære et nyt sprog. Det er også rigtigt, det er en meget brugt metafor, velsagtens af den grund, at mange programmeringssprog ligner hinanden, ligesom sprog ligner hinanden (eller i nogle tilfælde slet ikke ligner hinanden, men dog tjener samme formål). Men der er et andet sprog vi også lærer at tale, nemlig det sprog vi bruger, når vi taler om programmering, og på et højere plan taler om teknologier, som man f.eks. gør det på en konference eller en arbejdsplads.

Jeg har haft mange episoder gennem årene, hvor jeg har hørt en person sige "klasse" og tænkt "han mener objekt", mig selv sige "metode", for så at blive spurgt om jeg mener "funktion", osv. På det niveau, hænger de fleste af os på. Men da en spurgte mig på konferencen, om det sprog han lige havde hørt om, der ikke benyttede sig af multipel nedarvning, ikke lige så godt kunne implementere en række interfaces, og opnå det samme, kom jeg til at tænke på det sprog vi bruger om vores fag. I dette tilfælde er der ikke så meget af snakke om, de to ting er ikke det samme, og så er den vel ikke længere (hvad skulle han også gøre uden super()?). Forskellen er grund nok i sig selv, fordi begge begreber er skrevet i sten. Og netop derfor bruges de meget præcist. Hvor godt de forstås af modtageren, er en anden snak.

Hvor godt trænet er du i "det andet sprog"? Har du samtaler med kolleger, hvor du nikker og ser interesseret ud, og bagefter lige så godt kunne have lyttet til en kineser? Sikkert ikke, og det er nok heller ikke så underligt, for når vort håndværk kræver en nøjagtig formulering for at virke, er det jo naturligt, at det at tale om håndværket kræver nogenlunde samme grad af præcision. Alligevel tænker jeg på, om man bliver bedre til at tale om programmering, ved at lære at programmere på en uddannelse, frem for at lære sig selv det. Da jeg i sin tid lærte at programmere (eller det jeg kaldte at programmere) på de gamle Commodore-maskiner (16, 64 og Amiga), var jeg kun i stand til at gentage det jeg kendte, og lave variationer over det samme tema. Det var først på gymnasiet, at min begrebsverden blev "voksen" (og ikke mindst udfordret), og jeg kunne løse mere komplekse opgaver. Man kan sige, at jeg gik fra at være i stand til at programmere til husbehov, til at vide hvad jeg gjorde. Uden af den grund at kunne alt.

En underviser jeg kender brugte engang en musikmetafor, for det at tale om programmering. Det er ellers sjældent, at der sættes ord på den del af programmeringskunsten, men pointen var, at det svarer til at sige til et band, "Vi spiller en blues i A-dur", eller "Vi spiller en reggae-rundgang over D-dur og A-mol". Samme kombinationer af begreber kaster vi glade om os i programmering, og så er spørgsmålet vel bare: Are you experienced?

Kommentarer (3)
sortSortér kommentarer
  • Ældste først
  • Nyeste først
  • Bedste først
Kasper Birch Olsen

Hej Michael

Når jeg siger til en kollega: Det kan du lave med dependency injection eller du bør bruge observer pattern osv. så fortæller jeg ham meget præcis hvordan opgaven kan løses. Men det forudsætter at vi har lært at tale det samme sprog om programmering: Design Patterns.

Ud over alt det tekniske i design patterns er de også et fælles sprog udviklere imellem til at beskrive fremgangsmåder for udviklingsopgaver. De svarer ikke på alle de udfordringer du nævner, men de er helt klart en vigtig del af "sproget om programmering".

  • 1
  • 0
Michael Niebuhr

Helt enig, Kasper.

Det er et godt eksempel på den begrebsverden der befinder sig over det, at bruge f.eks. delegering og events. Det kan man jo sagtens gøre, uden at vide at der findes et pattern der beskriver det man gør. Men skal man tale om hvad man gør, er det oplagt at starte med et pattern i sin forklaring.

Ikke at det af den grund gør det lettere for begyndere at komme med i samtalen, men det de evt. googler er så til gengæld meget konkret.

  • 0
  • 0
Esben Ravnholt Ovesen

Når nogen siger programmering, forstår jeg: den proces hvor man skriver i et sprog der bliver oversat til instruktioner som i den sidste ende bliver udført af en processor.

Men når nogen siger design, forstår jeg: resultatet af den proces hvor man arbejder med abstrakte begreber, struktur overvejelser, afhængigheder, dynamik og lignende. Dele som ikke kan fastholdes med programmeringssprog, men kan afspejles i det skrevne.

Jeg betragter derfor design sprog og programmerings sprog som to vidt forskellige ting.

Design pattern er ligesom en trille i musikkens verden eller et mønster i grafikkens verden. Deraf Pattern. Men det er et mønster i designet; Et mønster som går igen i mange forskellige design. Det er ikke programmering. Men det der skrives i programmeringssproget kan afspejle det. Som en skygge afspejler et træ.

Måske er jeg gammeldags når jeg godt kan lide at fastholde designet i sit eget sprog. Men min erfaring er at det er nemmere at bevare overblikket, når man ikke kun kender skyggen, men også ved hvad der kaster den.

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