Mitt første møte med programmering, var under militærtjenesten i 1970.
Jeg gikk 3 måneder på rekruttskole i Trandum leir. Vi fikk tilbud om noen fritidsaktiviteter vi kunne melde oss på. Og et av tilbudene var et kurs i programmering.
En student fra Universitetet på Blindern kom til Trandum en kveld hver uke for å lære oss å programmere i FORTRAN. Han tegnet på flipover, og vi noterte på papir. Hver gang ga han oss en oppgave vi skulle prøve å programmere. Vi skrev løsningen vår ned på papir, og leverte dette til studenten.
«På Blindern punchet han det vi hadde skrevet på hullkort, og leste hullkortene på stormaskinens kortleser.»
På Blindern punchet han det vi hadde skrevet på hullkort, og leste hullkortene på stormaskinens kortleser. Resultatet havnet på printeren, på store ark med traktorframtrekk. Disse arkene tok han med tilbake til oss på Trandum neste uke.
Vi hadde fått kompileringsfeil. Og vi så raskt at vi hadde et par rene skrivefeil, som vi rettet opp. Deretter gikk vi løs på denne ukens oppgave som studenten fikk med seg. Denne gangen var vi ekstra nøye med å lese korrektur.
Også neste uke hadde vi kompileringsfeil i begge programmene. Men denne gangen var det ikke rene skrivefeil, men ulovlig bruk av programmeringsspråket. Feilene ble rettet og en ny oppgave ble programmert.
Etter 3 uker fikk vi endelig tilbake et program som hadde kompilert uten feil. Men denne gangen fikk vi meldingen «Run time error» med en kryptisk kode etter seg. Studenten kunne fortelle oss at årsaken var at vi hadde programmert en evig løkke. Han hjalp oss med å rette dette.
Og endelig, etter 4 uker, kom studenten tilbake med en listing som viste en vellykket kjøring. Vi hadde laget vårt første dataprogram som virket. Det feiret vi med å bruke hele dagslønna på en flaske Cola.
Slik fungerte programmeringsspråket jeg skulle ende opp med å bruke i mange år framover:
GO TO
Programlinjene utføres sekvensielt. Men ved å legge inn labeler, er det mulig hoppe framover eller bakover i koden ved å bruke GO TO . GO TO ble gjerne brukt i forbindelse med IF-tester, men kunne også brukes til å konstruere løkker.
Hver programmerer gjorde dette på sin måte, og noen var svært kreative med sin bruk av GO TO. Mye bruk av GO TO reduserte lesbarheten til programmet, og gjorde det vanskelig for andre å vedlikeholde det. Når man skulle skynde seg med å gjøre en rettelse i et program, og det var en sekvens man ikke forsto, lot man gjerne den gamle koden stå og brukte GO TO for å hoppe forbi den.
GO TO ble mye brukt, og mye misbrukt. Vi fikk begrepet «spagetti programmering».
Det fantes en spesialvariant av GO TO som ble kalt «Computed GO TO». Her brukte du en variabel til å styre hvilken label du skulle hoppe til. En skummel sak som det ble advart mot å bruke. Selv brukte jeg «Computed GO TO» en gang under programmering av Postens Skrankesystem. De hadde ca 100 fortløpende nummererte transaksjonstyper, hvor jeg på denne måten kunne switche til aktuell behandling.
Se hvordan data endra Norge på 80-tallet
DO-løkker
Dette var FORTRANs teknikk for å konstruere løkker. En typisk løkke kunne se slik at:
DO 20 I = 1,100,1
<Statements>
20 CONTINUE
Denne løkka styres av heltalls variabelen I som løper gjennom alle verdiene fra 1 til 100.
Noen ganger oppstår en situasjon der du ønsker å gå ut av løkka før I har løpt gjennom alle verdiene. Da kan du hoppe ut av løkka med GO TO. Når du gjør det, har du ikke kontroll på de variable som oppdateres i løkka. Og her er vi mange programmere som har fått en ubehagelig opplevelse.
IF-tester
I FORTRAN 66 (FORTRAN 4) var det kun helt enkle IF-tester:
IF <Logisk uttrykk><et enkelt statement>
Dette medførte at man gjerne testet på unntakene først, slik at man kunne bruke GO TO til å hoppe over den etterfølgende behandlingen. Når en annen person leste programmet, kom unntakene fort i fokus, mens hovedstrukturen i programmet kom litt i bakgrunnen.
«Når en annen person leste programmet, kom unntakene fort i fokus.»
I FORTRAN 77 (FORTRAN 5) hadde man lært av de blokk-strukturerte programmeringsspråkene, og innførte IF – THEN – ELSE strukturer:
IF <Logisk uttrykk> THEN
<Statements>
ELSE IF <Logisk uttrykk> THEN
<Statements>
ELSE
<Statements>
END IF
Subrutiner og funksjoner
Når man ble litt mer rutinert som programmerer, brukte man gjerne subrutiner til å strukturere programmene sine. Hovedprogrammet ble ofte kun en samling av kall til subrutiner. Hvis man valgte gode navn på subrutinene, var det lett å forstå hva programmet gjorde. Eksempelvis:
CALL INNLESNING
CALL BEREGNING
CALL UTSKRIFT
En funksjon var en slags «subrutine» som kun returnerte en verdi.
Både subrutiner og funksjoner kunne ha parameteroverføring.
Norske Kodémus spådde smartmobiler i 1968
Autokon Data
FORTRAN og COBOL var de dominerende programmeringsspråkene gjennom lang tid. FORTRAN ble i hovedsak brukt innenfor tekniske miljøer, mens COBOL i hovedsak ble brukt til administrativ databehandling.
Jeg har brukt FORTRAN i flere sammenhenger, men vil spesielt trekke fram den jobben jeg gjorde hos Autokon Data. Autokon var et norskutviklet CAD/CAM (Computer Assisted Design and Manufactoring) system for skipskonstruksjon. Autokon ble brukt av de fleste store norske skipsverftene, samt flere skipsverft rundt om i verden. FORTRAN 66 er brukt som programmeringsspråk. Dessverre gikk firmaet konkurs midt på 80-talllet da det var nedgangstider i verftsindustrien.
Opplæringen besto i at jeg fikk navnet på en subrutine som jeg skal sette meg inn. Jeg skulle først forstå hvordan subrutinen virket, deretter skulle jeg legge inn noe ny funksjonalitet.
«Først skrev jeg subrutinen ut på papir. Ved første øyekast så det oversiktlig og greit ut.»
Først skrev jeg subrutinen ut på papir. Ved første øyekast så det oversiktlig og greit ut, programmet fikk plass på en snau side. Men så oppdaget jeg at denne siden hovedsakelig besto av kall til andre subrutiner. Neste skritt var da å skrive ut disse, som selvfølgelig også hadde kall til nye subrutiner. Og sånn fortsatte det.
Heldigvis fikk jeg støtte av en veteran. Han startet med å vise meg noen helt grunnleggende subrutiner. Konstruksjon av skip består av 3-dimensjonal geometri, og det ble benyttet både globalt og lokale koordinatsystemer. Konvertering mellom forskjellige koordinatsystemer var ofte nødvendig, og dette var det laget subrutiner for. Det var nødvendig å lære seg hva disse subrutine het, og hva de gjorde. Deretter kunne jeg gå et nivå opp, og bli kjent med viktige subrutiner som brukte disse grunnpilarene.
I denne settingen var det dødfødt å prøve seg på en top-down tilnærming slik jeg gjorde. Bottom-up tilnærming fungerte mye bedre. Etter noen uker skjønte jeg endelig hvordan subrutinen min fungerte, og jeg kunne starte arbeidet med å legge inn den nye funksjonaliteten.
Slik var nettet i Norge, før internett
Teledata på Commodore 64, oppkobling fra telefonkiosker og databaser med nyheter.