Få de daglige nyheder fra Version2 og Ingeniøren. Læs mere om nyhedsbrevene her.

close
Ved at tilmelde dig accepterer du vores Brugerbetingelser, og du accepterer, at Teknologiens Mediehus og IDA-gruppen lejlighedsvis kan kontakte dig om arrangementer, analyser, nyheder, job og tilbud m.m. via telefon og e-mail. I nyhedsbreve, e-mails fra Teknologiens Mediehus kan der forefindes markedsføring fra samarbejdspartnere.
Flerekeyboard_arrow_right
forskningsingeniøren bloghoved

Hurtig akademikerkode - og så videre...

Af 20

For et stykke tid siden snakkede jeg med en kollega, hvis arbejde ligesom mit er baseret på teori og beregninger. Han fortalte, at han ofte, når han er midt i processen med at skrive kode til at simulere de systemer, han arbejder med, forfalder til ad-hoc løsninger i koden, efterhånden som problemstillingen udvikler sig.

En hurtig if-sætning her, en hurtig for-løkke der. Løsninger, som lige nu gør det ønskede, og som derved leder til de data og resultater, han er ude efter. Men som rent kodemæssigt ikke er hensigtsmæssigt. Alt dette i håbet om, at han aldrig skal bruge koden igen, når resultaterne er opnået, data behandlet og analyseret, og arbejdet udgivet. Kort og godt: Hurtig akademikerkode.

Illustration: Privatfoto

("Piled Higher and Deeper" by Jorge Cham, www.phdcomics.com)

Jeg kender godt selv følelsen, at det bare er nemmere - lige nu - med en hurtig løsning. Men man opbygger på denne måde "gæld" i sin kode, og på sigt bliver den typisk sværere at udvide og ændre - og at læse og forstå, når man senere kigger på detaljerne.

Nogle få ildsjæle skriver og udgiver open source kodepakker til gavn for andre forskere, men i de fleste tilfælde - i hvert fald i det akademiske - skriver man koden til sig selv og ingen andre. Dette kan til dels forklare hurtige løsninger, men koden bliver således nemt en smule indforstået. Selvom jeg altid forsøger at skrive grundige kommentarer overalt i min kode, falder jeg jævnligt over steder, som hverken er kodet eller kommenteret optimalt.

I mit ph.d. projekt udvikler arbejdet sig i sagens natur løbende, og jeg har ugentligt behov for at ændre større eller mindre dele af den Matlab kodepakke, jeg udvikler og laver analyser med. Det er grundlæggende ingen undskyldning, men i processen, hvor vi tester forskellige idéer, strukturer og teorier - hvilket alt sammen foregår ved at ændre forskellige dele af koden - forfalder jeg ofte til at lave ændringerne hurtigt og specielt uden at kommentere dette grundigt. Mentalt noterer jeg mig dette, og med jævne mellemrum dedikerer jeg tid til at rydde koden op - til at tilbagebetale "gælden".

Som med debugging handler det om at tage sig tid til at skrive ordentlig og robust kode. Men når man som mig ikke er softwareingeniør, men fysiker er det mest interessante ikke selve koden, men de resultater og analyser, den kan producere. Og så er det bare sjovere at få resultaterne lige nu!

Retfærdigvis skal det siges, at jeg - og forhåbentlig mange andre - investerer en del tid i at gennemtænke den kode, vi udvikler. I slutningen af sidste år opstod der et væsentligt problem i mine beregninger, og jeg brugte i den forbindelse en del tid på at forbedre og optimere min kode. Jeg skal snart i gang med at udvikle ny kode til endnu mere krævende beregninger af tredimensionelle strukturer, og her skal der træffes mange "gode kodebeslutninger".

Koden skal dog langt hen ad vejen kun betjenes af mig selv - så jeg håber ikke, at jeg forfalder til hurtig akademikerkode.

Emner : Software
Forskningsingeniøren
Jakob Rosenkrantz de Lasson er civilingeniør og ph.d. i nanofotonik fra DTU. Jakob arbejder som Product Lead og forskningsingeniør hos virksomheden TICRA i København og blogger om forskning, fotonik og rumteknologi. Jakobs blog har tidligere heddet DTU Indefra (2012-2016) og DTU Studenten (2012)
Flere indlæg fra Forskningsingeniøren
Mest læste
1

Trafikstyrelsen: Amerikansk flyvetilladelse får ikke 737 Max på vingerne i Danmark

Plus.
3 Kommentarer
2

Midtjyder vil lægge skinner til Danmarks første batteritog

48 Kommentarer
3

Efter lufthavnssag: Chikanesager mod ingeniører er sjældne

19 Kommentarer
Forsiden lige nu

Molekylesvamp suger vand ud af tør ørkenluft

Molekylesvamp suger vand ud af tør ørkenluft

Grundfos-direktør: Der er mange ligheder mellem os og musikere

Spørg Fagfolket: Hvad sker der konkret i cellerne, når UV-lys rammer huden?

Trafikstyrelsen: Amerikansk flyvetilladelse får ikke 737 Max på vingerne i Danmark

GRAFIK: Elektronisk 'snorkel' lader søbunden ånde

Ugens debat: Aarhus Letbane kan gøre det svært for busserne

Nyt materiale sætter ny rekord for sort: Forskere tester farven på million-dyr diamant

Flere nyheder
andre skriver| også værd at læse
via TV2 Nyhederne 13. sep 2019 15:09
Metrotog afsporer - spor spærret
via Børsen 13. sep 2019 08:50
Teleselskaber øger investeringer i 5G og fiber
via Jyllands-posten.dk 13. sep 2019 07:55
Spildt kaffe tvang fly med 337 passagerer til nødlanding
via DR 13. sep 2019 07:37 16
Storbyborgmestre: Gamle dieselbiler skal forbydes i bymidterne
via Bloomberg 12. sep 2019 07:53 4
Boeing: 737 Max skal i luften igen
via TV 2 12. sep 2019 07:34
Nyt missil om bord på krigsskibe i det sydkinesiske hav
Se hele overblikket >
sortSortér kommentarer
  • Ældste først
  • Nyeste først
  • Bedste først

I mit ph.d. projekt udvikler arbejdet sig i sagens natur løbende, og jeg har ugentligt behov for at ændre større eller mindre dele af den Matlab kodepakke, jeg udvikler og laver analyser med.

Måske du skulle overveje et seriøst programmeringssprog. Matlab er hat og briller. Hvad skriver man Linuxkernen i? C. Hvad skiver man Windows NT kernen i? C. Hvad skriver man (Libre-)Office i? C. Og så bliver der brugt C++, Delphi, Pascal og diverse til alle mulige diverse applikationer. Selv Cobol lever fint fordi der findes 30+ år programmer der er brug for at holde liv i på mainframes. Og hvis man levere til forsvaret skriver man i ADA.

Men Matlab er dybt irrelevant.

  • 2
  • 10

Matlab er et programmeringsmiljø, en IDE, særligt designet til implementation af numeriske algoritmer og matematiske modeller. Der er stort set alt af funktioner og algoritmer inden for alle områder af ingeniørvidenskaberne, fysikken og anvendt matematik. Derudover er der en masse test, simulation, grafik, GUI og dokumentationsværktøjer. Man kan skrive c++ i Matlab og man kan blande Matlabkode og c++. Fremgangsmåden er typisk, at man laver sit tekniske arbejde i Matlabsprog, hvorefter man skriver det i c++, hvis det er planen, der skal en exe ud af det, fordi c++ er et general purpose language og ikke velegnet til at lave disse ting i.

  • 3
  • 0

Man skal nok være forsigtig med at undervurdere kvaliteterne i MatLab - og mindst lige så forsigtig med, hvad man bruger den kode systemet kan generere til. MatLab er ikke Comal 80 om igen, bare fordi hvert enkelt udtryk kan indtastes og udføres med det samme i editoren.

Hvad er god kode?

Det afhænger primært af, hvem der skal bruge koden, til hvad og hvor tit. Det er vel klart.

Mindre klart hvornår ad hoc ikke er godt nok. Hvis 100 mennesker må sendes hjem i 3 dage, mens man genstarter den industrielle proces, som standser, når ens program crasher, så er ad hoc klart ikke godt nok.

Hvis det tager lang tid at udføre de konkrete eksperimenter med det program man har udviklet, så bør man nok lige regne på det, for at se om det nu også det ægte hårde liv eller bare suboptimal kode- og datastruktur, som spiller ind.

  • 2
  • 0

Matlab er et meget yndet sprog at bruge på DTU ... og bruges i en række fag, og til nogle ting er det virkeligt effektivt: Der er en række special funktioner til f.eks. matrix algebra, og de er godt implementeret. Hvis man kan bruge nogle af de specielt implementerede funktioner, kan koden
godt være effektiv, selv hvis den er implementeret i Matlab.

  • 0
  • 0

Jeg kan anbefale at tage et kig på denne:
http://www.plosbiology.org/article/info%3A...

For mig og en god del af mine kollegaer har Python erstattet vores behov for Matlab. Nu er det ved at være nogle år siden at jeg var inkarneret Matlab bruger, så jeg ved ikke hvordan det har udviklet sig de sidste ca. 3 - 4 år. Men muligheden for at skrive læsbar, genbrugelig og testbar kode er IMHO meget bedre i Python. Med pakkerne numpy, scipy, matplotlib og pandas ville jeg aldrig gå tilbage til Matlab. Desuden er adgang til database værktøjer, GUI (qt), web etc. kun et enkelt modul væk. En stor grund til jeg forløb Matlab var nu også de hæftige priser man skal betale for at få et par enkelt toolboxes med, og betaling for vedligehold af licenser etc. når man ikke befinder sig på universitetet mere.
Jeg kan give bogen her en varm anbefaling hvis der er nogen der har lyst til at gå fra Matlab til Python:

http://shop.oreilly.com/product/0636920023...

  • 2
  • 0

Jeg er softwareingeniør, og jeg har det dårligt med at aflevere kode, hvor der ikke er god dokumentation og ingen eller få tests.

Årsagen er at når (ikke hvis) der kommer ændringer, så er det nemt at køre alle tests, og se at koden stadig virker.
Der hvor tests fejler kan man nemt se i testkoden hvad der er det ønskede resultat, og så rette det så testen går godt igen.

En anden ting er at tests egentlig også er en del af dokumentationen.
Kan man ikke lige huske hvad en bestemt funktion gør et 1/2 år senere, så kan man kigge på test koden, og så på den måde gennemskue hvad funktionen gør.

Der er også det der kaldes "code coverage" - som er en måling af hvor godt koden er testet.
http://en.wikipedia.org/wiki/Code_coverage

Programmeringssprog
Et programmeringssprog er kun et værktøj, og nogle værktøjer er bedre til en ting, end et andet værktøj.

Jeg bruger ofte Go programmeringssproget: http://golang.org lige nu. Go's go værktøj kan ud over at oversætte kode, hente pakkeafhængigheder repositories rekursivt, memory/tids performance analyse der vises som pæne grafer, også afvikle tests og lave coverage analyse på tests.
Coverage kommer gratis, når man har skrevet alle tests.

C bruger jeg kun til kerne kode, og embedded systems/indlejrede systemer, som ikke har et styresystem.
C++ bruger jeg helst ikke - da der efter min mening er for mange måder at skyde sig selv i foden på.

/Lars

  • 1
  • 0

En god del af min tid i FreeBSD kernen blev brugt på "phd-ware" :-)

Min anbefaling er at opfatte phd-ware som prototyper og følge Frederick P. Brooks vise ord: Smid det væk og start forfra, med den viden der blev vundet.

  • 4
  • 0

Måske du skulle overveje et seriøst programmeringssprog. Matlab er hat og briller. Hvad skriver man Linuxkernen i? C. Hvad skiver man Windows NT kernen i? C. Hvad skriver man (Libre-)Office i? C. Og så bliver der brugt C++, Delphi, Pascal og diverse til alle mulige diverse applikationer. Selv Cobol lever fint fordi der findes 30+ år programmer der er brug for at holde liv i på mainframes. Og hvis man levere til forsvaret skriver man i ADA.

Men Matlab er dybt irrelevant.

Brug det værktøj, der passer til opgaven. Eller bare det, der løser opgaven. Hvad du mener er et seriøst programmeringsprog, er dybt irrelevant.

  • 4
  • 0

Jeg kan anbefale at tage et kig på denne:
http://www.plosbiology.org/article/info%3A...

For mig og en god del af mine kollegaer har Python erstattet vores behov for Matlab. Nu er det ved at være nogle år siden at jeg var inkarneret Matlab bruger, så jeg ved ikke hvordan det har udviklet sig de sidste ca. 3 - 4 år. Men muligheden for at skrive læsbar, genbrugelig og testbar kode er IMHO meget bedre i Python. Med pakkerne numpy, scipy, matplotlib og pandas ville jeg aldrig gå tilbage til Matlab. Desuden er adgang til database værktøjer, GUI (qt), web etc. kun et enkelt modul væk. En stor grund til jeg forløb Matlab var nu også de hæftige priser man skal betale for at få et par enkelt toolboxes med, og betaling for vedligehold af licenser etc. når man ikke befinder sig på universitetet mere.
Jeg kan give bogen her en varm anbefaling hvis der er nogen der har lyst til at gå fra Matlab til Python:

http://shop.oreilly.com/product/0636920023...

Interessant indspark. Som jeg har omtalt i tidligere blogindlæg har jeg lært basal Python (http://ing.dk/blog/er-breaking-bad-big-dat...) og er begyndt at bruge det på iPad'en (http://ing.dk/blog/algebra-og-python-progr...), men i sidste ende har jeg valgt at holde fast i Matlab til arbejdet i mit ph.d. projekt.

Det er dog en god pointe, du påpeger mht. prisen af Matlab - hvilket man, når man er, hvor jeg er nu, ikke skænker en tanke, men som selvfølgelig i det lange løb gør Python endnu mere interessant.

Jeg vil dog også sige, at Matlab bare "spiller ud af boksen", som et kommercielt produkt selvfølgelig skal gøre. Jeg er ingen Python haj, men har oplevet nogle ting, som ikke lige virkede - og som timers søgning på Google heller ikke gav en løsning på.

  • 1
  • 0

http://www.johndcook.com/blog/2011/07/21/s...

Sjovt indlæg, som langt hen ad vejen slår hovedet på sømmet i forhold til de overvejelser, jeg selv har haft og har.

Hvor jeg er, værdsættes det, at det tager tid at skrive programmer, som kan simulere de systemer, vi arbejder med - men programmerne er, som blogindlægget ovenfor beskriver, værktøjer; de er i sig selv ikke et produkt.

Eftersom vi bruger lang tid på at udvikle dem, og at de er vigtige for vores arbejde, gør vi os naturligvis umage for at gøre dem "pæne", effektive, hurtige osv. Men det vil altid være sådan, at de er et middel til at nå målet - og det sætter i sagens natur nogle begrænsninger, i hvert fald fra en "rigtig" programmørs synspunkt.

  • 2
  • 0

Med den udbredte brug at software - hjemme syet eller ej - til at bedrive forsking er det i stigende grad et problem at brugen af dette software og de mange små 'ticks' i akademiske koder - "for lige at få det til at køre og skrevet endnu en artikel" - typisk er efterladt udokumenterede.

Der er i de beregningstunge videnskaber stort set ingen tradition for at dokumentere brug og ændringer i softwaren på en systematisk måde. Resultatet er at hvis man ser på en typisk artikel og beder forfatteren om at genskabe en graf eller et resultat, så vil det typisk være umuligt. Efter 3 år (en PhD generation) vil softwaren typisk værd utilgængelig og data forsvundet på en harddisk på en skrotten PC.

Med reproducerbarhed som et helt centralt begreb i moderne videnskab kan man så spørge sig selv om den slags forskning, baseret på udokumenterede brug og udvikling af akademisk software, egentlig er videnskab ?

Det er lidt alarmerende at en PhD studerende syntes at der et ok med akademiske koden da han jo blot bruger softwaren som et værktøj - netop fordi det er videnskab burde fokus på reproduserbarhed være i højsædet.

De beregningstunge videnskaber er langt bagefter de eksperimentielle videnskaben på det område - og hvis vi ikke skal spilde enorme resourcer på en masse 'one-off' beregninger så er det nok værd at tænke over hvordan den ny generation af forskere uddannes til at tænke over det.

PS - og det er i forbindelse naturligvist fuldstændig uden betydning hvilket programmerings sprog der bruges - brug hvad der passer til problemet som andre også har nævnt.

  • 1
  • 0

Det værste sløseri fra min side er, hvis jeg lige skal prøve en ide af og kopierer noget kode fra et andet sted, retter det til og så er der pludselig to steder koden skal vedligeholdes. Når dette alligevel forekommer skyldes det at jeg til at starte med ikke ved om den nye ide overlever på sigt. Der er jo ikke nogen grund til at implementere "smart" dobbelt-funktion det første sted i koden, hvis ideen senere dør og man bare får en ubrugt feature i koden.

P.S. Det mest nærliggende frie og gratis alternativ til Matlab er Scilab. Jeg kigger også på Python (iPython, PyLab...) en gang imellem, men er ikke blevet lun på det endnu. Scilab har:

  1. Omtrent samme hastighed som Matlab
  2. IDE som Matlab
  3. Model baseret design (aka Simulink)
  • 0
  • 0

Med den udbredte brug at software - hjemme syet eller ej - til at bedrive forsking er det i stigende grad et problem at brugen af dette software og de mange små 'ticks' i akademiske koder - "for lige at få det til at køre og skrevet endnu en artikel" - typisk er efterladt udokumenterede.

Der er i de beregningstunge videnskaber stort set ingen tradition for at dokumentere brug og ændringer i softwaren på en systematisk måde. Resultatet er at hvis man ser på en typisk artikel og beder forfatteren om at genskabe en graf eller et resultat, så vil det typisk være umuligt. Efter 3 år (en PhD generation) vil softwaren typisk værd utilgængelig og data forsvundet på en harddisk på en skrotten PC.

Med reproducerbarhed som et helt centralt begreb i moderne videnskab kan man så spørge sig selv om den slags forskning, baseret på udokumenterede brug og udvikling af akademisk software, egentlig er videnskab ?

Det er nogle interessante og vigtige pointer, du betoner. Reproducerbarhed er, som du nævner, centralt inden for forskning, og det er problematisk, hvis forfattere ikke selv kan reproducere egne resultater - for så kan andre med stor sandsynlighed slet ikke reproducere dem!

For mit eget projekts vedkommende håber jeg, at der vil være interesse for og ressourcer til, at andre kan overtage den kode, jeg udvikler. Pt. er jeg den eneste, som benytter koden, og jeg dokumenterer løbende udvidelser og ændringer i koden (som del af mine arbejdsnoter; http://www.jakobrdl.dk/blog/the-art-of-wri...). Hvis andre senere skal overtage den, vil jeg absolut gør en indsats for, at den er tilgængelig, forståelig og veldokumenteret.

Det er lidt alarmerende at en PhD studerende syntes at der et ok med akademiske koden da han jo blot bruger softwaren som et værktøj - netop fordi det er videnskab burde fokus på reproduserbarhed være i højsædet.

Men hvad er min kode udover at være et værktøj? Jeg er ikke programmør, men fysiker; computerkode er, hvor jeg er, et (vigtigt) værktøj til at forstå komplicerede fysiske systemer. Det betyder ikke, at vi ikke tager kode og kodeudvikling alvorligt, men hvad vil du kalde min kode udover et værktøj?

Derudover extrapolerer du en smule på, hvad jeg har givet udtryk for; hvem siger, at jeg ikke har fokus på reproducerbarhed? Som forklaret ovenfor dokumenterer jeg løbende ændringer og udvidelser i min kode, og specielt sikrer jeg mig, at resultater, som skal være de samme før og efter en ændring, rent faktisk er dette.

  • 0
  • 0

Det værste sløseri fra min side er, hvis jeg lige skal prøve en ide af og kopierer noget kode fra et andet sted, retter det til og så er der pludselig to steder koden skal vedligeholdes. Når dette alligevel forekommer skyldes det at jeg til at starte med ikke ved om den nye ide overlever på sigt. Der er jo ikke nogen grund til at implementere "smart" dobbelt-funktion det første sted i koden, hvis ideen senere dør og man bare får en ubrugt feature i koden.

Jeg kender følelsen, men hvad er løsningen? Jeg tester løbende en hel masse ting - både egne og mine vejlederes idéer - hvilket, som du beskriver, ofte foregår ved nogle hurtige tilføjelser og ændringer i koden. Eftersom vi ikke på forhånd kender svaret og ved, om idéen er interessant, er det svært at vide, om denne del skal implementeres "rigtigt" eller "hurtigt".

Når noget bliver en central del af min kode, sikrer jeg mig, at den er "rigtigt" integreret og dokumenteret i koden - men der er i de fleste tilfælde en mellemfase, hvor koden - og min forståelse af det, koden skal gøre - er i udvikling, og hvor det for mig er svært at gøre det "rigtigt".

Hvis jeg kendte alle svarene på forhånd, ville det være nemt at skrive koden "rigtigt" - og uendelig ligegyldigt at gøre det:-)

  • 0
  • 0

>Jeg kender følelsen, men hvad er løsningen?

Jeg har ingen bedre løsning, da jeg ikke har tid til at fluekneppe indtil kildekoden ser pæn, ryddelig og læselig ud. Det bliver til oprydning bagefter, når kode-stumpen er bragt til at virke og efterfølgende har bevist at den overlevede. Desværre må vi nok leve med "akademiker-kode".

  • 0
  • 0

Alle kender matlab og simulink.
Jeg har aldrig hørt om C og C++.

Fysikere bruger matlab, simulink, vhdl, Python og Java i nogle tilfælde.

  • 0
  • 0
Vis alle ( 20 )
Bidrag med din viden – log ind og deltag i debatten