Paradigmer i Programmering - akira.ruc.dk

Paradigmer i programmering 

- Om hvor man skal starte i programmeringsundervisningen 

John Elbek Basbous — jelbekb@ruc.dk 

Frank Biel Knudsen — fbk@ruc.dk 

Andreas Westh — awesth@ruc.dk 

Nikolaj Alstrøm Christiansen — nialch@ruc.dk 

Christian Bohr-Halling — cbh@ruc.dk 

Jon Hørup Langeland — kemo@discworld.dk 

Vejleder: 

Keld Helsgaun — keld@ruc.dk 

20. december 2003 

Roskilde Universitetscenter 

Naturvidenskabelig Basisuddannelse Hus 13.2 

3. semester

Resumé 

Rapporten omhandler hvilket paradigme man bør undervise i ved det introducerende 

programmeringskursus. 

I rapporten gennemg˚as definitionen p˚a et paradigme generelt, og i forbindelse med 

programmering. Vi beskriver de fire hovedparadigmer: det logik –, funktions –, imperativ, 

– og det objekt-orienterede paradigme. Derudover gives en kort forklaring af tankegangen 

bag multi-paradigmet. 

Rapportens konklusion bygger p˚a et litteraturstudie af over 50 forskellige artikler, der 

udtaler sig om paradigmer og undervisning. Konklusionen afhænger af hvilken synsvinkel 

man har p˚a programmering. Der konkluderes udfra to synsvinkler. 

Vi er n˚aet frem til, at hvis man har en teoretisk synsvinkel p˚a programmeringen, vil det 

være en fordel at starte undervisningen i et multi-paradigme. Er synsvinklen anvendelses 

orienteret, bør paradigmet være objekt orienteret. 

Abstract 

Paradigms of programming – Where to begin the teaching of programming 

The purpose of this report is to examine which paradigm should be taught in the first 

course of computer science. We describe the paradigm concept in general and in relation 

to computer programming. Furthermore we describe the 4 major paradigms(logical, 

functional, imperative and objectoriented) and briefly explain the concepts of the multiparadigm 

language. 

Our conclusion is based upon a study of more than 50 articles concerning the paradigms 

and teaching. The final conclusion depends on which of the two perspectives(listed below) 

are concidered: 

Teaching in the multiparadigm language would be an advantage if the student takes a 

theoretical approach towards programming. 

The objectoriented paradigm is recommended if the student takes an applicational 

approach towards programming.

Indhold 

1 Indledning 5 

1.1 Indledning . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 

1.2 Problemformulering . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 

1.3 Afgrænsning . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 

1.4 Metode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 

1.5 Motivation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 

1.6 M˚algruppe . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 

2 Hvad er et paradigme 8 

2.1 Programmering . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 

2.2 Paradigmer i programmering . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10 

2.2.1 Paradigmatiske retninger for programmeringen . . . . . . . . . . . . . . . 10 

3 De procedurale paradigmer 12 

3.1 Det imperativt orienterede paradigme . . . . . . . . . . . . . . . . . . . . . . . . 12 

3.1.1 Paradigmet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12 

3.1.2 Sætninger i det imperative paradigme . . . . . . . . . . . . . . . . . . . . 13 

3.1.3 Historie . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14 

3.1.4 Opsummering . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14 

3.2 Det objektorienterede paradigme . . . . . . . . . . . . . . . . . . . . . . . . . . . 15 

3.2.1 Objekter . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15 

3.2.2 Klasser . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15 

3.2.3 Nedarvning . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16 

3.2.4 Historie . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16 

3.2.5 Opsummering . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17 

4 De deklarative paradigmer 18 

4.1 Det funktionsorienterede paradigme . . . . . . . . . . . . . . . . . . . . . . . . . 18 

4.1.1 Paradigmet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18 

4.1.2 Historie . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23 

4.1.3 Opsummering . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23 

4.2 Det logikorienterede paradigme . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24 

4.2.1 Generelt . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24 

4.2.2 Paradigmet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24 

4.2.3 Logik i programmering . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25 

4.2.4 Eksempler i Prolog . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26 

4.2.5 Historie . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27 

4.2.6 Opsummering . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28 

5 Multiparadigmet 29 

3

Paradigmer i programmering 

6 Præsentation af fordele og ulemper ved paradigmerne 30 

6.1 Imperative . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30 

6.1.1 Fordele . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30 

6.1.2 Ulemper . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30 

6.2 Objektorienteret . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31 

6.2.1 Fordele . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31 

6.2.2 Ulemper . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32 

6.3 Deklarativ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32 

6.3.1 Fordele . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32 

6.3.2 Ulemper . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33 

6.4 Multiparadigmet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33 

6.4.1 Fordele . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33 

6.4.2 Ulemper . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34 

7 Undersøgelse 35 

7.1 Om undersøgelsen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35 

7.2 Forventninger til undersøgelsen . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35 

7.3 Resultat . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36 

8 Diskussion 38 

8.1 Anvendt datalogi — Datamatik. . . . . . . . . . . . . . . . . . . . . . . . . . . . 39 

8.2 Teoretisk datalogi . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40 

9 Konklusion 42 

10 Perspektivering 43 

20. december 2003 Roskilde Universitetscenter 4

Kapitel 1 

Indledning 

1.1 Indledning 

Uddannelse er et vigtigt element for at kunne klare sig p˚a arbejdsmarkedet i et udviklet samfund 

som det danske. Nogen g˚ar endda s˚a langt som at sige, at uddannelse er Danmarks vigtigste 

r˚astof, og i fremtiden m˚aske det eneste med reel betydning for samfundet. For at skabe gode 

uddannelser er det vigtigt at undervisningen ogs˚a er tilsvarende. 

Det er nødvendigt at gøre sig nogle overvejelser omkring undervisningsmetoder, pædagogik 

og m˚alsætningen for undervisningen, for eksempel hvilke dele der bør vægtes højt og hvilke der 

ikke har relevans. Endvidere indenfor hvilke emner i fagomr˚adet man bør p˚abegynde og afslutte 

undervisningen i. 

Som et banalt eksempel kunne man stille spørgsm˚al ved, om man inden for den matematiske 

videnskab skal starte med undervisning i addition eller multiplikation. I dette eksempel ville 

det være oplagt at starte med addition og se multiplikation som en udvidelse af dette koncept. 

Lige s˚a indlysende behøver det ikke at være i andre undervisningssituationer. 

Vores rapport tager udgangspunkt i datalogiundervisningen, og hvor i dette undervisningsomr˚ade 

eleverne f˚ar mest ud af at starte deres undervisning. 

Hvilket paradigme, eller programeringsmæssig tankegang, f˚ar eleverne det bedste grundlag 

for deres videre uddannelse? Vil det for eksempel være en fordel for de studerende at starte 

med objektorienteret programmering frem for noget andet? 

Overvejelserne for universiteterne og de studerende kunne g˚a p˚a, om det er form˚alet at 

tilgodese erhvervslivets interesser eller om det er vigtigere, at de studerende f˚ar en generel 

forst˚aelse for programmering, s˚aledes at de senere hen vil f˚a lettere ved at sættes sig ind i nye 

omr˚ader af datalogien. 

Overvejelser som disse er et glimrende oplæg til 3. semester p˚a den Naturvidenskabelige Basisuddannelse 

ved Roskilde Universitetscenter, hvor arbejdet skal dreje sig om naturvidenskaben 

som et kulturelt og samfundsmæssigt fænomen ud fra overskriften ” Refleksion over naturvidenskab 

og naturvidenskabsformidling“. 

Projektet har netop som helt centralt punkt overvejelser og reflektioner omkring undervisning 

i programmering, og undervisningen som s˚adan er netop et vigtigt element i forhold til 

b˚ade kultur og samfund. 

5

Paradigmer i programmering Kapitel 1.6 

1.2 Problemformulering 

Vi vil anskue programmeringsundervisningen udfra to tilgangsvinkler: 

En teoretisk tilgangsvinkel med programmeringens grundprincipper i fokus. En anvendelses 

orienteret tilgangvinkel med fokus p˚a praktisk anvendelses af programmering og planlægning. 

Vi opstiller følgende spørgsm˚al: 

Hvilket paradigme er mest hensigtsmæssigt at anvende til introducerende programmeringsundervisning, 

for hver af de to tilgangsvinkler? 

1.3 Afgrænsning 

Vi har valgt at beskæftige os med hvilket paradigme, der vil være mest hensigtsmæssigt at 

starte programmerings undervisning i, p˚a videreg˚aende datalogiske uddannelser. Det forventes 

ikke, at de studerende har modtaget nogle forudg˚aende undervisning indenfor programmering. 

Vi vil i rapporten kun forholde os til, hvilket paradigme man skal anvende, og konkluderer 

alts˚a ikke noget om konkrete programmeringssprog. Vi vil enkelte steder bruge konkrete program 

eksempler i rapporten for at tydeliggøre forst˚aelsen af de enkelte paradigmer. ˚ Arsagen 

til vi ikke har valgt at se p˚a konkrete sprog, men paradigmer istedet, er for at give rapporten 

et bredere perspektiv. Ved at se p˚a paradigmer istedet for sprog vil konklusionen være mere 

generel anvendelig. 

1.4 Metode 

For at besvare problemformuleringen, starter vi med at undersøge, hvad et paradigme er, b˚ade 

generelt i forhold til programmering og datalogi. Dette gør vi med henblik p˚a at f˚a en mere præcis 

forst˚aelse af paradigme-begrebet, og bedre kunne definere hvilke aspekter, der efterfølgende er 

relevante at behandle i rapporten. 

Herefter vil vi skabe os en forst˚aelse for de enkelte hovedparadigmer i programmeringen 

og hvad tankegangen er i disse. Dette gøres ud fra et studie af litteraturen for de forskellige 

programmeringsparadigmer. 

Vi vil dernæst forsøge at opstille fordelene og ulemperne i forhold til de enkelte paradigmer 

i programmering, og senere hen vurdere disse ud fra den introducerende programmeringsundervisning. 

Fordele og ulemper vil vi dels f˚a fra artikler, og dels fra en undersøgelse af praksis 

p˚a danske universiteter og datamatiker-skoler, med hensyn til førstgangsundervisningen i programmering. 

I undersøgelsen vil vi kontakte universiteter og datamatiker-skolerne via e-mail, 

for at undersøge deres overvejelser de har omkring førstegangsundervisningen i programmering. 

Dette vil desuden være med til at give os et billede af, hvilke paradigmer der rent faktisk 

anvendes aktuelt p˚a uddannelsesstederne i Danmark, og kan anvendes i forbindelse med en 

perspektivering. 

Da man ikke umiddelbart kan komme med en generel udtalelse om hvilket paradigme, man 

skal starte med at undervise i, valgte vi at arbejde udfra de to tidligere nævnte tilgangsvinkler. 

I diskussion vil vi ikke vurdere hvilken tilgangsvinkel der er den korrekte, men mere hvilket 

paradigme der bør anvendes inden for hver tilgangsvinkel. 

1.5 Motivation 

Vi har i de to første semestre p˚a NatBas haft kurser og projekter inden for det datalogiske 

omr˚ade, hvor vi hovedsageligt har beskæftiget os med datalogien indefra. Det betyder, at vi 

ukritisk har arbejdet inden for programmeringen. Vi mener det kunne være interessant at se 

p˚a datalogien mere udefra, hvilket netop er muligt i dette projekt, samt at f˚a et indblik i de 

forskellige programmeringsparadigmer. 


Kapitel 1.6 Paradigmer i programmering 

1.6 M˚algruppe 

Projektet henvender sig til personer med interesser for introducerende undervisning inden for 

programmering i datalogi. Der stilles indledende forudsætninger inden for programmering for 

at kunne forst˚a indholdet i rapporten; dette kunne være Datalogi A p˚a NatBas p˚a RUC. 

Der anbefales, at læseren har et grundlæggende kendskab til matematik, der svarer til et 

gymnasielt B–niveau. Dette skyldes at der optræder matematiske ligninger, symboler og lignende 

under beskrivelsen af funktions- og logik paradigmet. 

7 Roskilde Universitetscenter 20. december 2003

Kapitel 2 

Hvad er et paradigme 

I dette kapitel vil vi gennemg˚a hvad et paradigme generelt er. Vi beskriver bagefter de enkelte hovedparadigmer 

inden for programmering. Paradigmer som begreb er et hovedelement i denne rapport, derfor 

finder vi det nødvendigt at gennemg˚a. 

Et paradigme er i følge[Nudansk92] defineret som følgende 

Arbejdsmetoder og antagelser, som p˚a et givet tidspunkt er anerkendt som grundlæggende 

inden for et videnskabeligt omr˚ade, og som præger forskningen inden for dette. 

Et paradigme er alts˚a overordnet et grundsyn for, hvordan man anskuer en given videnskab 

og verden. S˚adan et grundsyn vil p˚avirke, hvordan man arbejder inden for en videnskab. Det 

kommer for eksempel til udtryk ved, at man tager udgangspunkt i visse antagelser og arbejder 

ud fra dem eller bygger videre p˚a dem. 

Især videnskabsteoretikkeren Kuhn har gjort sig tanker om paradigmebegrebet og videnskab. 

Kuhn ser videnskaben som værende strengt opdelt i paradigmer. Det vil sige, en given videnskab 

vil kun udfolde sig inden for ét paradigme ad gangen [Kuhn73]. Der vil generelt set kun være et 

paradigme ad gangen. Et paradigme kan dog blive afløst af et nyt og lovende paradigme, hvis 

der over tid er sket en opsummering af anomali i modstrid med det eksisterende paradigme, hvis 

dette nye og lovende paradigme p˚a samme tid kan forsvare denne anomali ud fra andre antagelser 

— betegnet Kuhnske revolutioner[Kuhn73]. Anomali forst˚as for eksempel som observationer, 

paradigmets teorier ikke kan forklare. Hvis et paradigme opererer med, at jorden er flad, s˚a vil 

et eksempel p˚a anomali være, at skibe kan sejle rundt om jorden uden at falde ud over en kant. 

Arbejdet, der udføres under et Kuhnsk paradigme, kaldes normalvidenskab og best˚ar i et 

” rengøringsarbejde“. Det vil sige, at man kun arbejder med en præcisering, for eksempel af teorier 

med mere inden for paradigmet. Det kunne for eksempel være at opn˚a en bedre samordning 

mellem forskellige teorier inden for paradigmet eller mere præcis bestemmelse af forskellige observationer. 

Man arbejder ikke p˚a at komme væk fra det gældende paradigme eller at opdage et 

nyt. Man arbejder netop under pardigmet, og p˚a denne m˚ade er dette alts˚a en styrende faktor 

— og m˚aske ogs˚a begrænsende. 

I den normalvidenskabelige fase er der mellem de videnskabelige aktører konsensus om blandt 

andet værdier; et eksempel herp˚a kunne være hvilke kriterier, man kræver opfyldt før teorier 

kan accepteres; et andet eksempel er de helt overordnede metafysiske antagelser om hvordan 

verden er opbygget (er den for eksempel flad eller rund; findes Gud eller ej; osv.). De omr˚ader, 

man finder relevant at forske i, styres af paradigmet, og dermed er der ingen reel objektivitet, 

da man allerede er p˚avirket af paradigmet og dermed ogs˚a i forhold til de ting, man overhovedet 

stiller spørgsm˚al ved.[Kragh91] Samlet set er paradigmet altdominerende og som udgangspunkt 

hævet over enhver tvivl. At rokke ved dette udgangspunkt kræver, som tidligere skrevet, en 

opsummering af anomali og et muligt afløserparadigme. 

En banal illustration af den styring, den forudindtagede tankegang, paradigmet hermed medfører, 

kan ses p˚a Figur 2.1. Figuren ses og tolkes oftest p˚a to m˚ader — som en hjort“ eller som 

” 

8


en ” fugl“ — i dette tilfælde er der ikke nogen korrekt tolkning. Den umiddelbare opfattelse styres 

af individets forudg˚aende oplevelser, erfaringer, pavirkninger og lærdom. Det er det samme 

med paradigmerne i videnskaben. N˚ar man først konsekvent opererer inden for et paradigme 

— f.eks. hjorteparadigmet, som vi jo kunne kalde det her — vil hele ens verdensanskuelse være 

kontrolleret af dette, og man vil s˚aledes sandsynligvis kun se netop hjorten. 

Figur 2.1: Fugl eller hjort[Kragh91] 

Det bør m˚aske bemærkes, at den Kuhn’ske opfattelse af rengøringsarbejdet ikke er negativt 

ladet, da arbejdet medfører et klarere og mere præcist billede af det aktuelle paradigme. I sidste 

ende er det ligeledes rengøringsarbejdet, der ligger til grund for, at der senere kan komme et 

paradigmeskift p˚a tale. Uden dette arbejde ville en afdækning af anomalier ikke ske [Kuhn73]. 

2.1 Programmering 

For at forst˚a, hvad programmering er, bliver man først nødt til at forst˚a, hvad et program er. 

Et program er det, der f˚a en computer til at udføre et bestemt handlingsforløb.Man kan kalde 

det for en slags forskrift. Programmet skrives i et programmeringssprog, som gøres forst˚aligt 

for computeren. 

Man kan kort definere et program som: 

Program: En komplet samling sætninger, udformet i alle detaljer i et programmeringssprog, 

med det form˚al at f˚a en computer til at udføre en p˚a forh˚and fastlagt og afrundet 

opgave.[itLex01] 

Programmering er s˚a den proces, hvor man udarbejder og udvikler programmet. 

Lige som nævnt i Kuhn’s paradigmeopfattelse, vil der ogs˚a være en vis styring — og m˚aske 

endda begrænsning — af tanker, løsningsmetoder og udtryksm˚ader, n˚ar man opererer under et 

bestemt programmeringsparadigme. 

Rent teknisk er det muligt at udtrykke det samme inden for alle programmringsparadigmer 

s˚a længe et givet sprog under et givet paradigme stiller en løkke- og en betingelseskonstruktion til 

r˚adighed 1 — dog med variationer i udtryksvanskeligheder[Budd95b] — s˚a teknisk begrænsende 

og styrende kan man ikke umiddelbart kalde et programmeringsparadigme. Det er i stedet netop 

udtryksvanskelighederne, paradigmet blandt andet er med til at bestemme styrken af. Der er for 

eksempel store udtryksvanskeligheder i at skulle udtrykke numeriske beregninger blot ved hjælp 

af logiske sammenhænge. Et paradigme inden for ren logik ville derfor ikke være hensigtsmæssigt 

at anvende i denne sammenhæng. 

Dette kan illustreres med ganske almindelig menneskesprog, som har rødder i forskellige 

kulturer . Hvis man p˚a grønlandsk skulle udtrykke ” sand“ ville man have større udtryksvanskeligheder 

i forhold til, hvis man ville udtrykke ” sand“ i et sprog med baggrund i den nordafrikanske 

kultur . Dette skyldes, at sprog indhørende under den nordafrikanske kultur formentlig 

har flere definitioner til r˚adighed, n˚ar det kommer til en præcis fremstilling. ” Sand“ er hører 

naturligt ikke ikke ind under den grønlandske kultur, s˚a overhovedet at komme p˚a den tanke at 

1 Rekursion er et eksempel p˚a en anden løkkenkonstruktion end den normale imperative 



udtrykke det ved en given lejlighed er ogs˚a begrænset af denne kultur — og p˚a samme m˚ade er 

det selvfølgelig, hvis man vil udtrykke sne i et sprog med baggrund i den nordafrikanske kultur. 

P˚a denne m˚ade er kulturen med til at styre/begrænse udtryksmuligheder og tankem˚aden. 

Talesprog udspringer fra kulturere og har alt efter oprindelse forskellige udtrykmuligheder. 

Overført til programmeringsverden, hører de forskellige programmeringssprog ligeledes til, under 

overordnede paradigmer med individuelle udtryksmuligheder, hvorfor det kan være mere 

hensigtsmæssigt at udtrykke ” Sand“ indenfor et paradigme frem for et andet. 

Illustrationen med kultur (paradigmer) og menneskesprog (programmeringssprog under paradigmet) 

herover, skulle gerne give en intuition for, at programmeringsparadigmer og programmeringssprog 

netop har samme problemstillinger tilfælles, og at der overordnet er paradigmatiske 

krafter p˚a spil i forhold til styring af programmeringsretninger — ogs˚a selvom sprog inden 

for paradigmerne teoretisk set kan udtrykke det samme, men dette blot med forskellige grader af 

vanskeligheder. Et programmeringssprog inden for et givet programmeringsparadigme er i kraft 

netop af paradigmet begrænset i at kunne udtrykke konstruktioner, og paradigmet er dermed 

ogs˚a begrænsende for hvad, der reelt bliver udtrykt af en given programmør. 

Der er ikke hovedsagligt, som ved Kuhns paradigmer, tale om monoparadigmel styring, da 

man netop i progammeringen opererer inden for flere forskellige paradigmer — til tider endda 

p˚a samme tid. Man ” tillader“ alts˚a flere paradigmer at eksistere p˚a samme tid i den datalogiske 

verden uden de nødvendigvis ses som værende konkurrenter, og uden at man kan pege p˚a 

dét optimale paradigme. Faktisk g˚ar man s˚a langt, at paradigmerne ikke er strengt opdelte i 

reelanvendelse da man godt kan operere inden for forskellige paradigmer p˚a samme tid. Der 

tænkes her konkret p˚a, at der i mange programmeringssprog er tale om, at de understøtter flere 

forskellige paradigmer, hovedsagligt to. Der findes dog flere sprog som for eksempel Leda, der 

understøtter op til fire[Spinellis93]. 

Til forskel fra Kuhn’s paradigmetankegang er der — i hvert fald ikke foreløbig — tale om ét 

paradigme, der ender med at omstyrte et eller flere andre paradigmer. Dette skyldes formentlig, 

at datalogien som videnskab er s˚a ung. 

2.2 Paradigmer i programmering 

Et programmeringsparadigme kan defineres som følgende: 

A programming paradigm is a way of conceptualizing what it means to perform computation, 

and how tasks that are to be carried out on a computer should be structured and 

organized[Budd95b] 

N˚ar man snakker om paradigmer inden for programmering, er der ikke tale om præcis det 

samme paradigmebegreb som inden for den generale videnskab, da der kan være flere paradigmeopfattelser 

p˚a samme tid. S˚a et nyt programmeringsparadigme er ikke nødvendigvis et 

aftagerparadigme, som i følge Kuhn er tilfældet inden for videnskaben. 

Programmeringsparadigmer er alts˚a en begrebsliggørelse af, hvad det vil sige at programmere. 

En overordnet tankegang for, hvordan verden af programmering hænger sammen, er 

en anden m˚ade at betragte programmeringsparadigmer. Er det for eksempel i programmering 

smartest at se verden som best˚aende af enkeltst˚aende objekter, der arbejder sammen (objektorienteret 

programmering), eller skal den ses som matematikske funktioner, der kan bruge 

hinanden som in- og output (funktionsorienteret programmering). Skal programmering være 

om at opstille logiske sammenhænge (logikorienteret programmering) eller skal det handle om 

at lave kørselsopskrift for computeren (imperativt orienteret programmering). 

2.2.1 Paradigmatiske retninger for programmeringen 

Ud fra C. Ghezzi og M. Jazayeri, ” Programming Language Concepts ” , John Wiley and Sons, 

1987 som er citeret i John Placer, ” Multiparadigm Research“ [Placer91] er vi n˚aet frem til, at 

der primært er tre retninger, man anskuer programmering og paradigmer. 



A Paradigmerne skal holdes adskilte i forhold til anvendelse. Man skal alts˚a i et programmeringssprog 

kun understøtte ét paradigme. Hvilket paradigme, et program skal udvikles 

under, bestemmes af typen af programmet, der skal udvikles. 

B 

Ét paradigme skal bruges til alt. Det vil sige, at alle programmer skal kunne udvikles 

under ét paradigme. 

C Paradigmer skal samles under én hat s˚aledes, at man i et givet sprog kan anvende flere 

paradigmer direkte. 

Der er fordele og ulemper ved dem alle. A er acceptabel, n˚ar man i udviklingen har separate 

problemstillinger, men s˚a snart der er tale om, at disse indhører under samme projekt, kommer 

der en konflikt. Enten m˚a man vælge ét paradigme ud og programmere det hele under det, eller 

skrive forskellige dele af det samlede program under forskellige paradigmer. Det førstnævnte er 

ikke altid en mulighed uden besvær (f.eks. matrix-beregninger under logik-paradigmet), og det 

sidstnævnte giver ikke plads til, at man direkte kan trække p˚a elementer tilhørende forskellige 

paradigmer. 

B kan forsvares ud fra, at man kun behøver at skulle arbejde med et paradigme, og af den 

grund ville kunne komme mere i dybden og opn˚a en bedre forst˚aelse for paradigmet. B er ikke 

optimalt ud fra det argument, at det ikke giver mening at sammenligne paradigmer generelt i 

den forstand, at man ikke bare overordnet kan sige, ét paradigme er bedre end et andet. Er det 

for eksempel altid bedre at se verden som en samling af objekter, eller er det altid bedre at se 

den som funktionsrelationer? Det giver ikke mening at skulle lave denne sammenligning og en 

konklusion p˚a, hvilket ene paradigme, der s˚a er dét bedste, da man netop s˚a skal ind og m˚ale 

p˚a diverse forudsætninger og antagelser omkring verden. Det ville svare en smule til, at skulle 

udtale sig om, hvilken religion er den mest rigtige. 

Dette leder frem til C. Her kan man operere direkte inden for flere og endda mange paradigmer 

p˚a én gang, fx Java der understøtter b˚ade det imperative og objektorienterede paradigme. 

P˚a denne m˚ade er man ikke bundet rent mentalt og tankemæssigt i sine muligheder for udfoldelse. 

Man bliver herved befriet fra et snævert og m˚aske ensporet syn p˚a verden gennem netop 

ét paradigmes begrænsninger. Man kan s˚a tvivle p˚a, om alle disse muligheder, hvis et sprog 

understøtter mange paradigmer p˚a en gang, er til at styre hensigtsmæssigt, eller det ender i et 

stort kaos af sammenblandede løsningsmuligheder og paradigmer. 


Kapitel 3 

De procedurale paradigmer 

De proceduralle paradigmer har procedurer som en essentiel strukturerende metode. En procedure 

defineres som et underprogram, der kan kaldes fra et andet underprogram eller et hovedprogram, 

og som selv kan kalde andre procedurer[itLex01]. 

Procedurer kan eventuelt videreindkapsles i objekter[itLex01], s˚a som i det objektorienterede 

paradigme, eller være den grundlæggende struktureringsmetode s˚a som i det imperative 

paradigme. 

Det objektorienterede paradigme skal ikke nødvendigvis forst˚as som en forlængelse af det 

imperative paradigme. 

3.1 Det imperativt orienterede paradigme 

3.1.1 Paradigmet 

Hvis man sl˚ar ordet imperativ op i en ordbog, finder man følgende definition. 

Imperativ(navneord); 1.a. En kommando; en ordre.[dictionary.reference.com, imperative] 

Denne definition passer godt sammen med den reelle definition p˚a det imperative paradigme, 

som bliver defineret p˚a følgende m˚ade af Lehmann[Lehmann]. 

In imperative programming, a program is regarded as (partially ordered) sequence of actions 

(procedure calls) manipulating a set of variables. 

Det imperative paradigme kan alts˚a defineres som en række kommandoer til maskinen, 

hvorved der udføres nogle handlinger, som ændrer tilstande af variabler. 

For at gøre det mere overskueligt kan der opstilles tre definitions punkter.[Budd95c, side 

26]. 

• Sekventiel udførelse af kommandoer. 

• Programmering med sideeffekter. 

• Maskinorienteret struktur, b˚ade data og kontrol ligger opad arkitekturen i en datamaskine. 

Sekventiel udførelse af kommandoer kan karakteriseres ved sekventielt/trinvist manipulation 

af et sæt variabler. Herved menes tilstandsændring af en mængde variabler, lagret i computerens 

hukommelse, En pædagogisk beskrivelse af det imperative paradigme, er at det kan forst˚as som 

en detaljeret opskrift. Med detaljeret opskrift menes at programmer skrevet p˚a imperative form, 

følger kommandoerne trin for trin, linje for linje og fra top til bund. 

12


Sideeffekter, der er et af de tre tidligere definerende punkter for det imperative paradigme, kan 

karakteriseres i programmering som alle andre p˚avirkninger end den efter hensigten primære 

p˚avirkning.[Horstmann03, side 832]. En sideeffekt kunne mere konkret være, hvis et procedurekald 

medfører, at en variabel i den omgivende programkode uden for procedurens kode bliver 

ændret af proceduren. Der sker p˚a den m˚ade mere end der umiddelbart kan forventes af et 

s˚adan procedurekald. 

Inspirationen til det imperative paradigme er hentet fra datamaskinerne. Datamaskiner anvender 

den selv samme teknik, som det imperative paradigme; en maskin-instruktion udføres en 

efter en. En computer følger et mønster af maskin-instruktioner, hvor hver instruktion f˚ar processoren 

til at hente nogle bestemte værdier fra hukommelsen, hvorefter deres tilstand ændres 

og de placeres igen p˚a deres specifikke plads i hukommelsen. N˚ar beregningerne/tilstandsændringerne 

er færdige, kan resultatet af maskin-instruktionerne findes i hukommelsen.[Budd95b, 

side9] 

Det imperative paradigme er velegnede til sm˚a programmer, men det kan blive vanskeligt at 

strukturere et større program, hvor der ofte vil opst˚a problemer med at holde styr p˚a eventuelle 

sideeffekters p˚avirkning p˚a globale data, ved procedurekald. 

De mest kendte programmeringssprog befinder sig enten i det imperative paradigme eller i 

b˚ade det imperative og det objektorienterede paradigme. For eksempel er Pascal og C begge 

imperative sprog hvorimod Java og C++ b˚ade er imperative og objektorienterede. 

3.1.2 Sætninger i det imperative paradigme 

I programmering betegner en sætning (eng.: statement) en sammenhængende og afsluttet række 

af definitioner og instruktioner.[itLex01] Der findes fire grundlæggende former for sætninger i 

det imperative paradigme. Her følger en definition p˚a dem. [wikipedia.org2] 

Tildeling 

Tildelingssætninger kan kort defineres som; tildeling af værdi til variable.[itLex01] Alts˚a tilstandsændring 

af variabler lagret i hukommelsen. 

Eksempel p˚a tildeling skrevet i det imperative sprog Fortran: 

v = 2 

Variablen p˚a venstre side af lighedstegnet f˚ar tildelt værdien p˚a højre side af lighedstegnet. 

Løkke 

En løkke tillader en række tildelingssætninger at blive udført adskillige gange. Løkker kan enten 

udføre de tildelingssætninger, de indeholder, et foruddefineret antal gange, eller de kan udføre 

dem gentagne gange, indtil en betingelse bliver sand. 

Eksempel p˚a While Løkke skrevet i det imperative sprog C: 

while(v < 12){ (løkker s˚a længe v er mindre end 12) 

v = v+1; (tildelingssætning inden i løkken) 

} (løkken slutter) 



Betinget forgrening 

Hvis nogle betingelser er gældende, tillades udførelsen af en blok af erklæringer. Hvis betingelserne 

ikke er gældende bliver blokken sprunget over, og programmet fortsætter sin sekventielle 

gennemkørsel efter den betingede forgrening. 

Eksempel p˚a betinget forgrening skrevet i det imperative sprog C: 

IF (v < 2){ (hvis variablen v er mindre end to) 

v = 2+1 (tildelingssætning i den betinget forgrening) 

} (betinget forgrening slutter) 

Ubetinget forgrening 

Ved ubetinget forgrening er det muligt at hoppe til et andet sted i programmet. Dette kan for 

eksempel gøres med sætningen goto eller ved kald af en procedure. 

Eksempel p˚a ubetinget forgrening, rettere goto sætningen, skrevet i det imperative sprog 

Fortran: 

1 v = 2+1 (tildelingssætning) 

2 GOTO 1 (her sendes program udførelsen tilbage til linie 1) 

Det skal bemærkes at eksemplet ovenfor udgør en uendelig løkke, da den ubetingede forgrening 

vil blive ved med at sende udførelsen af programmet tilbage til linie 1. 

3.1.3 Historie 

Det imperative paradigme er det ældste programmeringsparadigme. Det s˚a, kraftigt inspireret 

af maskin-instruktioner, sit lys i slutningen af 1950’erne, i sprogene Algol og Fortran, der 

henholdsvis blev udviklet i Europa og USA. Inden udviklingen af Fortran programmerede man 

primært i maskinkode og Assembler. Maskinkode er den binære kode som en cpu forst˚ar. Selve 

koden best˚ar af kombinationer og sammensætninger af binære tal. I assemblerkode anvendes der 

symboler til repræsentation af maskinkoden, alts˚a er assembler symbolsk maskinkode.[Bergin96, 

side26] 

3.1.4 Opsummering 

Paradigmet er kraftigt inspireret af maskinkode, hvilket er kendetegnet ved den sekventielle 

læsning af kommandoerne. Paradigmet er svært at holde p˚a et højt abstraktionsniveau, hvilket 

skyldes ligheden med maskin-instruktionerne. 

Det imperative paradigme kan være vanskeligt at programmere større programmer i, da det 

er vanskeligt at holde styr p˚a sideeffekterne. 



3.2 Det objektorienterede paradigme 

Det objektorienterede paradigme, ligger ikke s˚a langt fra den m˚ade vi i dagligdagen opfatter 

verden. N˚ar man for eksempel betragter en person, ser man personen som et objekt.[Weisfeld01] 

I artiklen af Ole Lehmann [Lehmann], findes der en definition af det objektorienteret paradigme. 

In object-oriented programming a program execution is regarded as a physical model, simulating 

the behavior of either a real or imaginary part of the world.[Lehmann] 

Den centrale del af denne definition af paradigmet er, ifølge Ole Lehmann, ordet fysisk. 

Man ser objekter som et digitaliseret materiale, der kan bruges til at lave fysiske modeller. 

Objekterne kan ses som fysisk materiale, for eksempel legoklodser, der bruges til at opbygge en 

legofigur.[Lehmann] 

3.2.1 Objekter 

Som beskrevet ovenfor er omdrejningspunktet i det objektorienteret paradigme, objekter. Et 

objekt kan defineres som: 

En enhed der rummer b˚ade data og adfærd.[Weisfeld01] 

Vi vil herefter forklare hvad der menes med data og adfærd. 

Data — attributter 

I den objektorienteret terminologi kaldes data for attributter. Disse attributter kan bedst forklares 

ved et eksempel hentet fra Matt Weisfeld. Eksemplet tager udgangspunkt i den fysiske 

verden, hvor et objekt repræsenterer en person. Attributterne indeholder information om personen, 

og kunne for eksempel være hudfarve, CPR-nummer og telefonnummer. 

Adfærd — metoder 

Figur 3.1: Attributter 

Et objekts adfærd, er det objektet kan gøre. Adfærderen bliver implementeret i objektet med 

metoder. Metoder bliver i andre paradigmer kaldt for procedurer, funktioner, subrutiner. For at 

bruge en metode skal den aktiveres, ved at sende en besked til den. I eksemplet med person– 

objektet, har man brug for en metode, der kan ændre og returnere de forskellige attributter. 

Derfor vil hvert attribut have korresponderende metoder. Eksempelvis vil telefonnummer attributten 

have metoderne setTelefonnummer og getTelefonnummer. P˚a denne m˚ade kan andre 

objekter hente og sende data fra person–objektet. 

3.2.2 Klasser 

En klasse er en skabelon til at oprette objekter. N˚ar man opretter et objekt siger man at instantiere 

et objekt. Hvis man for eksempel opretter tre person–objekter, laver man i virkeligheden 

3 instanser af person–klassen. Hver person–objekt indeholder sine egne data i attributterne og 

en kopi at metoderne. 



3.2.3 Nedarvning 

Figur 3.2: Metoder 

Figur 3.3: Klasser 

Et af paradigmets største fordele, er den store genavendelighed af kode. Med nedarvning udvider 

man muligheden for at genanvende kode, og samtidig f˚ar man muligheden for at definere relationer 

mellem klasser. En klasse kan arve egenskaber fra en mere generel klasse(superklasse). En superklasse 

kan videregive egenskaber til sine, mere specialiserede underliggende klasser(subklasser). 

[itLex01] 

Eksempelvis kunne man lave en Hunde–klasse og en Katte–klasse, som begge indeholder 

attributten øjenfarve og dens tilsvarede metoder. Med nedarvning er det muligt at abstrahere 

og lave en klasse der hedder Pattedyr–klassen. Denne klasse indeholder attributten øjenfarve 

og tilsvarende metoder. Det er nu muligt for vores Hunde–klasser og Katte–klasser, at arve 

øjenfarve–attributterne og dens metoder. P˚a denne m˚ade sparer man en masse kode og f˚ar 

skabt en relation mellem henholdsvis pattedyr/hunde–klassen og pattedyr/katten–klassen. Det 

er stadig muligt for Hunde og Katte–klasserne at angive nye attributter. I eksemplet forneden 

har Hunde–klassen en gøfrekvens som attribut og Katte–klassen en mijavefrekvens. Fælles for 

dem begge er at de har øjenfarve–attributten fra Pattedyr–klassen. 


Er blevet udkommenteret, da der skal skrives noget andet 

Ideerne til det objekt orienterede opstod i midt af 60’erne, og i 1967 kom det første egentlig 

objekt orienteret sprog; Simula men ogs˚a sproget, Ada er et godt stykke hen ad vejen, og 

man kan ogs˚a argumentere for, at LISP kan opføre sig objekt-orienteret. Men der har manglet 

forst˚aelse blandt programmørerne. 

C fik i starten af 80’erne en efterfølger p˚a designbordet, C with Classes, som i løbet af f˚a ˚ar 

skulle udvikle sig til en ANSI-standard kaldet C++ (”++”er optællingsoperatoren i C, s˚a C++ 

er 1 mere end C). I C++ har programmøren mulighed for at beskrive, hvordan hendes egne 

datatyper skal opføre sig i forskellige situationer - det er s˚a at sige datastrukturens eget ansvar 



Figur 3.4: Nedarvning 

at behandle sine data. Det har en stor indflydelse p˚a metoder for udvikling af software, fordi 

eventuelle fejl altid befinder sig i den del af koden, der er sprogligt direkte relateret til de data, 

som indeholder fejlen. C++ vinder kraftigt frem blandt systemprogrammører, men kritiseres 

for at være et konglomerat af lappeløsninger. 

I 1995 lancerer Sun sproget Java, der med sin platform uafhængighed virkelig hjalp det 

objekt orienterede paradigme p˚avej. 


I det objektorienteretparadigme organiser man alts˚a koden i objekter, der kan interagere med 

hinanden. Objekterne kan være opbygget at referencer til andre objekter og metoder. Nedarvning 

giver objekterne muligheden at arve egenskaber fra hinanden. Denne metode gør objekterne 

meget genanvenlig og den høje genanvenlighed er ogs˚a med til at gøre det objektorienteretparadigme 

meget attraktivt for større programmeringsprojekter, da disse kan drage stor nytte af 

dette. 


Kapitel 4 

De deklarative paradigmer 

Et deklarativt program erklærer hvad programmet skal udføre s˚a tydeligt, entydigt og præcist 

som muligt, men det lader op til compilerprogrammøren at holde styr p˚a s˚a mange memory, 

proces og andre ” how to“ afgørelser som muligt.[Reinfelds95] 

Med deklarativeparadigme bringer man programmøren p˚a et højere abstraktionsniveau. Man 

bevæger sig væk fra det mere maskinnære og tankegangen om, hvordan gør vi dette til det mere 

overordnede, hvad er det, vi gør. 

Der findes to programmeringsparadigmer inden for det deklarative paradigme, funktion og 

logik. 

4.1 Det funktionsorienterede paradigme 

Det funktionsorienterede paradigme tager udgangspunkt i en matematisk tankegang. Definition 

af funktioner (disse dog ikke begrænset til at arbejde med tal) er omdrejningspunktet i programmeringen 

inden for paradigmet. Paradigmet kan mere formelt set defineres ud fra følgende 

tre punkter, s˚asom [Placer91] har opsummeret det ud fra M.A. Jenkins, J.I Glasgow og C.D. 

McCrosky, ” Programming Styles ind Nial“, IEEE Software 3, 1, Jan. 1986, p. 46-55. 

• Funktioner har fast input/output-relation (Referential transparency) 

• Matematiske variable (uforanderlige variable) 

• Funktioner kan have andre funktioner som in- og output (højere-ordens funktioner) 

Dette bliver mere detaljeret gennemg˚aet umiddelbart herefter. 


Matematiske funktioner 

Da selve funktionsbegrebet er vigtigt for paradigmet, begynder vi med en definition af dette, 

hvorefter vi set dette i forhold til funktioner anvendt i programmering. 

Matematiske funktioner har en afvigende definition i forhold til de funktioner, der normalt 

anvendes i datalogisk programmering om disse s˚a kaldes ” funktioner“, ” procedure“, ” metoder“ 

eller ” subrutiner“. 

Funktion. En afbilledning af mængden A ind i mængden B er en funktion, hvis den til 

ethvert element i A entydigt tilordner et element i B [Karush78] 

Matematisk set er en funktion en black box, der entydigt afbilleder en definitionsmængde ind i 

en anden mængde, værdimængden. P˚a denne m˚ade bliver en funktion en input/output–relation 

gennem en black box, som indeholder selve implementationen af denne relation. 

18


Selve implementationen af funktionens relationer, formelen, kan være udformet p˚a vidt 

forskellige m˚ader. Et eksempel kan være input/output–relationen mellem et givet naturligt tal 

og summen af de underliggende naturlige tal i talrækkefølgen kan udtrykkes p˚a følgende to 

forskellige m˚ader: 

f(x) = 1 + 2 + 3 + 4 + ... + (n − 1) + n 

n(n + 1) 

g(x) = 

2 

Funktionerne f og g betegner samme funktoin, men har forskellige implementationer/formler. 

Referential transparency 

Udtrykket for en matematisk funktion med en given pargument–værdi (f.eks. g(3)) kan substitueres 

med dens returværdi uden, at der vil være forskel p˚a resultatet — man kalder dette, at 

matematiske funktioner har referential transparency [Paulson91]. Det vil med andre ord sige, 

at en matematisk funktion altid producerer samme output ved samme input, og der er en fast 

input/output–relation for en funktion — en funktion giver ikke forskellige output alt efter, 

hvorn˚ar den kaldes. Konsekvensen heraf er, at den matematiske funktion kun er inkonsekvent 1 

p˚avirkelig gennem et funktionskalds aktuelle parametre. Funktionen kan alts˚a kun modtage 

foranderligt input gennem parameteroverførsel. 

Et eksempel p˚a referential transparency i matematisk sammenhæng kunne være, n˚ar man 

vil foretage en trigonometrisk udregning; her forventer man, at cos(90) altid giver 0 ogs˚a selvom 

man for eksempel umiddelbart før har anvendt cos-funktionen med parameteren 17 — og s˚adan 

er det da ogs˚a for matematiske funktioner. Det vil sige, man kan forvente, at cosinus-funktionens 

formel ikke har ændret sig og altid giver det samme. 

Overholdelse af referential transparency i et program vil medføre, at man ikke skal bekymre 

sig om betydningen af, hvorn˚ar man kalder en funktion i programmet. Funktionen vil altid 

opføre sig p˚a samme m˚ade. Det vil sige, man skal ikke holde øje med et programs dynamik for 

at kunne forst˚a resultatet af et funktionskald. At man kalder en funktion p˚a linje 5 og p˚a line 20 

gør ingen forskel. Sagt p˚a en anden m˚ade, s˚a vil alle funktioner være p˚a samme m˚ade, som cosfunktionen 

i eksemplet herover. Dens formel vil aldrig ændre sig. S˚adan bør et paradigme-rent 

programmeringssprog under det funktionsorienterede paradigme ogs˚a opføre sig med hensyn til 

funktioner. 

En funktion i et traditionelt programmeringssprog har ikke nødvendigvis referential transparency 

— den vil ikke som en selvfølge have samme returværdi til samme aktuelle parameter 

ved forskellige funktionskald. Dette kan være grundet, at dens formel er p˚avirkelig af indirekte 

input, det vil sige input, der ikke kommer via en parameteroverførsel, og at dette indirekte input 

netop er inkonsekvent fra gang til gang, funktionen kaldes. Hvis et indirekte input, til en given 

funktion, er konsekvent fra gang til gang, denne funktion kaldes, vil dette ikke kunne medføre 

ændring af opførsel af funktionen. Den vil nemlig s˚aledes have samme formel og dermed have 

referential transparency. 

Sideeffekter er problematiske i forhold til referential transparency, da et funktionskald dermed 

kan medføre ændring af det omgivende miljø, og disse ændringer kan indg˚a som input i 

anden funktion. En matematisk funktion p˚avirker kun — som resultat af parameterinputtet — 

det omgivende miljø via den direkte returværdi og kan derfor ikke siges at have sideeffekter. 

En funktion i et traditionelt programmeringssprog kan derimod netop godt have sideeffekter, 

hvilket ikke er aktuelt i et paradigme–rent funktionsorienteret sprog. 

Det er ikke referential transparency i for eksempel det imperative sprog Pascal eller det objekt 

orienterede sprog Java 2 . Beregningen af henholdsvis en funktion og en metode i disse sprog kan 

p˚avirkes inkonsekvent af det omgivende miljø p˚a anden m˚ade end gennem inputparameteren 

1Den kan i teorien godt være p˚avirklig andet end via parameteroverførsel, blot p˚avirkning s˚a er konsekvent 

hver gang. 

2Selvom Java er objekt orienteret s˚a hører implemtationen af metoderne under det imperative paradigme. 



til funktionen/metoden. Der er ogs˚a sideeffekter, da funktionen/metoden selv kan p˚avirke det 

omgivende miljø tilbage p˚a anden m˚ade end gennem realværdien. 

Et konkret eksempel — om end en smule trivielt — p˚a sideeffekt og manglende overholdelse 

af referential transparency kan ses i Programkode 4.1. Problemet er netop her, at metoden 

f(int n) har anden indg˚aende forbindelse fra det omgivende miljø end gennem parameteren n, 

da den ogs˚a f˚ar indirete og inkonsekvent input fra variabelen flag. Det er indirekte, da det ikke 

overføres via parameteroverførsel, og det er inkonsekvent, da selvsamme metode ændrer p˚a det 

ved hvert metodekald. Dette betyder i at metoden giver forskellige realværdier ved samme input 

— noget der aldrig ville ske ved en matematisk funktion, der netop har referential transparency 

og ingen sideeffekter. 

1 class Eks{ 

2 private s t a t i c boolean f l a g = true ; // f o r a n d e r l i g data 

3 

4 public s t a t i c int f ( int n ) { 

5 int r e t u r ; 

6 i f ( f l a g ) // problem ( har i n d i r e k t e , f o r a n d e r l i g i n p u t ) 

7 r e t u r = n ; 

8 else 

9 r e t u r = 2∗n ; 

10 

11 f l a g = ! f l a g ; // problem ( s i d e e f f e k t ) 

12 return r e t u r ; 

13 } 

14 

15 public s t a t i c void main ( S t r i n g [ ] a r g s ) { 

16 System . out . p r i n t l n ( f ( 1 ) + f ( 2 ) ) ; // f (1) + f (2) = 1 + 4 = 5 

17 System . out . p r i n t l n ( f ( 2 ) + f ( 1 ) ) ; // f (2) + f (1) = 2 + 2 = 4 

18 } 

19 } 

Programkode 4.1: Sideeffekt og ikke–referential transparency i en Java–metode 

Manglende referential transparency og sideeffekter gøre det svært at overskue, hvad en given 

ikke–matematisk funktion giver som output, da man er nødt til at tage historikken af tidligere 

funktionskald og det omgivende program med i sine betragtninger. Dette er alts˚a i modsætning 

til den matematiske funktion og funktioner i et funktionsorienteret programmeringssprog, da 

disse ligger fast med hensyn til input/output–relationen underordnet sammenhængen, funktionskaldene 

kommer. 

Hovedproblemet her er, at det er tilladt for en ikke–matematisk funktion at ændre data i 

det omgivende miljø p˚a anden m˚ade end via returværdien af funktionen og at det p˚a samme tid 

er muligt for en s˚adan funktion at anvende denne data, eftersom denne data kan være blevet 

ændret mellem forskellige funktionskald. 

Uforanderlige variabler 

Det virker umiddelbart ud fra en traditionel datalogisk synsvinkel selvmodsigende, at variable 

skal være uforanderlige, men en variabel skal netop under det funktionsorienterede paradigme 

ikke anskues ud fra traditionel datalogisk synsvinkel, men ud fra en matematisk synsvinkel. 

Variabelbegrebet er matematisk set, at en variabel dækker over en vilk˚arlig konstant. Det 

vil mere præcist sige, at en variabel kan antage forskellige tilskrivninger fx af værdier, men 

n˚ar først en variabel er tilskrevet en værdi første gang, kan den ikke ændres. Der kan dermed 

ikke være flere tildelinger af værdier til en variabel, alts˚a findes der ikke destruktiv tildeling. 

Det ville i en matematisk sammenhæng være utænkeligt, at variablen x i det følgende antog to 

forskellige værditilskrivninger henholdsvis før og efter funktionskaldet g(8), mens det ikke ville 

være en umulighed i traditionel programmering. 

x 2 + g(8) + x 

I traditionel programmering kan en variabel x godt antage forskellige værditilskrivninger 

og er s˚aledes ikke bundet til den første værditilskrivning. Hvis ovenst˚aende var skrevet ud fra 



det imperative paradigme, s˚a ville funktionskaldet g(8) uden problemer via en sideeffekt kunne 

have ændret værditilskrivningen af x s˚aledes, at x før 3 funktionen g(8) evalueres er tilskrevet én 

værdi, men efter g(8) er evalueret er den tilskrevet en anden værdi med dertil ændret resultat 

af den samlede evaluering. 

Højere-ordens funkioner 

En højere-ordens funktion er en funktion, der som argument og/eller som returværdi kan have 

andre funktioner[Thompson99]. 

Et eksempel kunne være, funktionen, composit, der sætter to funktioner sammen til én. Den 

f˚ar to argumenter, som ogs˚a er funktioner, og giver som returværdi en ny samlet funktion. 

Dermed bliver composit en funktion af højere orden. Selve definitionen heraf som den ser ud i 

Haskell er vist i Programkode 4.2. 

1 −− d e f . en f u n k t i o n a f h ø j e r e orden 

2 composit : : ( a −> a ) −> (a −> a ) −> (a −> a ) −− d e f . a f f u n k t i o n e n s domæne og 

værdiomr˚ade 

3 composit p q = ( p . q ) −− d e f . a f f u n k t i o n e n s formel ( funktionssammensætning ) 

Programkode 4.2: Composit, definition af en højere-ordens funktion i Haskell 

I linje 2 st˚ar der (a −> a)−> (a −> a)−> (a −> a). Dette angiver input– og output–domæne, 

typer for funktionens argumenter og returværdi. N˚ar der st˚ar (a −> a) angiver dette, at der er 

tale om en funktion, hvor første a er argumenttypen, og sidst er returtypen; mere præcist bliver 

der i aktuelle tilfælde tale om en vilk˚arlig funktion med hensyn til domæne, da input- og output– 

domæne er vilk˚arligt i kraft af, at a her ikke betegner en konkret type, hvorfor funktionen ikke 

er bundet til for eksempel at have heltal som input og decimaltal som output. 

De to første gange (a −> a) optræder i composit-funktionens domnænedefinition er det som 

repræsentant for input-argumenter, hvilke der alts˚a er to af her, mens den sidste gang (a −> a) 

optræder, er det som repræsentant for returværdien. Som input f˚ar composit derfor netop to 

funktioner over et vilk˚arligt domæne angivet som (a −> a)−> (a −> a), og outputtet er netop 

ogs˚a en funktion, angivet som det sidste −> (a −> a). 

Linje 3 angiver selve formlen for composit, og den er her blot en sammensætning af de to 

inputfunktioner ved hjælp af operatoren ” .“. p og q er i denne sammenhæng argumenterne for 

de to inputfunktioner, composit-funktionen tager, og svarer til de to første (a −> a) i linje 2. 

Det bliver mere klart, hvis vi giver et eksempel p˚a anvendelse. Vi starter med at definere 

to funktioner, der kan anvendes som input-funktioner i højere-ordens funktionen composit, se 

Programkode 4.3. Linje 1–3 i programkoden definerer funktionen f. I linje 2 angives funktionens 

input- og outputdomæne. Den har ét inputargument som heltal, og som returværdi har den 

ligeledes heltal. Dernæst i linje 3 defineres selve formlen for funktionen. Præcist det samme 

gøres for funktionen g i linje 5–7. 

1 −− d e f . a f en alm . f u n k t i o n 

2 f : : Int −> Int −− d e f . a f f u n k t i o n e n s domæne og værdiomr˚ade 

3 f ( x ) = 8∗ x + 3 −− d e f . a f f u n k t i o n e n s formel 

4 

5 −− d e f . a f en alm . f u n k t i o n 

6 g : : Int −> Int −− d e f . a f f u n k t i o n e n s domæne og værdiomr˚ade 

7 g ( x ) = 10∗ x + 2 −− d e f . a f f u n k t i o n e n s formel 

Programkode 4.3: To tiltældige funktioner i Haskell 

Vi kan dernæst i et program kalde composit-funktionen med disse to funktioner som argument, 

f og g. Af dette kald kan composit’s returværdi anvendes som en ny funktion. Det vil sige (composit 

g f) er returværdien af et funktionskald af composit-funktionen med argumenterne g og f. Vi kan 

derfor kalde denne returværdi (alts˚a en funktion) med et argument, (4), og f˚a et resultat, se 

Programkode 4.4. 

3 Evaluering venstre mod højre 



1 −− a n v e n d e l s e a f composit−f u n k t i o n e n 

2 ( composit g f ) ( 4 ) −−g i v e r 352 

Funktionsparadigmets tankegang 

Programkode 4.4: Anvendelse af composit 

Paradigmet tager udgangspunkt i en matematisk tankegang. Der er referential transparency, 

uforanderlige variabel og højere-ordens funktioner. Funktionsbegrebet og variabelbegrebet ses 

ud fra det, de matematiske definitioner foreskriver. 

Paradigmet er ligeledes deklarativt. Det vil sige, at man ved programmering skal opstille 

statiske funktionsdefinitioner. Dette er i modsætning til at være dynamisk i programmeringen. 

Definitionerne har ikke dynamik indbygget i sig p˚a den m˚ade, at der i beregningen sker 

ændringer eller opdateringer. Beregninger sker i kraft af en definition og ikke i kraft af en 

beregningesmæssig metode. Under det funktionsorienterede paradigme gælder det netop ikke 

om at programmere med tilstandændringer for øje (som man gør imperativt med opdateringer 

af variable), men i stedet med definitioner og sammenhænge mellem definitioner for øje. Omdrejningspunktet 

er ikke gennemkørsel, men definitioner. Denne deklarative tankem˚ade finder 

man ogs˚a i logik–programmering, men hvor man i funktionsprogrammering lægger vægten p˚a 

funktioner, lægger man i logik–programmering vægten p˚a de logiske relationer. 

Mere konkret kommer den deklarative tankegang til udtryk ved, at man ikke opererer med 

foranderlige variable. Der er kun én tilstand af en variabel, da denne kun kan antage netop én 

værdi. Der er derfor ingen tildelingssætninger (assigments), da man ikke kan ændre en variabels 

værdi (man kan kun lave en ny variabel). Man har heller ikke eksplicitte løkker, da tankegangen 

i funktionsprogrammering netop ikke g˚ar p˚a at n˚a frem til en løsning ved hjælp af hvordan og 

ændringer af tilstande i programmet. Implicit kan en løkkestruktur dog skrives ved at definere 

rekursive funktioner. Da der ikke som s˚adan er tilstandsændringer, er der derfor heller ikke 

sideeffekter. Udover dette har man ogs˚a referential transparency. 

Eksempel p˚a tankegangen Til hjælp af forst˚aelsen af tankegangen, opstilles her et eksempel 

p˚a den funktionsorienterede tankegang set som modstykke til den traditionelle. 

Hvis man i et imperativt sprog som C eller et objektorienteret sprog som Java fik stillet 

den opgave at skrive en metode til at beregne potenser, hvordan ville man s˚a udforme denne 

løsning? Vi ser naturligvis bort fra, at potens–udregning allerede er muligt i sproget Dette 

kan læseren jo lige stoppe op og tænke lidt over inden den videre læsning her. Jo, man ville 

sandsynligvis gøre sig nogle tanker om, hvad x n er for noget. Da man netop underliggende her 

har imperative tanker i baghovedet, ville man sandsynligvis n˚a frem til, at x n er x ganget med 

sig selv n gange. Da denne tankegang netop inspirerer til en løsning, der let kan laves i C eller 

Java — det vil sige en tilstandsændrende løsning. Løsningen bliver derved hurtigt inden for det 

imperative paradigme med udgangspunkt i en løkke, der opdaterer en variabel til det endelige 

resultat er n˚aet, se Programkode 4.5. 

1 // Beregner potens , xˆn 

2 public s t a t i c int power ( int x , int n ) { 

3 i f ( n == 0) return 1 ; 

4 

5 int r e s u l t a t = x ; 

6 for ( int i = 1 ; i < n ; i ++) 

7 r e s u l t a t = r e s u l t a t ∗ x ; 

8 

9 return r e s u l t a t ; 

10 } 

Programkode 4.5: Dynamisk og tilstandsændrende i Java (metode imperativ) 

Ved en løsning under funktionsparadigmet ville man nok ogs˚a gøre sig nogle tanker om, hvad 

x n er for noget, men da man opererer inden for en helt anden verden — deklarativ og uden 

løkker — s˚a er det overvejende sandsynligt, at man i stedet ville n˚a frem til en erklæring, en 



definition, p˚a x n i stedet for en beregningsmæssig metode; groft sagt kommer man frem til hvad 

i stedet for hvordan. Man ville nemlig nok n˚a frem til, at x n er x · x n−1 . I dette er der ingen 

programmering til ændringer af tilstande og opdatering af variable, men i stedet erklæring af 

en definition, se Programkode 4.6. 

1 (∗ Beregner potens , xˆn ∗) 

2 fun power ( x , 0 ) = 1 

3 | power ( x , n ) = x ∗ power ( x , n−1) ; 


Programkode 4.6: Statisk og deklarativ i SML (funktionsorienteret) 

Et af m˚alene med udviklingen af programmeringssprogvar at komme op p˚a et højere abstraktionsniveau 

i forhold til ren maskinkode og assembler. Programmering i maskinkode og assembler 

er meget nær det imperative paradigme, s˚a man kan se det imparative paradigme i 

forlængelse heraf. Det funktionsorienterede paradigme derimod prøver at bevæge sig op p˚a et 

endnu højere abstraktionsniveau i forhold hertil og dermed fjerne sig fra det maskinelle. 

Lisp fra sidst af 1950’erne var det første programmeringssprog[wikipedia.org1], der indeholdte 

funktionsorienterede elementer. Det var ikke fuldstændigt funktionsorienteret, da det 

ogs˚a havde imperative strukuterer, som for eksempel sideeffekter. Det blev udviklet af en gruppe 

under M.I.T., der arbejdede med kunstig intelligens. Dets anvendelsesomr˚ade er mere præcist 

manipulation af forskellige symbolske udtryk[Sammet69]. 

Sidenhen er fulgt andre sprog som ML og endnu senere det mere paradigme–rene 4 Haskell. 


Paradigmet er matematisk i sin grundstuktur. Dette er med til at gøre programmer skrevet 

under dette paradigme klarere at forst˚a, da man ikke har ting som for eksempel sideeffekter 

og foranderlige variable samt man har referential transparency. Som konsekvens heraf er dette 

ogs˚a med til at gøre formel bevisførelse for programmerne lettere at udføre. 

P˚a samme tid er paradigmet ogs˚a deklarativt, hvilket medfører et højere abstraktionsniveau 

for programmøren. Der skal ikke bruges tid p˚a trivielle ting som at finde ud af, hvordan man 

gør noget, men hvad det er, der rent faktisk skal gøres. 

4 Mere ren i overholdelsen af paradigmets definerende elementer med de ting, der understøttes, samt s˚a vidt 

muligt udeladelse af andre paradigmalle elementer 



4.2 Det logikorienterede paradigme 

4.2.1 Generelt 

Normalt betegner ” logik“ læren om rette slutning ud fra bestemte forudsætninger [Høholdt00]. 

I logikken ser man ikke p˚a det egentlige indhold af forskellige udsagn, men hvorledes den rette 

sammenhæng mellem forudstæning og slutning opn˚as. Dermed bliver de reele ting om verden, 

der udtrykkes i en given situation, ikke relevante at se p˚a og logikken bliver derved uden 

tilknytning til verden som s˚adan. Dette kan i et almindeligt sprog sammenlignes med kun at se 

p˚a grammatiske regler i en sætning og ikke p˚a den faktiske og konkrete betydning af sætningen. 

Matematisk logik er denne form for logisk tænkning i en konkret formaliset udformning med 

regler og metoder til at bestemme den logiske korrekthed[Høholdt00]. 

I kapitlet kigger vi p˚a logikken inden for matematisk logik, der hedder udsagnslogik og 

prædikatlogik. Til sidst gives eksempler p˚a hvordan logik bruges i programmering. 


Udsagnslogik 

Udsagnslogik 5 er opbygget af udsagn og logiske operatorer[itLex01]. Et udsagn er i denne sammenhæng 

noget, der kan være enten sandt eller falsk[Høholdt00] og formaliseres ved et stort 

bogstav; mens operatorerne i denne sammenhæng best˚ar af en række symboler, der er vist i 

nedenst˚aende tabel. 

Navn: Symbol: 

Konjunktion(OG) ∧ 

Disjunktion(ELLER) ∨ 

Negation(IKKE) ¬ 

Implikation ⇒ 

Biimplikation ⇔ 

Et eksempel p˚a et udsagn kan være der er fuldm˚ane“ (P) eller det blæser“ (Q). Der er 

” ” 

knyttet en sandhedsværdi til disse og betragtes som enten værende sande ellers falske. Hvis der 

er fuldm˚ane, er udsagnet sandt og hvis ikke, er det falsk. Disse udsagn for eksempel samles til 

” der er fuldm˚ane og det blæser ikke“. Dette giver et nyt udsagn, der samlet set igen enten kan 

være sandt eller falsk. I vores eksempel her er det samlet set kun sandt i det tilfælde, at begge 

dele er opfyldt. Det vil sige, at det faktisk er fuldm˚ane“ og det faktisk ikke blæser“. Dette kan 

” ” 

formaliseres som: P ∧ ¬Q. 

Vi kan udvide vores eksempel. Vi kunne bruge den samlede sandhedsværdi for, om der er 

fuldm˚ane og det ikke blæser som betinget konsekvens. Vi kan skrive hvis der er fuldm˚ane og 

” 

det ikke blæser s˚a er det ikke uhyggeligt“. I formaliseret udgave bliver det til, hvis udsagnet 

” det er uhyggeligt symboliseres med S: P ∧ ¬Q ⇒ ¬S Den faktiske tilknytning til verden af P 

” 

og Q er ikke relevant. 

At P og Q henholdsvis dækkker over der er fuldm˚ane“ og det blæser“ har ingen betydning 

” ” 

for logikken. Lige meget hvad P og Q antager af forbindelse til den virkelige verden, s˚a vil det i 

logik betyde, at for det samlede udsagn skal være ska b˚ade P & Q være sande. Dette er netop 

helt uafhængigt af den faktisk binding til verden for de to udsagn P og Q. 

Prædikatlogik 

Prædikat logik er en udvidelse af udsagnslogik med prædikatsymboler, individvariable og kvantorer[itLex01] 

Den formalisme, der blev beskrevet i det tidligere afsnit om udsagnslogik, viser sig utilstrækkelig 

til at beskrive og undersøge alle de logiske slutninger vi kan være interesserede i. Lad os 

betragte et nyt eksempel[Høholdt00]: 

5 Kaldes ogs˚a propositions logik 



Eksempel 1. 

Hvis x og y er reele tal og xy = 0 

s˚a gælder, at x = 0 eller y = 0. 

Ovenst˚aende matematiske sætning indeholder variabler (x,y) og kan ikke udtrykkes vha. 

udsagnslogik, da xy = 0, x = 0 og y = 0 ikke er konkrete udsagn. Deres sandhedsværdi afhænger 

af hvilke reele tal x og y refererer til. Ved at indføre begrebet prædikat kan vi behandle udtryk 

og slutninger af ovenst˚aende karakter. 

Et prædikat kan i denne forbindelse være udtrykket x = 0. ” x“ er en variabel og kan antage 

en værdi fra en mængde af reele tal. Denne mængde kalder vi for universet, og der understreges 

at der til ethvert prædikat tilhører et univers. Hvis man erstatter x med et bestemt element fra 

universet, s˚a f˚as et udsagn, der enten er sandt eller falsk. Ved at betegne udtrykket x = 0 med 

N(x) og gøre brug af de tidligere introducerede operatorer, kan vi formulere en del af sætningen 

i Eksempel 1, som: 

N(xy) ⇒ [N(x) ∨ N(y)]. 

Ovenst˚aende er et sammensat prædikat. Ved at bruge andre operatorer sammen med prædikater, 

kan man p˚a tilsvarende m˚ade opn˚a andre sammensatte udtryk. 

M˚aden at anvende prædikater kan anvendes i andre sammenhænge end vist i Eksempel 1. 

Lad os betragte et nyt eksempel(Eksempel 2): x er en hund. Her antager variablen x en værdi 

fra et univers af hunde. Hvis vi lader A(x) betyde ” x er et hund“ og lade B(x) betyde ” x har 

fire ben“, s˚a kan vi opskrive udtrykket 

A(x) → B(x) 

Udtrykket betyder: Hvis x er en hund, s˚a har x fire ben. Vi kan lade variablen ” x“ referere 

til navnet ” Fido“ og lade p betegne dette navn. A(p) vil derfor betyde, at Fido er en hund og 

B(p) at Fido har fire ben. For at gøre Eksempel 2 mere abstrakt kan vi skrive ” Alle hunde har 

fire ben“. Vi mangler blot at indføre et udtryk for ” Alle“. Hvis vi lader K(x) være et prædikat 

og anvende det logiske symbol for alkvatoren, kan vi skrive: ∀ x K(x), som læses, for ethvert x 

K(x), er udsagnet sandt, n˚ar udsagnet K(a) er sandt, uanset hvilket element a fra det betragtede 

univers der er tale om. Et komplet sandt udsagn for Eksempel 2 kan nu formaliseres som: 

1. ∀ x (A(x) → B(x)) (Alle hunde har 4 ben) 

2. A(p) (Fido er en hund) 

3. B(p) (Fido har fire ben). 

Efter at have introduceret alkvatoren kan vi ligeledes opskrive et komplet udtryk for Ekempel 

1. 

∀ x ∀ y (N(xy) → (N(x) ∨ N(y))). 

Der findes flere prædikatlogiske relationer(operatorer), som man kan anvende til at konstruere 

mere komplekse og omfattende prædikatlogiske udsagn. I Eksempel 1 og 2 er der vist hvordan 

nogle af de mere grundlæggende relationer anvendes. 

I næste afsnit skal vi se p˚a de metoder man anvender til at udtrykke logik i programmering. 

4.2.3 Logik i programmering 

Ovenfor introducerede vi tankegangen bag matematisk logik og hvordan man vha. bl.a symboler, 

der repræsenterer operatorer, kan formalisere konkrete prædikatlogiske udsagn ud fra en række 

sætninger. Tankegangen i logikprogrammering stemmer overens med den vi har introduceret 



i de foreg˚aende afsnit. I logik paradigmet kan man betragte databehandling som en deduktiv 

proces, som gør brug af fakta, regler og forespørgsler[Budd95c]. Resultatet af forespørgsler opn˚as 

p˚a baggrund af fakta og regler for inferens. I afslutningen af dette afsnit ser vi p˚a hvordan man 

udtrykker fakta og forespørgsler i logikprogrammeringssproget Prolog. 

Klausuler 

I logikprogrammering anvendes en form til at udtrykke logiske sætninger, som kaldes klausulform. 

Generelt kan en klausul betragtes som en sætning af formen ” hvis A s˚a B“, som opskrives 

B1,...Bn ← A1,...An 

, hvor B1,...Bn og A1,...An kaldes atomer. Atomerne A1,...An er betingelser og atomerne 

B1,...Bn er konklusioner i klausulen[Kowalski]. Et atom er et udtryk af formen P(t1, ... , tn 

, hvor P er prædikatsymbolet og t1, ... , tn kaldes termer. Et atom skal fortolkes som, at relationen 

P dækker over individerne t1, ... , tn. Et term kan enten være en variabel eller en 

konstant. 

Lad os kigge p˚a et eksempel, hvor vi anvender en klausul. Ønsker vi for eksempel at udtrykke 

et forhold imellem en far og en søn, f.eks. sætningen Peter er fader til Jens, hvor Peter referer til 

variabel x og Jens til y, vil det udtrykkes som Fader(peter,jens). Vi kan ogs˚a nøjes med kun at 

definere en person og lade den anden variabel st˚a: Fader(Peter,y). Fader“ er et prædikat symbol, 

” 

som repræsenterer et forhold mellem de to personer. Det andet klausul best˚ar af konstanterne 

” peter“ og jens“, som er de to defineret personer. 

” 

Et andet eksempel hvor vi gøre brug af operatorer og hvor en betingelse skal være opfyldt 

kunne være: 

Hankøn(x) ← Fader(x,y) 

Ovenst˚aende klausul skal forst˚as som: x er hankøn hvis x er fader til y. I dette eksempel gør vi 

brug af den logiske operator implikation. Hankøn(x) er konklusionen i klausulen hvis betingelsen 

Fader(x,y) bliver opfyldt. 

Ved at anvende konnektoren og kan vi udtrykke mere komplekse klausuler, som best˚ar af 

flere forhold. Lad os betragte følgende eksemplet: 

Bedstefader(x,y) ← Forældre(x,z), Forældre(z,y) 

, hvor kommaet i klausulen betyder og. For alle x,y og z variabler gælder der: x er bedstefader 

til y hvis x er forældre af z og z er forældre til y. 

4.2.4 Eksempler i Prolog 

Fakta 

Efter gennemgangen af klausuler vil vi vise en række konkrete eksempler i programmeringssproget 

Prolog. Da logik i Prolog bruges som en konkret værktøj til problemløsning er der en 

række principper, som undervejs vil blive introduceret(bl.a. regler og forespørgsler). Den simpleste 

form for klausul-erklæring i Prolog kaldes for et faktum. Hvis vi anvender Eksempel A fra 

tidligere kan et faktum udtrykkes s˚aledes: Fader(peter,jens). 

Et program i logik best˚ar af en række fakta. I Eksempel 3. er vist en lille familiedatabase, 

som best˚ar af forbindelser mellem forskellige personer. 



Eksempel 3 

Fader(peter,jens). Hankøn(peter). 

Fader(abraham,anders). Hankøn(anders). 

Moder(line,isabel). Hunkøn(line). 

Forespørgsler 

Den anden form for erklæring i logikprogrammeringer en forespørgsel, som er en m˚ade at 

f˚a information udfra et logik program. En forespørgsel undersøger om der er en forbindelse 

imellem individ objekter. Tager vi udgangspunkt i familiedatabasen, vil et udtryk som Fader(abraham,anders)? 

undersøge om Fader-forholdet gælder for personerne abraham og anders. 

Da dette faktum er angivet i databasen er denne forespørgsel umiddelbart sand, og Prolog vil returnerer 

svaret ”´ja“. Spørgsm˚altegnet efter udtrykket angiver at der er tale om en forespørgsel. 

Hvis vi ligeledes spørgerFader(line,anders)? vil Prolog returnerer svaret ”´nej“, da denne forespørgsel 

ikke stemmer overens med de fakta angivet i familie databasen, og vil umiddelbart 

være falsk. 

Logiske variabler 

I de tidligere afsnit gennemgik vi hvordan variabler anvendes i matematisk logik. I logikprogrammeringkan 

man definere et logisk variabel som et uspecifieret individ[Sterling2000] Logiske 

variabler kan bl.a. bruges i forbindelse med forespørgsler. Hvis vi f.eks. vil vide hvem abraham 

er fader til, kan vi spørge Fader(abraham, X)?, som vil returnere svaret X=anders. At anvende 

logiske variabler i forespørgsler i denne sammenhæng, er en effektiv m˚ade finde en relation 

mellem individer, da man ikke undg˚ar at skulle undersøge samtlige Fader forhold i databasen. 

Universelle fakta 

Logiske variabler kan ogs˚a anvendes i fakta. Lad os antage at b˚ade peter, abraham og line elsker 

appelsiner. I stedet for at angive dette faktum for alle individer, som Elsker(peter,appelsiner), 

Elsker(abraham,appelsiner). og Elsker(line,appelsiner)., kan man opsummere alle disse fakta 

vha. logiske variabler og skrive: Elsker(x,appelsiner). Den logiske variabel ”´x“ dækker alts˚a 

over alle personer. 

Regler 

Den sidste og vigtigste bestanddel i logikprogrammeringer en regel. En regel kan opskrives p˚a 

formen A ← B1, B2, ...,Bn, hvor n ≥ 0. Det er værd at bemærke, at et fakta er en regel n˚ar 

n=0. Vi kan udbygge vores database med en række regler. Hvis vi f.eks. ønsker at regel der 

udtrykker et ” søn“ og et ” datter“ forhold kan vi skrive: 

Søn(X,Y) ← Fader(Y,X), Hankøn(X). 

Datter(X,Y) ← Fader(Y,X), Hunkøn(X). 

Pilen til ventre er taget fra matematisk logik og er symbolet for implikation. Søn reglen skal 

læses som: ” X er søn af Y, hvis Y er fader af X og X er hankøn“. Prædikatet ” Søn“ er blevet defineret 

ud fra prædikaterne ” Fader“ og ” Hankøn“. Regler er ofte anvendt i logik programmer, da 

man kan definere hvilke betingelser, der skal være gældende i forbindelse med f.eks. en familie. 


Udviklingen af logikprogrammeringbegyndte i starten af 1970’erne, og blev introduceret af Robert 

Kowalski(1974) og Alain Colmerauer et al(1973). Deres arbejde bestod i en videreudvikling 

af automatisk bevisførelse(inden for kunstig intelligens), som var introduceret af J. A. 

Robinson[HofPL]. 



P˚a dette tidspunkt ekisterede programmeringssprog inden for det imparative paradigme, 

s˚asom Fortran og Algol. I disse sprog havde programmøren blandt andet mulighed for at anvende 

symbolske navne til lagrings omr˚ader og skrive algebraiske udtryk. Disse sprog gjorde det lettere 

for programmører at programmere, da oversætteren gjorde en stor del af struktur-arbejdet i 

koden. 

P˚a trods af disse fordele, bestod et program skrevet i det imperative paradigme stadig af 

kommandoer(som virker ved at ændre værdier i hukommelsesomr˚ader). Kowalski og Colmerauer’s 

ide var at bruge logik som et programmeringssprog. I stedet for at et program best˚ar af 

kommandoer som skal udføres, skal det indeholde definitioner og erklæringer om det problem 

der skal løses. Denne tankegang kaldtes for deklarativ programmering. Det betyder, at man 

for eksempel udtrykker en sætning i et logiksprog, som er enten sand eller falsk. Deklarative 

programmer indeholder ingen explicit instruktioner, som computeren skal udføre. Derimod er 

computerens opgave at manipulere information og n˚a frem til en løsning p˚a et givet problem. 

Det var denne tankegang der indledte til udviklingen af et, af de i dag mest udbredte logik 

programmeringsprog, Prolog. 


En gennemgang af den matematiske logik giver et indblik i den grundlæggende tankegang i logik 

paradigmet. Eksemplerne vist under afsnittende om udsagns– og prædikatlogik skulle illustrere 

hvordan man vha. symboler for operatorer kan formalisere en sætning som et matematisk logisk 

udtryk. I logikprogrammering anvender man samme tankegang, og vi har vist hvordan man 

bruger klausul formen til at udtrykke sætninger. I et programmeringssprog som Prolog gør man 

brug af logiske variabler, regler, fakta og forespørgsler som anvendes i forbindelse med løsningen 

af et givent problem. I afsnittet s˚a vi hvordan man brugte disse typer af erklæringer i en familie 

database. 


Kapitel 5 

Multiparadigmet 

Multiparadigmet kombinerer tidligere paradigmers principper i et samlet overordnet paradigme. 

I artikel [Budd95c] refereres Brent Hailpern som har givet følgende definition. 

”A multiparadigm programming language is a system that incorporates two or more of the 

conventional programming” 

Et multiparadigmentionelt programmeringssprog, skal alts˚a have to eller flere konventionelle 

programmeringsparadigmer inkorporeret i sig, før det kan kaldes et multiparadigmentionelt 

sprog. Som s˚adan er der ikke tale om et konventionelt paradigme, da det ikke tilføjer nye 

programmeringssyn, men kombinerer tidligere principper i et enkelt programmeringssprog. Det 

kan derfor diskuteres, om hvorvidt man overhovedet kan tale om et s˚akaldt multiparadigme, 

men om der ikke kun er tale om multiparadigmentionelle programmeringssprog, der kombinerer 

allerede eksisterende tankegange. 

Tendensen i nye programmeringssprog g˚ar ogs˚a p˚a kombinationen af flere paradigmer. Eksempelvis 

er C++ blevet udr˚abt som et multiparadigmentionelt programmeringssprog i [Budd95c], 

som refererer Stanley B. Lippman. C++ Primer. Addison-Wesley, Reading, Massachusetts, 

second edition,1991. Om hvorvidt man vælger at betegne et kombinationssprog for et hybridsprog, 

istedet for et multiparadigmentionelt sprog er i og for sig underordnet – der lader ikke 

til at være fastsl˚aet en standard betegnelse. 

Et programmeringssprog, der ofte nævnes i sammenhæng med multiparadigmet, er Leda, som 

kombinerer imperativ-, logik-, funktions- og objekt-orienteret programmering i et sprog med én 

syntaks[Budd95b]. Leda startede p˚a forsøgsbasis, hvor man ønskede at undersøge mulige fordele 

og ulemper ved løsninger indenfor for flere paradigmer, i følge forfatteren bag Leda — Timothy 

A. Budd — videreudvikles det løbende. Den ˚abenlyse fordel ved at benytte et multiparadigmentionelt 

sprog er, at man kan tilg˚a samtlige inkorporerede paradigmer med samme syntaks. 

Dette vil vi behandle senere ved præsentationen af de paradigmatiske argumenter. 

29

Kapitel 6 

Præsentation af fordele og 

ulemper ved paradigmerne 

I dette kapitel vil vi præsentere fordele og ulemper inden for de fire programmeringsparadigmer. 

Alle argumenter er taget p˚a baggrund af en række artikler der beskriver, hvilke paradigme(er) 

den studerende skal introduceres for, i et indledende programmeringskursus. Fordelene og ulemperne 

skal være grundlaget for, at vi kan vurdere hvilket paradigme vi mener der bør undervises 

i, i et indledende programmeringskursus. Disse skal lede op til en diskussion af overvejelser omkring 

denne problematik. 

Det kan forekomme, at der vil være nogle fordele og ulemper der vil modsige hinanden, 

hvilket skyldes at artiklerne har forskellige meninger inden for dette emne. Vi har valgt at 

medtage begge synspunkter, da vi ikke skal vurdere argumenterne i dette afsnit. 

6.1 Imperative 

6.1.1 Fordele 

• Der findes meget kvalificeret undervisningsmateriale til anvendelse ved et indledende programmerings 

kursus, hvorimod andre paradigmer godt kan halte lidt p˚a dette punkt. Det 

er dog kun et spørgsm˚al om hvor længe det p˚agældende paradigme har eksisteret og været 

anvendt til undervisning.[Brilliant96][Pedroni03] 

• S. Brilliant og T. Wiseman[Brilliant96] mener, at der ikke er andre paradigmer p˚a samme 

høje pædagogiske niveau som det imperative paradigme, hvilket giver sig til kende ved at 

de fleste studerende, finder paradigmet nemt at forst˚a/indlære.[Brilliant96] 

• Det imperative paradigme er ofte mere naturligt for de studerende end andre paradigmer. 

[Neubauer02] 

• De fleste paradigmer anvender sammen kørselorienteret tankegang som det imperative 

paradigme.[Pedroni03] Især i det objektorienteret paradigme, der ofte kombineres med 

imperative, se for eksempel p˚a Java og C++. Derfor bør der altid undervises i det imperative 

paradigme, og de studerende skal have fuld kendskab til det, inden der for eksempel 

undervises i det objektorienterede paradigme.[Neubauer02] 

6.1.2 Ulemper 

• Det imperative paradigme er et af de oftest anvendte paradigmer. 

Dette skyldes, at paradigmet er kan bruges til programmering af maskinelle apparater, 

s˚asom hvidevarer med elektroniske styresystemer. Det er et faktum at det imperative 

paradigme er udbredt p˚a arbejdsmarkedet, dog mener ACM og IEEE-CS [Curricula01] 

30


at man ikke bør undervise i det p˚a universiteterne, da det ikke er universiteternes job at 

lefle for softwareindustrien og fremstille dataloger der kan programmere i det pt. hyppigst 

anvendte programmeringsparadigme. De skal derimod være fremtidssikret for eksempel 

med henblik p˚a forskning. 

• Undervises de studerende i de hyppigst anvendte paradigmer, for eksempel imperative, 

vil de f˚a en negativ indstilling, til at lære andre paradigmer.[Brilliant96] 

• Imperativ er det paradigme de studerende oftest har kendskab til i forvejen, derfor bør 

man ikke undervises i det, som førstegangsundervisning, da de studerende sandsynligvis 

ikke har samme forudsætninger. [Curricula01] 

• N˚ar der er opn˚aet en forst˚aelse for det imperative paradigme, er det vanskeligt at ændre 

tankegangen til at tænke i for eksempel objekter.[Brilliant96][Neubauer02] Det har vist 

sig at paradigme skiftet fra imperativ til objektorienteret er vanskelig for de studerende, 

hvorimod skiftet fra objektorienteret til imperativ er betydeligt nemmere. [Pedroni03] 

• Det tvinger de studerende til at lægge fokus p˚a syntakserne og karakteristikaene ved det 

p˚agældende sprog der nu anvendes. Derved fjernes hovedvægten fra algoritmerne, der er 

det fundamentale ved det imperative paradigme. [Pedroni03] Et andet minus er at det er 

vanskeligt at genbruge kode skrevet i det imperative paradigme. [Decker93] 

• Det imperative paradigme kræver operationel-, implementering- og sekventiel-paradigme 

specifik tankegang, i artiklen eksemplificeret i C. Dette kan f˚a eleverne til at glemme 

simpel og elegant kode.[Brilliant96] 

• Det kan være vanskeligt at holde styr p˚a sideeffekter n˚ar man skriver sætninger i imperative 

paradigme, hvilket vanskeliggør indlæringen for de studerende. [Brilliant96] 

6.2 Objektorienteret 

6.2.1 Fordele 

• I stigende grad anvendes det objektorienterede paradigme b˚ade i akademisk sammenhæng 

og i software-industrien. Dette er i ACM og IEEE-CS’s Computing Curricula [Curricula01] 

argumentet for at starte med det objektorienteredeparadigme, da man s˚a tidligt som muligt 

bør have kendskab til paradigmet. P˚a samme tid er dette paradigme ogs˚a komplekst, 

s˚a man i det indledende kursus især skal overveje undervisningsforløbet for at begrænse 

denne kompleksitet for de studerende. 

• Objekt-begrebet giver en mere korrekt beskrivelse af, hvordan mennesket løser opgaver, 

siger R. Decker [Decker93], hvorfor objekter i programmering ogs˚a tillader os at løse en 

opgave mere ud fra menneskelig tænkning i modsætning til, at vi som mennesker i vores 

problemløsning skal tænke som computeren. Som konsekvens heraf er det objektorienterede 

paradigme lettere at arbejde med i de indledende programmeringkurser. Dette er vel 

nok ogs˚a den generelle holdning, at objekter — alts˚a et samlet hele i form netop af et 

objekt — er en mere naturlig afbilledning af den faktiske verden. 

• Den struktur- og design-mæssige karakter ved det objektorienterede paradigme er en fordel 

i følge J. Rosenberg m.fl. [Rosenberg95]. Paradigmet tilskønner programmering med 

designovervejelser for øje og kodegenbrug, hvilket bliver introduceret tidligt i undervisnignsforløbet. 

• Paradigmeskift fra det objektorienterede paradigme til andre paradigmer er lettere, mens 

den modsatte vej synes mere vanskelig. S˚adan har det i følge J. Rosenberg m.fl. [Rosenberg95] 

vist sig at være, hvis man er kommet fra det imperative til det objektorientede paradigme. 



• Man bør starte undervisningen inden for det objektorienterede paradigme, da dette paradigme 

medfører et højt abstraktionsniveau allerede fra starten af, og giver s˚aledes tidligt 

øvelse i abstraktion, da dette i følge Peter Sprague og Celia Schahczenski [Sprague02] 

netop skal bruges gennem hele de studerendes videre studie. 

6.2.2 Ulemper 

• Objekt-begrebet er nødvendigvis ikke det mest naturlige i alle programmeringssituationer 

i følge J. Neubauer m.fl. [Neubauer02]. De siger, at selvom verden godt nok er opbygget 

af objekter, s˚a har disse ikke metoder til at gøre noget ved sig selv, da der i stedet i 

den virkelige verden ofte bliver gjort noget ved objekterne. Det vil sige, at i den rigtige 

verden udføres der en process p˚a objekter, mens objekter i objektprogrammering selv 

har ansvaret for det, der kan/skal gøres — de udfører alts˚a processen p˚a sig selv. Som 

eksempel herp˚a nævner de blandt andet, at en side i en fysisk bog (et objekt) ikke selv har 

en metode at vende sig, den bliver vendt. Det er alts˚a en process udefra, der udføres p˚a 

objektet og objektet har intet begreb om de ting, der kan gøres ved det. Processbegrebet 

stemmer mere overens med den imperative tankegang, hvor man netop ogs˚a har processen 

central, og det er et argument mod det objektorienterede paradigme som et letforst˚aligt 

første paradigme. 

• De studerende skal introduceres til syntaks uden reelt at forst˚a deres betydning, hvilket 

P. J. Burton og R. E. Bruhn [Bruhn] beskriver som et problem. De mener, at før man 

overhovedet begynder p˚a undervisning i det objektorienterede paradigme, skal man først 

have styr p˚a det imperative. Det vil sige processen først, og s˚a det mere strukturmæssige 

fra det objektorienterede paradigme. P˚a denne m˚ade ser de det objektorienterede paradigme 

som en naturlig udvidelse af det mere procesorienterde imperative paradigme. At 

se det objektorienterede paradigme s˚aledes er dog helt forkert, st˚ar der i [Pedroni03], da 

det netop er en helt anden tankegang det objektorienterede paradigme medfører, og ikke 

blot en udvidelse. 

6.3 Deklarativ 

Vi har valgt at samle fordele og ulemper for det funktionsorienterede og logikorienterede paradigme 

under ét afsnit og ser samlet p˚a dem. Dette har vi gjort, da argumenterne, vi har fundet, 

har været gældende for begge paradigmer og ikke som s˚adan for de enkelte paradigmer. 

Dette medfører s˚aledes, at vi i konklusionen ikke er i stand til at se p˚a de to deklarative 

paradigmer adskilt, men derimod som et samlet hele. 

6.3.1 Fordele 

• Det deklarative paradigme har i høj grad simpel syntaks og semantik [Reinfelds95], og af 

denne grund er det let at lave et hurtigt program med en masse funktionalitet. 

• Den deklarative tankegang er mindre kompleks, da den fjerner tidsdimensionen i et program.[Rebelsky01] 

• Det kan skabe problemer at mange studerende, der vil læse datalogi, i forvejen har kendskab 

til programmering. Oftest er det de har kendskab til et imperativt eller et objektorienteret 

paradigme, og derfor vil det være mere hensigtsmæssigt at starte undervisningen inden 

for et deklarativt paradigme[Reinfelds93], da alle har samme startforudsætninger.[Pedroni03] 

• Beherskelse en række mindre koncepter, og gør det muligt at løse interessante problemer og 

giver en gradvis overgang fra konkrete til abstrakte koncepter inden for problemløsning.[Reinfelds93] 



• Deklarative giver en god opdeling mellem en præcision ved løsningen af problemet og en 

effektiv implematation af løsningen.[Reinfelds93] 

• Deklarativ vil give en nemmere forst˚aelse af datalogien, og det bevirker at den studerende 

allerede fra første dag, kan skrive meningsfyldte programmer.[Reinfelds93] 

6.3.2 Ulemper 

• Mange studerende vil finde det svært at skulle tænke abstrakt inden for paradigmet. At 

introducere abstraktion tidligt i undervisningsforløbet kan afskrække studerende der ikke 

er vant til denne tankegang, som st˚ar skrevet i Michela Pedronis afhandling [Pedroni03] 

• Rekursion er en vigtig del af det funktionsorienterede paradigme og skal introduceres 

tidligt. Det er ofte tilfældet at studerende har problemer med at lære rekursion fordi de 

endnu ikke har den nødvendige viden for at forst˚a princippet, hvilket st˚ar skrevet i Michela 

Pedronis afhandling[Pedroni03] 

6.4 Multiparadigmet 

Helt overordnet burde studerende undervist i multiparadigmet have en bredere vifte af løsningsmodeller 

p˚a datalogiske problemstillinger end studerende med kendskab til kun et enkelt 

programmeringsparadigme, hvorfor de burde have en bedre forst˚aelse af grundprincipperne inden 

for programmeringen. 

6.4.1 Fordele 

• De studerende vil efter det indledende programmeringskursus være bedre rustet til de 

uundg˚alige fremtidige programmeringsparadigme skift. Eleverne skulle alts˚a have meget 

lettere ved at tilegne sig nye programmeringssyn, da man har den bredere vifte af løsningsmuligheder 

i kraft af anvendelsen af flere paradigmeteorier.[Budd95c] 

• Undervisningen er ikke styret af de nuværende industrille krav, som bekendt ogs˚a skifter 

hyppigt.[Budd95c] 

• Det har vist sig at studerende, der skal omstille sig fra det først indlærte paradigme til 

et nyt m˚aske endog mere pædagoisk paradigme, har store vanskeligheder med at tilegne 

sig de nye principper, og det er endvidere ofte en tidskrævende process [Brilliant96]. Hvis 

man skal vende argumentet om burde de studerende undervist i multiparadigmet i s˚a 

fald ogs˚a have svært ved at begrænse sig til eksempelvis udelukkende objektorienterede 

løsninger, hvis de senere hen tvinges til at arbejde med det paradigme. Dette postulat 

nævnes dog ikke i artiklen. Dog betegnes mange nye programmeringssprog som s˚akaldte 

hybrid sprog, der kombinerer to paradigmer i et enkelt sprog[Budd95c], det tyder p˚a at 

det er den generelle opfattelse, at kombinationer af traditionelle paradigmer er noget man 

vil se mere til i fremtiden. Hvis hybridsprog bliver et gennemg˚aende fællestræk for nye 

programmeringssprog, kan det tænkes at multiparadigmet vil være en god baggrund. 

• Det første undervisningsparadigme menes at have en stor indflydelse p˚a hvordan, man 

overordnet opfatter det at programmere, hvilket kan læses i J. Placer [Placer91], og er med 

til at p˚avirke den studerende adskillige ˚ar frem. Dette undg˚as netop i multiparadigmet 

da man netop ikke ensporet koncentrerer sig om et enkelt paradigme i den indledende 

undervisning. 

• I og med de studerende præsenteres for forskellige paradigmers løsninger i et multiparadigmentioneltsprog, 

undg˚as mange af de syntaksvanskeligheder der ellers ville være til 

stede, n˚ar et nyt paradigme skal indlæres p˚a traditionelvis ved brug af, et for dem, nyt 

programmeringssprog. Dermed kan der fokuseres p˚a programmeringens grundprincipper 

i stedet. [Placer93] 



6.4.2 Ulemper 

• Der argumenters for, at man p˚a første programmeringskursus kun skal undervises i et 

enkelt paradigme og lære dets grundprincipper til fulde, da man kun kan f˚a den nødvendige 

indsigt i et enkelt paradigme, ved at arbejde med det ét helt semester[Bruhn]. 

• Undervisning i multiparadigmet kunne m˚aske skræmme potentielle dataloger væk fra 

feltet, da den konkrete indsigt og fordybelse i et af de mere anvendte programmeringsparadigmer 

ikke er tilstede[Bruhn]. 


Kapitel 7 

Undersøgelse 

7.1 Om undersøgelsen 

Form˚alet med undersøgelsen er, at give et indblik i hvilke paradigmer, der bliver brugt til introducerende 

datalogikurser p˚a de danske uddannelsesinstutionerner. Vi har valgt at kontakte 

lange og mellemlange videreg˚aende uddannelser, og det er blevet til 16 datamatikerskoler, 7 datalogiskeinstitutter 

og 3 ingeniørskoler. Undersøgelsen blev foretaget per e-mail, hvor der blev 

stillet følgende tre spørgsm˚al: 

Spørgsm˚al: 

• Indenfor hvilket paradigme/sprog udbyder I de indledende programmeringskurser? 

• Udfra hvilke kriterier har I gjort disse valg? 

• Hvem har truffet valget? Har det for eksempel været op til de enkelte kursusundervisere, 

eller har der været en overordnet planlægning heraf? 

Form˚alet med undersøgelsen har som nævnt kun været at f˚a et overblik over, hvilke paradigmer 

der undervises i, p˚a de introducerende programmeringskurser, og at f˚a argumenter for 

disse valg. Derfor har vi valgt at e-mailen kun skulle indeholde disse relative enkelte spørgsm˚al. 

Vi valgte bevidst at skrive paradigme/sprog i første spørgsm˚al, selvom vi i rapporten kun 

behandler paradigmer. Dette skyldes vores tvivl, om der er nogen paradigme overvejelser p˚a 

alle institutioner. 

7.2 Forventninger til undersøgelsen 

Vores forventninger til undersøgelsen gik p˚a at se en tydelig opdeling, af hvilke paradigme der 

bliver undervist i og p˚a hvilken type uddannelsessted. 

Da det objektorienteret paradigme er det hyppigst anvendte paradigme p˚a arbejdsmarkedet, 

har vi en forventning om at datamatikerne undervises i dette paradigme. Denne introduktion 

er mest hensigtsmæssig for datamatikerne, da de kan g˚a direkte ud i erhvervslivet, forberedt til 

at programmere i det paradigme der allerede anvendes, p˚a den p˚agældende arbejdsplads. 

Forventningerne til ingeniørernes introduktion til det imperative paradigme, skyldes at det 

er det, paradigme der ligger nærmest maskinkode. Den lave abstraktion er velegnet til ingeniørernes 

viden om maskinarkitektur. 

Forventningerne til datalogi–institutionerne er et kursus der tilbyder generel og fremtidssikret 

programmeringsundervisning. Det vil sige at undervise i overordnede metoder, ikke specifikke 

og produktafhængige. 

35


7.3 Resultat 

Af de 26 emails, fik vi svar tilbage fra 13 — nogle mere fyldige end andre. 

Hvis vi først kigger p˚a spørgsm˚alet: ” Indenfor hvilket paradigme/sprog udbyder I de indledende 

programmeringskurser?“ s˚a var fordelingen som følgende: 

Antal 

Java (objektorienteret) 9 

C++ (objektorienteret) 3 

Delphi (objektorienteret) 1 

Ubesvaret 13 

Tabel 7.1: Resultat fra undersøgelsen. 

Det er interessant, at alle sprogene er objektorienteret. Man skal dog huske p˚a, at der 

er imperative tankegange i de objektorienterede sprog, der her undervises i, da man i det 

objektorienteret sprog C++ kan ligge meget vægt p˚a det imperative element, eftersom det er 

en udvidelse af det imperative sprog C. 

Til spørgsm˚alet om, hvad der har ligget til grund for valg af sprog, var svarene godt fordelt 

udover; hensyn til erhvervslivet, især omkring JAVA, der samtidig giver et godt grundlag for det 

objekt orienterede paradigme. Nedenfor er der citeret et udsnit af svarene til dette spørgsm˚al. 

Pædagogisk optimal og samtidig er kompleksiteten stor nok, relevant for erhvervslivet.(IT 

Akademiet, Skive) 

Pædagogiske overvejelser, samt faglige, dvs. hvilke sprog som erhvervslivet anvender. (Uddannelsesleder 

Erhvervsakademi Midtjylland) 

Objektorientering har vi valgt ud fra følgende kriterier: 

• OO understøtter en tydelig opdeling af systemer og programmer. 

• OO understøtter b˚ade data-abstraktion og funktionel abstraktion 

• OO er moderne og udbredt i undervisningssektoren samt i erhverslivet 

• Java er udbredt og egner sig rimelig godt til grundlæggende undervisning 

P˚a tidspunktet for valget (˚ar 1999) var Java efter vor opfattelse det bedste valg. Andre sprog 

overvejes løbende.(Vejle handelsskole) 

Jeg kan ikke udtale mig med stor autoritet om hvorfor det lige er Java man har valgt, men 

jeg kan komme med nogle gæt (IT-Universitetet i København): 

• Det bliver benyttet i ganske mange firmaer. 

• Det har en syntaks som er relativt let at læse i forhold til f.eks C++. 

• Det giver god mulighed for at demonstrere mange grundlæggende begreber indenfor 

OOP. 

Industrirelevans + at den hardware og de systemer vi arbejder med forudsætter anvendelsen 

af C/C++. Eksempelvis ville det ikke være muligt at anvende Java som alternativ. 

(Ingeniørhøjskolen ˚ Arhus) 



Til spørgsm˚alet om hvem der træffer beslutningen om hvilket sprog/paradigme der skal undervises 

i har stort set alle svaret, at det er lærekolegiet der tager en fælles beslutning. 

Vurdering af undersøgelsen 

Vi kan konstatere, at svarene for undersøgelsen ikke opfylder vores ønske om at f˚a undersøgt 

hvilket paradigme, der undervises i p˚a de udvalgte uddannelsesinstitutioner. Vi havde forh˚abninger 

om at resultatet af undersøgelsen, ville best˚a af en række argumenter for hvilket paradigme 

universiteter, datamatikeruddannelser og ingienøruddannelser bruger i deres indledende 

programmeringsundervisning. 

Tilsyneladende fremgik det ikke klart i vores spørgsm˚al, at uddannelsesinstitoutioner skulle 

argumentere for deres brug af programmeringsparadigme og ikke programmeringssprog. Dette 

har formentlig været˚arsagen til vi ikke opn˚aede det ønskede resultat. Det betyder, at vi kun bruger 

argumenterne fra vores artikler og udfra dem vurdere hvilket paradigme, der skal anvendes 

i et indledende programmeringskursus. 


Kapitel 8 

Diskussion 

Vi vil i diskussionen tage udgangspunkt i argumenterne, vi præsenterede i kapitel 6. I dette afsnit 

vurderes hvordan man opn˚ar den optimale introducerende programmeringsundervisning. Denne ses ud 

fra forskellige fokusomr˚ader inden for programmering orienteret mod det anvendelige og teoretiske, og 

skal lede op til den afsluttende konklusion. 

Igennem projektforløbet har projektgruppen gentagende gange gjort sig overvejelser omkring 

m˚alet med de indledende programmeringskurser. Hvis m˚alet er at gøre de datalogi–studerende 

s˚a attraktive som overhovedet muligt for erhvervslivet — her antager vi at erhvervslivet ikke 

vægter innovation og nytænkning højt — m˚a det formodes at der fokuseres p˚a et programmeringsparadigme 

og de mest udbredte programmeringssprog inden for dette, hvorfor det vil være 

mest hensigtsmæssigt at undervise i kun det paradigme fra studiets begyndelse. Derved kan den 

studerende f˚a s˚a meget erfaring og knowhow inden for paradigmet som overhovedet muligt. 

En anden indgangsvinkel er at give den studerende den brede programmeringsviden. Det vil 

sige en bredde som formodentlig vil give et bredere perspektiv, og dermed et større indblik 

i udviklingen af nye programmeringsmetoder og forskningsomr˚ader inden for programmering. 

Har den studerende kendskab og erfaringer med løsninger inden for de forskellige programmeringsparadigmer, 

er det sandsynligt at man efterfølgende har en bedre baggrund for at designe 

algoritmer og løsningsmodeller til forskelligartede opgaver. Dog kan man frygte, at erhvervslivet 

ikke værdsætter eksempelvis evner og kendskab til logikprogrammering særlig højt, og derfor 

stort set altid ville vælge at ansætte datalogen, der har størst erfaring med programmering, 

inden for det paradigme som er oppe i tiden. 

En anden ting, vi har haft med i vores overvejelser, er om man med fordel ikke kan undervise 

de studerende i programplanlægning, alts˚a hvordan man kan dele en problemstilling op i mindre 

dele og p˚a den m˚ade f˚a et overblik over, hvorledes man bør starte sin programmering. Dette er 

selvfølgelig især oplagt, hvis man senere har til hensigt at sætte sig ind i objektorienteret programmering. 

Man taler ogs˚a om evnen til at analysere problemstillinger og dermed hurtigere 

komme ind til selve programmeringen. Det tænkes, at den studerendes manglende programmeringsevner 

vil vanskeliggøre forst˚aelsen af programplanlægningen, og det dermed ikke er en 

hensigtsmæssig introduktion til programmering. 

Vi vil ud fra problemformuleringen finde den mest hensigtsmæssige programmeringsundervisning. 

Derfor opstiller vi nu de tidligere omtalte tilgangsvinkler. De to tilgangsvinkler til 

programmeringsundervisningen er følgende. 

Inspirationen til denne opdeling blev fundet i IT-Lex [itLex01]. 

• Teoretisk datalogi. Her lægges vægt p˚a studiet af de principelle muligheder for databehandling, 

som dækker datarepræsentation og transformation. 

38


• Anvendt datalogi — Datamatik. Med dette tænkes at der skal tilegnes et dybdeg˚aende 

kendskab og kompetence indenfor programmering, systemkonstruktion og planlægning. 

Den faktiske udnyttelse af den ” teoretiske datalogi“ sker i den ” anvendt datalogi“ . 

Det er op til ledelsesorganer for studiet at definere i den p˚agældende studieordningen, hvad 

der efterfølgende ønskes, de studerende skal være specialiseret i. Vi som projektgruppe vil ikke 

udtale os om hvordan en s˚adan studieordning konkret bør se ud, men derimod vende os mod 

tilgangsvinklerne. 

8.1 Anvendt datalogi — Datamatik. 

Vi vil nu vurdere programmeringsparadigmerne som valget til første programmeringskursus ud 

fra anvendt datalogisk tilgangsvinkel. 

Vi finder multiparadigmet mindst hensigtsmæssig i forhold til de andre paradigme inden for 

denne tilgangsvinkel. Da dette medfører manglende fordybelse i et konkret paradigme. Derfor 

f˚ar den studerende ingen dybdeg˚aende kompetence efter det introducerende kursus, hvorfor 

man mangler evnen til at løse konkrete anvendelses relaterede opgaver, i den umiddelbare 

efterfølgende undervisning. 

Multiparadigmet er ikke aktuelt anvendelsesorienteret, da der p˚a nuværende tidspunkt ikke 

findes noget alment udbredt multiparadigmalt sprog. 

De deklarative paradigmer er ikke hensigtsmæssige, da paradigmernes anvendelsesspektre er 

en anelse snævert, hvorfor man m˚a formode det ikke vil give den studerende generelle brugbare 

kompetencer indenfor systemplanlægning og konstruktion. Endvidere er mulighederne for at 

udvikle generelle applikationer under de deklarative paradigmer begrænset. 

Abstraktionniveauet i deklarative paradigmer er p˚a et højere niveau, hvorfor det kan tænkes 

at de studerende ikke vil vinde noget ved at blive undervist p˚a dette niveau, og vil eventuelt 

afskrække dem for studiet i forhold til deres forventninger. 

Avancerede begreber bliver introduceret p˚a et tidligere niveau grundet paradigmets struktur, 

hvorfor der er meget teoretisk fokus allerede i starten, hvilket ikke er hensigtsmæssigt i forhold 

til programudvikling. 

Endvidere er det et faktum, at de deklarative paradigmer ikke er særlige udbredte, hvilket 

betyder de færreste har forudg˚aende kendskab til paradigmet. Dette er en fordel for den 

studerende i forbindelse med den introducerende undervisning, da alle starter p˚a samme niveau. 

Det imperative paradigme er som s˚adan et ganske fornuftigt valg til det indledende programmeringskursus. 

Det er simpelt i sin opbygning og har lavt abstraktionsniveau, hvilket gør det 

fordelagtigt for studerende, som ikke har noget kendskab til programmering. Endvidere kunne 

det tænkes at programmeringskurser med undervisning i imperativ ville appelere til studerende, 

som ikke har planer om at studere datalogi, da eksempelvis fysikere og matematikere kan f˚a 

brug for, at skrive sm˚a simple programmer til talbehandling eller lignende. 

Lignende grundlæggende opbygning, af eksempelvis løkker, findes ofte i objektorienterede 

sprog, og en senere tilgang til s˚adanne vil muligvis være lettere for den studerende. Dog er 

der blevet argumenteret for at de studerende skulle være negativt indstillet p˚a at lære nye 

programmeringssyn — det er dog ikke noget holdbart argument, da man burde undg˚a en generel 

negativ indstilling ved en pædagogisk tilgang til et nyt paradigme. 

Paradigmet skulle, som nævnt i kapitel 6, falde naturligt for mange studerende. Det i kombination 

med de mange ˚ars erfaring og veludviklede pædagoiske undervisningsmateriale inden 

for imperative programmering, giver det de bedste forudsætninger for de studerende for at tage 

imperative programmering til sig. Risikoen for sideeffekter og dermed unødige tidskrævende 

problemer er overhængende, og kan være et problem. 



Undervisning i det imperative paradigme vil give den studerende en fornuftig basis indenfor 

simpel programmering, der efterfølgende kan bygges videre p˚a. 

Vi mener, at undervisningen indenfor det objektorienterede paradigme er et oplagt valg til 

et introducerende programmeringskursus. De tidlige design overvejelser og arbejdet med at 

strukturere et program bliver lettere tilgængeligt med objekter. Endvidere er der ogs˚a dem, der 

mener den objektorienterede tankegang ligger tættere opad den virkelige verden og dermed er 

hurtigt at tilegne. 

Der kan argumenteres for, at det er sværere at tilegne sig det objektorienteret paradigme, 

n˚ar man allerede har opereret inden for andre paradigmer. Overgangen fra objektorienteret til 

andre paradigmer er efter sigende nemmere for de studerende. 

Det objekt orienterede paradigme opfylder de opstillede punkter godt inden for datamatik, 

b˚ade med kompetence indenfor reel programmering og planlægning. 

8.2 Teoretisk datalogi 

Det imperative paradigme er det traditionelle programmeringsparadigme. Det er relativ simpel 

og giver god træning i procesorienteret programmering. Paradigmet ligger tæt p˚a den maskinelle 

udførelse, hvilket gør at den studerende f˚ar en god indsigt i den reelle maskinudførelse. 

P˚a den anden side er abstraktionsniveauet i det imperative paradigme meget lavt, hvilket 

gør det svært for den studerende at repræsentere data p˚a et højere plan, og der skal meget 

grundarbejde til. Da paradigmet netop opererer p˚a dette nærmaskinelle plan fjerner det fokus 

fra teorien, da man skal bruge forholdsvis meget energi p˚a at realisere teorierne i paradigmet, 

eftersom der skal tages højde for kodning af mere triviel art. 

Det objektorienterede paradigme løfter programmøren fra det maskinnære abstraktionsniveau 

til en problemløsningsmetode nærmere den menneskeligetankegang. 

Overgangen fra objektorienteret paradigme til andre paradigmer, er ikke nær s˚a problematisk 

som ved andre paradigmer. Dette er en fordel for den teoretisk tilgangsvinkel til datalogi, da 

man her arbejder med flere paradigmer. 

I forhold til den teoretiske forst˚aelse for paradigmer er objektorienteret d˚arligt ved en førstegangsundervisning, 

eftersom der ved det introducerendekursus formentlig vil være en del 

udenadslæren. 

Hvis man derimod ser p˚a den deklarative tankegang, som er med til at bringe programmøren 

p˚a et højere abstraktionsniveau, s˚a har det en del fordele: Man bevæger sig væk fra det mere 

maskinnære og tankegangen om, ” hvordan gør vi det“, til det mere overordnede, ” hvad er det, vi 

gør“. Bindingen til maskinens m˚ade at gøre tingene p˚a undg˚ar man stort set, da man slipper for 

at tænke p˚a at allokere hukommelse og sletning af brugte referancer. Ved at lægge selve maskinens 

m˚ade at arbejde p˚a til side gives et større perspektiv, da man under programudviklingen 

ikke tynges ned af beslutninger af mere teknisk art. 

Samtidig kan det ogs˚a argumenteres at abstraktions niveauet kan blive for højt. Det kan 

være svært for de studerende at sætte sig ind i den ofte ganske anderledes tankegang, samtidig 

med at det er let at miste overblikket. Dette sammen med at de deklarative paradigmer ikke er 

alment udbredt, kan give de studerende en skeptisk holdning. 

Endvidere er det et faktum, at de deklarative paradigmer ikke er særlige udbredte, hvilket 

betyder de færreste har forudg˚aende kendskab til paradigmet. Dette er en fordel for den 

studerende i forbindelse med den introducerende undervisning, da alle starter p˚a samme niveau. 

Multiparadigmet er et oplagt valg til denne teoretiske tilgang, da fokus ikke bliver p˚a de 

forskellige paradigmers individuelle sprogs syntaks, men p˚a de paradigmentionelle principper 

og en forst˚aelse af disse. Multiparadigmet gør det nemmere for den studerende at sætte sig ind 

i fremtidige programmeringsparadigmer. Multiparadigmet giver de bedste muligheder for ikke 



at blive udsat for en paradigmatisk styring — om man vil det eller ej. Dette er netop vigtigt for 

en mere teoretisk orienteret datalog, eftersom denne helst skal kunne arbejde objektivt inden 

for flere paradigme. 


Kapitel 9 

Konklusion 

Vi kan p˚a baggrund af det forudg˚aende projektarbejde konkludere, at for ´”Anvendt datalogi“ 

vil det være mest hensigtsmæssigt at anvende det objekt orienterede paradigme til den introducerende 

undevisning, da dette giver den studerende kompetencer indenfor b˚ade konkret 

programmering og systemplanlægning. 

Hvis man vælger at starte undervisning med henblik p˚a et mere teoretisk syn, vil det være 

mest optimalt at starte med multiparadigmet, da dette fra starten af den introducerende programmeringsundervisning, 

giver den studerende et kendskab til paradigmatiske grundprincipper 

i programmering. 

42

Kapitel 10 

Perspektivering 

Projektarbejdet tog udgangspunkt i spørgsm˚alet ´”Hvilket paradigme er mest hensigtsmæssigt 

at anvende til introducerende programmeringsundervisning, for hver af de to tilgangsvinkler?“. 

Vi valgte at bedømme paradigmerne udfra nogle bestemte tilgangsvinkler, men der var som 

s˚adan intet, der forhindrede os i at have bedømt paradigmerne udfra nogle andre tilgangsvinkler. 

Man kunne eventuelt have argumenteret for, at ´”hensigtsmæssigt“ ville være et paradigme 

hvor man allerede efter første kursusgang ville være i stand til skrive et stykke kode, der kunne 

udføre noget, samtidig med at man forst˚ar hvorfor koden se ud som den gør. ´”Mest hensigtsmæssigt“ 

kunne ogs˚a bare være set i forhold til erhvervslivet. 

Vi valgte at beskæftige os med paradigmer, for at rapporten ville kunne sige noget mere 

generelt, og ikke bare se p˚a et lille udsnit af konkrete programmeringssprog. Men efter nu at 

have indkredset hvilket paradigme, der er mest hensigtsmæssigt at starte undervisningen med, 

ville det da være interessant at lave et opfølgende projekt, der havde til form˚al at undersøge 

hvilket sprog man konkret skulle undervise i. 

Man ville eventuelt kunne gøre den endnu mere specifik, og konkludere hvad man skal undervise 

i p˚a eksempelvis RUC. 

Hvis vi skal vende tilbage til undersøgelser, der kunne være interessante: En undersøgelse af 

hvad de studerende p˚a et indledende programmeringskursus finder vanskeligt. 

43

Litteratur 

[Bergin96] Thomas J. Bergin & Richard G. Gibson, ” History of Programming Languages“, 

The American University Washington D.C.,1996 

[Brilliant96] Susan S. Brilliant og Timothy R. Wiseman, ” The first programming paradigm 

and language dilemma“, ACM SIGCSE Bulletin , Proceedings of the 

twenty-seventh SIGCSE technical symposium on Computer science education, 

Volume 28, Issue 1, 1996 

[Bruhn] P. J. Burton og R. E. Bruhn, ” Teaching programming in the OOP era“, 

ACM SIGCSE Bulletin, Volume 35, Issue 2 

[Budd95b] Timothy A. Budd, ” Multiparadigm Programming in Leda“, Addison-Wesley, 

1995 

[Budd95c] Timothy A. Budd og Rajeev K. Pandey, ” Never Mind the Paradigm, What 

About Multiparadigm Languages?“, ACM SIGCSE Bulletin, Volume 27 Issue 

2, 1995 

[cs.auc.dk1] Undervisnings materiale p˚a AUC - http://www.cs.auc.dk/∼normark/ps3- 

98/noter/pdf/intr.pdf 

[Curricula01] Computing Curricula 2001, ACM og IEEE-CS, 

http://www.computer.org/education/cc2001/final/chapter07.htm 

[Decker93] Rick Decker og Stuart Hirshfield, ” Top-down teaching: Object-oriented programming 

in CS1“, ACM SIGCSE Bulletin , Proceedings of the twentyfourth 

SIGCSE technical symposium on Computer science education, Volume 

25, Issue 1, 1993 

[dictionary.reference.com] Online engelsk ordbog - http://dictionary.reference.com/ 

[Gordon88] Michael J. C. Gordon, ” Programming Language Theory and its Implementaion“, 

Prentice Hall International (UK) Ltd, 1988 

[Hadjerroult98] Said Hadjerroult, ” Java as First Programming langauge: A critical evaluation“, 

ACM SIGCSE Bulletin, Volume 30, Issue 2 

[Harbison91] Samuel P. Harbinson & Guy L. Stelle Jr., ” C a reference manual“, 3 udg, 

Prentice-Hall, 1991 

[HofPL] Thomas J. Bergin og R. Gibson, ” History of programming languages“, ACM 

Press, 1996 

[Horstmann03] Cay Horstmann, ” Computing Concepts with Java Essentials“, 3. udg, Wiley, 

2003 

[Høholdt00] Tom Høholdt og Helge Elbrønd Jensen, ” Grundlæggende matematik“, Institut 

for Matematik, DTU, 2000 

44


[itLex01] 

” IT-lex“, 2. udg., Ingeniøren | bøger, 2001 

[Karush78] Willian Karush, ” Matematisk Opslagsbog“, Politikens Forlag, 1978 

[Kowalski] Robert Kowalski, ” Algoritm = Logik + Control“, Imperial College, London 

[Kragh91] Helge Kragh og Stig Andur Pedersen, ” Naturvidenskabens teori“, 2. udg., 

Nyt Norisk Forlag Arnold Busk, 1991 

[Kuhn73] Thomas Kuhn, ” Videnskabens Revolutioner“, Fremad, 1973 

[Lehmann] Ole Lehrmann Madsen, ” Towards A Unified Programming Language“, Aahus 

Universitet. 

[Luker89] Paul A. Luker, ” Never mind the Language, What about the Paradigme?“, 

ACM SIGCSE Bulletin , Proceedings of the twentieth SIGCSE technical 

symposium on Computer science education, Volume 21, Issue 1 

[Luker94] Paul A. Luker, ” There’s more to OOP than syntax“, ACM SIGCSE Bulletin 

, Proceedings of the twenty-fifth SIGCSE symposium on Computer science 

education, Volume 26, Issue 1 

[Mey87] Meyer, B., ” Reusability: The Case for Object-Orieted Design“, IEEE 

Software, March 87 

[Neubauer02] B. J. Neubauer og D.D. Strong, ” The Object-oriented paradigm: More natural 

og less familiar?“, JCSC 18, okt, 2002 

[Nudansk96] Erik Høvring, ”Politikens store nye Nu Dansk ordbog“, Politikens Forlag, 

1996 

[Nudansk92] 

” Poltikens Nudansk Ordbog“, 15. udg., Politikens Forlag, 1992 

[Sammet69] Jean E. Sammet, ” Programming Languages: History and Fundamentals“, 

Prentice–Hall, 1969 

[Spinellis93] Diomidis D. Spinellis, ” Programming paradigms as Object Classes: A Structuring 

Mechanism for Multiparadigm Programming“, maj 1993, doktordisputats, 

Dept. of Computing, University of London, United Kingdom 

[Sterling2000] Leon Sterling og Ehud Shapiro, ” Art of Prolog“, Second Edition 2000 

[Paulson91] Laurence C. Paulson, ” ML for the Working Programmer“, Cambridge University 

Press, 1991 

[Pedroni03] Michela Pedroni, ” Teaching introductory programming with the inverted 

curriculum Approache“, Diploma thesis, Dept. of Computer Science, ETH 

Zurich, 2003 

[Placer91] John Placer, ” Multiparadigm Research: A New Direction In Language Design“, 

ACM SIGPLAN Notices, vol. 26, no. 3, March 1991 

[Placer93] John Placer, ” The promise of multiparadigm languages as pedagogical 

tools“, Proceedings of the 1993 ACM conference on Computer scienc, 1993 

[Rebelsky01] Samuel A. Rebelsky m.fl., ” Why I Do Declare! Declarative Programming 

in the Undergraduate Curriculum“, ACM SIGCSE Bulletin , Proceedings 

of the thirty-second SIGCSE technical symposium on Computer Science 

Education, Volume 33, Issue 1, 2001 



[Reinfelds93] Juris Reinfelds og Gopal Gupta, 

” LP as an Introductory 

Programming Paradigm“, http://wwwlp.doc.ic.ac.uk/UserPages/staff/ft/alp/comment/intro.html 

[Reinfelds95] Juris Reinfelds, ” A three paradigm first course for CS majors“, ACM 

SIGCSE Bulletin , Proceedings of the twenty-sixth SIGCSE technical symposium 

on Computer science education, Volume 27, Issue 1, 1995 

[Rosenberg95] M. Kölling, B. Koch og J. Rosenberg, ” Requirements for a first year objectoriented 

teaching language“, ACM SIGCSE Bulletin , Proceedings of the 

twenty-sixth SIGCSE technical symposium on Computer science education, 

Volume 27, Issue 1 

[Sprague02] Peter Sprague og Celia Schahczenski, ” Abstraction the key to CS1“, The 

Journal of Computing in Small Colleges, Volume 17, Issue 3, 2002 

[Thompson99] Simon Thompson, ” Haskell: The Craft of Functional Propgramming“, 2. 

udg., Addison-Wesley, 1999 

[VirginaTech] John A. Lewis, Sallie M. Henry, Dennis G. Kafura “‘An Empircal Study of 

the Object-Oriented Paradigm and Software Reuse´”, Virginia Tech, Blacksburg, 

Virginia 

[Wadler] Philip Wadler, ” Function Programming, Why no one uses funtional languages“, 

Bell Laboratories, Lucent Technologies 

[Weisfeld01] Matt Weisfeld, ” Objektorienterede begreber“, IDG, 2001 

[wikipedia.org1] http://en.wikipedia.org/wiki/Functional programming#History 

[wikipedia.org2] http://en.wikipedia.org/wiki/Imperative programming 

Sekundær litteratur 

- Maurive V. Wilkes, ” From Fortran and Algol to Object-Oriented Languages“, Communications 

of the ACM, Juli 1993, no. 7, p. 21-23 

- Hugh Glasser, Chris Hankin og David Till, ” Principles of Functional Programming“, 

Prentice-Hall International, 1984 

- ˚ Ake Wikström, ” Functional Programming Using Standard ML“, Prentice-Hall International, 

1987 

- Malcolm Morrison og Timothy S. Newman, ” A Study of the Impact of Student Background 

and Preparedness on Outcomes in CS I“, ACM SIGCSE Bulletin , Proceedings of the 

thirty-second SIGCSE technical symposium on Computer Science Education, Volume 33, 

Issue 1, 2001 

- Douglas Goodman og R. A. McBride, ” Ada as an Introductory Language“, Proceedings 

of the conference on TRI-Ada ’92, 1992 

- Katrin Becker, ” Back to Pascal: retro but not backwards“, The Journal of Computing in 

Small Colleges, Volume 18, Issue 2, 2002 

- William Marion, ” CSl: What Should We Be Teaching?“, SIGCSE Bulletin, Vol 31, 4, 

December 1999 

- Elliot Koffman og Ursula Wolz, ” CSI Using Java Language Features Gently“, ACM SIGCSE 

Bulletin , Proceedings of the 4th annual SIGCSE/SIGCUE ITiCSE conference on Innovation 

and technology in computer science education, Volume 31, Issue 3, 1999 



- Niklaus Wirth, ” Computing Science Education: The Road not Taken“, ACM SIGCSE 

Bulletin , Proceedings of the 7th annual conference on Innovation and technology in 

computer science education, Volume 34, Issue 3, 2002 

- N. Ram, ” Effectiveness of paradigmatic approach in teaching programming“, Proceedings 

of the ACM 1980 annual conference, 1980 

- Kris Howell, ” First computer languages“, The Journal of Computing in Small Colleges, 


- Mary Beth Rosson, ” How might the object-oriented paradigm change the way we teach 

introductory programming?“, CM SIGPLAN OOPS Messenger , Addendum to the proceedings 

on Object-oriented programming systems, languages, and applications (Addendum), 


- Cara MacNish m.fl., ” Java as a teaching language — opportunities, pitfalls and solutions“, 

Proceedings of the third Australasian conference on Computer science education, 1998 

- Chuck Leska m.fl., ” Multiple paradigms in CS I“, ACM SIGCSE Bulletin , Proceedings of 

the twenty-seventh SIGCSE technical symposium on Computer science education, Volume 

28, Issue 1, 1996 

- Amruth Kumar m.fl., ” Resources for Next Generation Introductory CS Courses“, ITiCSE 

1999 Working Group Reports, Vol 31, 4, 1999 

- Joel C. Adams, ” Object-centered design: a five-phase introduction to object-oriented programming 

in CS1–2“, ACM SIGCSE Bulletin , Proceedings of the twenty-seventh SIGCSE 

technical symposium on Computer science education, Volume 28, Issue 1, 1996 

- Mary Jane Willshire, ” Old Dogs, New Tricks“, ACM SIGCSE Bulletin , Proceedings of 

the twenty-sixth SIGCSE technical symposium on Computer science education, Volume 

27, Issue 1, 1995 

- Rolf Wiehagen m.fl., ” On the Power of Learning Robustly“, Proceedings of the eleventh 

annual conference on Computational learning theory, 1998 

- Ariel Ferreira Szpiniak m.lf., ” Our Experience Teaching Functional Programming at University 

of Rio Cuarto (Argentina)“, SIGCSE Bulletin, Vol 30, 2, 1998 

- Nan C. Schalle m.fl., ” Using Java in computer science education“, The supplemental proceedings 

of the conference on Integrating technology into computer science education: 

working group reports and supplemental proceedings, 1997 

- Leon E. Winslow, ” Programming Pedagogy – A Psychological Overview“, SIGCSE BUL- 

LETIN, Vol. 28, 3, 1996 

- Michael Kölling m.fl., ” Requirements for a first year object-oriented teaching language“, 

ACM SIGCSE Bulletin , Proceedings of the twenty-sixth SIGCSE technical symposium 


- M. B. Wells og B. L. Kurtz, ” Teaching multiple programming paradigms: a proposal for 

a paradigm general pseudocode“, ACM SIGCSE Bulletin , Proceedings of the twentieth 

SIGCSE technical symposium on Computer science education, Volume 21, Issue 1, 1989 

- Suzanne Skublics og Paul White, ” Teaching Smalltalk as a First Programming Language“, 

ACM SIGCSE Bulletin , Proceedings of the twenty-second SIGCSE technical symposium 


- Ursula Wolz m.fl., ” Teaching introductory programming in the multi-media world“, ACM 

SIGCSE Bulletin , Proceedings of the 1st conference on Integrating technology into computer 

science education, Volume 28, 1996 


Paradigmer i programmering Kapitel .0 

- ” A debate on Teaching Computing Science“, Communications of the ACM, Volume 32, 

Number 12, 1989 

- Mohsen Beheshti, Ananda D. Gunawardena, ” Teaching programming paradigms using a 

laboratory approach“, The Journal of Computing in Small Colleges, Volume 16, Issue 3, 

2001 

- Piyush Maheshwari, ” Teaching Programming Paradigms and Languages for Qualitative 

Learning“, Proceedings of the second Australasian conference on Computer science education, 

1997 

- Roger Duke m.fl., ” Teaching Programming to Beginners — choosing the language is just 

the first step“, Proceedings of the Australasian conference on Computing education, 2000 

- N.N. King, ” The evolution of the programming languages course“, ACM SIGCSE Bulletin 

, Proceedings of the twenty-third SIGCSE technical symposium on Computer science 

education, Volume 24, Issue 1, 1992 

- Tony Jenkins, ” The Motivation of Students of Programming“, ACM SIGCSE Bulletin 

, Proceedings of the 6th annual conference on Innovation and technology in computer 

science education, Volume 33, Issue 3, 2001 

- Richard J. Reid, ” The object oriented paradigm in CS 1“, ACM SIGCSE Bulletin , Proceedings 

of the twenty-fourth SIGCSE technical symposium on Computer science education, 


- Amparo Lopez Gaona, ” The Relevance of Design in CS1“, SIGCSE Bulletin, Vol 32, 2, 

2000 

- Peter Van Roy m.fl., ” The Role of Language Paradigms in Teaching Programming“, ACM 

SIGCSE Bulletin , Proceedings of the 34th SIGCSE technical symposium on Computer 

science education, Volume 35, Issue 1, 2003 

- Rick Decker og Stuart Hirshfield, ” The Top 10 Reasons Why Object-Oriented Programming 

Can’t Be Taught in CS 1“, ACM SIGCSE Bulletin , Proceedings of the twenty-fifth 

SIGCSE symposium on Computer science education, Volume 26, Issue 1, 1994 

- A. Michael Berman m.fl., ” Using C++ in CS1/CS2“, ACM SIGCSE Bulletin , Proceedings 

of the twenty-fifth SIGCSE symposium on Computer science education, Volume 26, Issue 

1, 1994 

- L.F. Johnson, ” C in the First Course Considered Harmful“, Communications of the ACM, 

Vol. 38, 5, 1995 

- Richard Close m.fl., ” CS1: perspectives on programming languages and the breadth-first 

approach“, The Journal of Computing in Small Colleges , Proceedings of the fifth annual 

CCSC northeastern conference on The journal of computing in small colleges, Volume 15, 

Issue 5, 2000 

- Frances Bailie m.fl., ” Objects first — does it work?“, The Journal of Computing in Small 

Colleges, Volume 19, Issue 2, 2003 

- Stephen A. Bloch, ” Scheme and Java in the first year“,The Journal of Computing in Small 

Colleges , Proceedings of the fifth annual CCSC northeastern conference on The journal 

of computing in small colleges, Volume 15, Issue 5, 2000 

- Richard L. Wexelblat, ” The consequences of one’s first programming language“, Proceedings 

of the 3rd ACM SIGSMALL symposium and the first SIGPC symposium on Small 

systems, 1980 

- Douglas Bell, ” Visual Basic.Net as a First Language: An Evaluation“, ACM SIGCSE 

Bulletin, Volume 34, Issue 4, 2002

Paradigmer i Programmering - akira.ruc.dk

You also want an ePaper? Increase the reach of your titles

Delete template?

Save as template?