Torben Mogensen header

Kend dit modersmål!

Den hollandske datalog Edsger Dijsktra er kilde til mange gode citater. Det citat jeg vil fokusere på i dag er fra hans Turing Award tale:

``Besides a mathematical inclination, an exceptionally good mastery of one's native tongue is the most vital asset of a competent
programmer.''

Den første del handler om matematisk sans. Bemærk, at der ikke er tale om matematisk viden, kun matematisk sans: Man behøver ikke kende til avanceret topologi eller C*-algebra, man skal blot kunne ræsonnere logisk og systematisk -- ligesom man gør i matematik.

Men det er den anden del af citatet, der er det vigtigste, blandt andet fordi det ofte bliver overset: Hvis man ikke i sit modersmål (som man har brugt i adskillige år) kan udtrykke sig klart, præcist, korrekt, entydigt og fuldstændigt, hvordan skal man så håbe at kunne udtrykke sig klart, præcist, korrekt, entydigt og fuldstændigt i et andet sprog, inklusive programmeringssprog?

Der er selvfølgelig forskelle mellem programmeringssprog og de såkaldte "naturlige sprog" såsom dansk og engelsk: Programmeringssprog har et langt mindre ordforråd end naturlige sprog og er ikke nær så afhængige af underforstået kontekst for at give entydig mening til tekster (programmer). Men en af de ting, der adskiller en kompetent sprogbruger fra en middelmådig sprogbruger er netop at kunne løsrive sig fra konteksten og udtrykke sig klart uden at underforstå en meget specifik kontekst, som læseren måske ikke har: Den middelmådige sprogbruger vil ofte appellere til modtagerens evne til at "forstå hvad jeg mener, og ikke hvad jeg siger". Computere har ikke denne evne, så man er nødt til at være præcis, entydig, komplet og korrekt i sin kommunikation med dem. Og det har (uanset sproget) kompetente sprogbrugere det nemmere ved. Det ser man også tit, når man retter opgaver: De studerende, der udtrykker sig uklart i tekst, har ofte også den dårligste kode i deres programmer.

Jeg vil dog lige skynde mig at sige, at ordblindhed ikke er en hindring for god programmering: Der har været forsøg, der viste at ordblinde kunne lære piktografiske sprog (som kinesisk) lige så let som andre, så ordblindhed har meget at gøre med den måde, indoeuropæiske skriftsprog er strukturerede og mindre med egentlig sprogsans. Så mit råd til ordblinde er: Vælg programmeringssprog, der minder mere om piktografiske sprog end om fonetisk skrift, f.eks. APL. Og mit råd til sprogdesignere er: Reducer brugen af keywords på engelsk eller dansk såvidt muligt og brug ikke-verbale symboler såsom matematiske symboler.

En artikel i The Register beskriver et programmeringssprog, der bruger arabisk skrift i stedet for det latinske alfabet. Et af argumenterne er, at traditionelle programmeringssprog er eurocentriske i deres brug af alfabet, hvilket giver "ikke-vestlige" en ulempe. Men dette sprog erstatter blot et sprogcentrisk alfabet med et andet sprogcentrisk alfabet, så det flytter blot problemet.

En anden ting, der adskiller middelmådige sprogbrugere fra kompetente ditto, er deres tyrkertro på, at en tekst er korrekt, når blot der ikke er røde bølgelinjer under teksten i Word: De er ikke i stand til at afgøre når Word tager fejl, og følger derfor blindt dens anvisninger. En kompetent sprogbruger bruger i stedet stave- og grammatikcheck til at fange slåfejl, men tager stilling til de råd, Word giver, og kunne godt undvære checket -- det ville blot kræve en ekstra gennemlæsning af teksten til korrektur. På samme måde er middelmådige programmører kendetegnet ved ikke at kunne undvære en IDE og have svært ved at finde fejl, som deres IDE ikke markerer, hvor en kompetent programmør bruger en IDE til at gøre sit arbejde hurtigere, men sagtens kunne undvære denne.

Så et godt råd til ledere, der vil ansætte programmører: Spørg ikke om, hvor mange års erfaring de har med Java, C eller lignende, men bed dem om at skrive en tekst på dansk eller engelsk. For eksempel en brugsanvisning til en tekande eller reglerne til kryds-og-bolle. Hvis de kan gøre dette, så det er forståeligt for folk, der ikke har set en tekande før eller aldrig spillet kryds-og-bolle, så skal de nok også være gode programmører.

Kommentarer (24)
sortSortér kommentarer
  • Ældste først
  • Nyeste først
  • Bedste først
David Rechnagel Udsen

Dansk - og især tysk - har en fordel mod engelsk; det er lettere at være mere præcis med færre ord. Stedordet »sin«/»sit« er ofte forhadt eftersom så få kan finde ud af det, og dem der ikke kan finde ud af det er forhadt af dem der kan. Men dette stedord gør det muligt at være meget præcis med relativt få ord.

Eksempel: »Min bror og hans fætter tog hen til sin mor.« Refererer »sin« til broren eller fætteren? Svaret er simpelt nok dog; der tales om broren, da det er det overordnet subjektiv. Havde man sagt »min bror og hans fætter tog hen til hans mor«, ville det være fætterens mor.

Det er simple sætninger man ikke kan skabe på engelsk, ej heller fransk (hvor de kun har »sin«/»sit«, men ikke »hans«/»hendes«/etc.). Tysk går heldigvis videre med sine kasus.

En kort sætning som „einem Wasser” har „Wasser” i akkusativ, hvilket - i denne kontekst - betyder at få bragt vand til en.

Men præcision i sproget gør også sproget ekstra svært at lære. Engelsk har som modsvar på sin manglende præcision i sin grundlæggende grammatik, valgt at øge sproget med nuancer i form af nye begreber og vendinger, der gør engelsk til - i hvert faldt påståede - det største sprog, i antal af begreber.

F.eks. »Han var en stor mand«. Af konnotationers grunde, vil man i en dansk sammenhæng mene at »stor« her betyder »storslået« (altså en positiv konnotation) og ikke f.eks. »tyk«, at der så er tale om en fysisk beskrivelse. Men bytter man objektivet »mand« ud med et andet navneord, vil konnotationerne måske ikke være lige så tydelige. Engelsk har til dette formål forskellen på »stor«s betydninger i form af 'big' og 'great', hvis konnotationer ikke er til at være i tvivl om.

Til gengæld, så tillader dansk og tysk bedre længere sætninger end engelsk gør. Lange sætninger - med mange kommaer - på engelsk er til at gå død i. Jeg synes Edward Gibbons The History of the Decline and Fall of the Roman Empire er en formidable læsning, men man kan godt mærke at værket er skrevet i 1770erne, hvor længere sætninger - og masser af bisætninger - stadig var velset på engelsk.

Kants Kritik af den sunde fornuft derimod viser blot, at tysk sagtens magter opgaven med lange sætninger. Men som BBC-instruktøren siger i Yes Prime Minister "The Ministerial Broadcast", »problemet med lange sætninger er, at når man kommer til enden, så har de fleste glemt hvor den startede«.

  • 4
  • 1
Poul-Henning Kamp Blogger

Her afhænger resultatet af om det er en matematiker eller fysiker man har foran sig.

For dem der ikke kender vittigheden:

Q: Hvordan kan man kende forskel på en matematiker og en fysiker med et tekøkken ?

A: Bed dem lave te, det kan de begge finde ud af. Fyld derefter kedlen med vand, vent til den koger, bed dem igen lave te. Fysikeren gør det, matematikeren slukker derimod kedlen, hælder vandet ud og annoncerer at han nu har reduceret det til et allerede løst problem.

  • 3
  • 0
Martin Hundebøll

Jeg har længe være den irreterrende type, der venligt retter min nærmeste, når de bruger "hans" i stedet for "sin". Først for nylig gik det op for mig, at jeg ynder at bruge sproget så præcist og entydigt som muligt, og at grunden nok skal findes i mit hverv som udvikler; jeg er simpelthen vænnet mig til, at hvis jeg udtrykker mig entydigt, så virker mine programmer ikke...

  • 2
  • 0
Kai Birger Nielsen

Jeg har også bandet over nøgleord af og til. Fx husker jeg et af mine første pascal-programmer, som det tog en krig at få til at oversætte, fordi jeg havde brugt variabelnavnet card. (Programmet simulerede en kabale.)
På den anden side så har jeg også af og til snublet over matematiktekster, hvor forfatteren har syntes at græske bogstaver fra den sidste del af alfabetet skulle mikses med X'er, Z'er og x'er og z'er sat med fed og kursiv osv.

Så ja, en eller andet behersket brug af symboler i stedet for nøgleord er sikkert at foretrække. Navnlig hvis oversætteren er i stand til at yde fornuftig hjælp i tilfælde af fejl.

Jeg tøver en lille smule med at henvise til lisp og python (paranteser og indrykning), men det er jo samme problemstilling, de har forsøgt at løse.
Designovervejelserne for de to sprog kunne sikkert være værd at kigge lidt på.

  • 0
  • 0
Palle Due Larsen

David, dit eksempel er desværre ikke korrekt.

Min bror og hans fætter tog hen til sin mor

"Sin" henviser til et entalssubjekt, man bruger "deres" i flertal.
Et bedre eksempel er:
Min bror så min fætter kysse hans/sin kone

  • 4
  • 0
Morten Bøgh

Antag at systemudvikling er at arbejde sig fra en beskrivelse med stor overskuelighed - men manglende præcision - frem til den helt præcise beskrivelse af problemet: nemlig den beskrivelse der formuleres i programmerings-sproget. At test går ud på at finde hullerne (dvs. defekter i præcisionen) i denne beskrivelse.
Men hvor tæt programmerings-evner er knyttet til evner for for dagligsprog, er vel svært at indkredse. Autister har typisk dårlige evner i dagligsproget, men har ofte gode evner for programmering.
Den modsatte vinkel er mere givende: Hvilke systemudviklings-teknikker fanger dette aspekt bedst? Hvilke teknikker understøtter bedst antagelsen om at programmering er et spørgsmål om sproglig kreativitet og formulering af et overblik over kundens problem-område? Et banalt - og ret forkert - svar var i sin tid COBOL, som brystede sig af at formuleringerne var tæt på engelsk dagligsprog. (...IF SALDO GREATER THAN COMPANY-LIMIT OR CUSTOMER-LIMIT THEN DIVIDE A BY B GIVING C ROUNDED REMINDER E). (Et aspekt som er meget nedtonet i moderne COBOL). Et andet bud som muligvis ikke er meget bedre, er 'objektorienteret programmering' som oprindeligt tog udgangspunkt i at den fysiske verden består af objekter, dvs instanser af black-boxe med informationer indeni, som reagerer forudsigeligt når man sparker til dem på veldefinerede måder. Det er en noget flimrende beskrivelse af verden, som ikke siger meget om hvordan de store linier fungerer. Et problem er også at ikke al programmering hander om den fysiske virkelighed, det er ofte mere abstrakte begreber, fx kreditværdighed eller markedsførings-strategier, der er focus. Det er vel heller ikke fordi vi ser verden som bestående af objekter, at alle programmerer objektorienteret i dag, det er vel nærmere fordi at objektorienteret programmering har vist sig at være et udmærket setup til programmering af komplekse brugergrænseflader.

Interessant i denne forbindelse er den klassiske tilgang til relationsdatabaser, eller SQL-databaser. Her opstiller man i data-analysen et begrebsapparat: kunder, varer, saldi, handler, etc. Problemformulering og programmeringen efterfølgende går så ud på at arbejde med disse begreber (bla. opstille relationer mellem begreberne) for at løse kundens problem. Det viser sig typisk undervejs at begreberne ikke er dækkende nok eller præcise nok, man itererer så, og ændrer eller udvider data-grundlaget for opgaven. Der er således to led i processen: dels konstruerer man opgavens sproglige begreber, og dels specificerer man løsningen ved brug af dette sprog. Øvrige systemudviklinsmodeller er mere monolitiske: 'alt er objekter', 'databasen er persistence-laget: der hvor data hviler sig når lyset er slukket'. Eller SAP-modellen: man putter løsningen ind i det database-design som leverandøren har, og hopper dermed over data-analyse-fasen. Eller den klassiske CASE-model: man laver data-analysen, og går ud fra at systemet herefter laver sig selv (via CASE værktøjet). Man kan helt sikkert udvikle suveræne systemer uden at bruge tid på data-analyse (især hvis området er så modent at data-analysen er lavet før), eller uden adskillelse af dataanalyse og programmering, men hvis Dijsktra har ret i at programmering har et sprogligt aspekt, så er en adskillelse af (1) begrebsdannelse og (2) sproglig formulering med brug disse begreber nok ikke decideret tosset.

  • 0
  • 0
Log ind eller Opret konto for at kommentere
IT Company Rank
maximize minimize