Ett komplementerande läromaterial för datastudenter som lär sig fysik Läromaterialet Learn You a Physics for Great Good! Kandidatarbete inom Data- och informationsteknik Johan Johansson Oskar Lundström Erik Sjöström Björn Werner Institutionen för Data- och informationsteknik CHALMERS TEKNISKA HÖGSKOLA Göteborg, Sverige 2018 Kandidatarbete DATX02-18-08 Ett komplementerande läromaterial för datastudenter som lär sig fysik Läromaterialet Learn You a Physics for Great Good! Johan Johansson Oskar Lundström Erik Sjöström Björn Werner Institutionen för Data- och informationsteknik Avdelningen för funktionell programmering Chalmers tekniska högskola Göteborg, Sverige 2018 Ett komplementerande läromaterial för datastudenter som lär sig fysik Läromaterialet Learn You a Physics for Great Good! Johan Johansson Oskar Lundström Erik Sjöström Björn Werner © Johan Johansson, 2018. © Oskar Lundström, 2018. © Erik Sjöström, 2018. © Björn Werner, 2018. Handledare: Patrik Jansson, CSE, Chalmers Kandidatarbete DATX02-18-08 Institutionen för Data- och informationsteknik Avdelningen för funktionell programmering Chalmers tekniska högskola SE-412 96 Göteborg Telefon +46 31 772 1000 Omslag: Newton står och tänker på fritt fall i termer av Haskellkod och precis då får han ett lambda-äpple i huvudet. Bilden är ritad i samma stil som bilderna i läromaterialet. Typsatt i LATEX Göteborg, Sverige 2018 iv Abstract This report describes the development of the learning material Learn You a Physics for Great Good!. The material was developed as part of a bachelor thesis project at the Department of Computer Science and Engineering at Chalmers University of Technology. The goal of the project is to create a text-based learning material which presents physics with the help of the programming concept domain specific languages, where the domain specific languages are implemented in the programming language Haskell. Furthermore, the pedagogical use of a learning material of this kind and how well physics and domain specific languages can be combined are discussed. The background of the project is the (for Computer Science and Engineering students at Chalmers) mandatory physics course Fysik för ingenjörer which has had less-than-good exam statistics for several years. We believe one factor for why Computer Science and Engineering students get bad results in this course is that they find physics irrelevant in relation to the rest of their education. We think this problem can be solved with a learning material bridging physics and programming, both highlighting the relevancy of physics and invoking an interest for it. An increased interest will hopefully lead to better results in the course. The learning material includes five chapters dealing with physical dimensions, calculus, vectors, particle mechanics and applications of them. Each chapter consists of Haskell code combined with a descriptive text. Some chapters construct domain specific languages from the ground up, while some apply previously constructed domain specific languages on physical problems. The learning material is published on a website1 and its source code is freely available2. The report also describes the meetings and discussions conducted with non-project mem- bers. Their purpose has been to improve the learning material and to perform an informal evaluation of the completed learning material. The conclusions are that domain specific languages can have a pedagogical use in physics education. The rigorous nature of domain specific languages makes the process of physical problem solving rigorous as well. We believe this way of thinking can further the teaching if it’s used in traditional physics education. Keywords: Domain Specific Languages, Classical Mechanics, Physics Education, Learning Material, Functional Programming, Haskell 1https://dslsofmath.github.io/BScProj2018/ 2https://github.com/DSLsofMath/BScProj2018 v https://dslsofmath.github.io/BScProj2018/ https://github.com/DSLsofMath/BScProj2018 Sammanfattning Denna rapport beskriver utvecklingen av läromaterialet Learn You a Physics for Great Good!. Materialet utvecklades som ett kandidatarbete vid institutionen för Data- och informationsteknik på Chalmers tekniska högskola. Syftet med projektet är att skapa ett textbaserat läromaterial som presenterar fysik med hjälp av programmeringskonceptet domänspecifika språk, där de domänspecifika språken är implementerade i programme- ringsspråket Haskell. Vidare diskuteras den pedagogiska nyttan av ett läromaterial av detta slag samt hur väl fysik och domänspecifika språk går att kombinera. Bakgrunden till projektet är fysikkursen Fysik för ingenjörer. Kursen är obligatorisk för studenter på Datateknik (D) på Chalmers och har haft ganska dålig tentastatistik i flera år. Vi tror att en faktor till att just D-studenter får dåliga resultat i denna kurs är att studenterna finner ämnet irrelevant i förhållande till resten av utbildningen. Vi tror också att detta problem kan lösas med ett läromaterial som bryggar fysik och programmering, och både visar på relevansen av ämnet och väcker intresse för fysik. Ett ökat intresse för fysik leder förhoppningsvis till bättre resultat i kursen. Det resulterande läromaterialet innehåller fem kapitel som behandlar områdena fysikalis- ka dimensioner, matematisk analys, vektorer och partikelmekanik, och tillämpningar av dem. Varje kapitel består av Haskell-kod tillsammans med beskrivande text. Vissa kapitel bygger upp domänspecifika språk från grunden medan andra kombinerar och tillämpar tidigare domänspecifika språk på fysikaliska problem. Läromaterialet är publicerat på en hemsida3 och dess källkod finns fritt tillgänglig4. Rapporten beskriver även de möten och diskussioner som genomförts med utomstående. Syftet var att förbättra läromaterialet samt att genomföra en informellt test av läroma- terialet. Slutsatserna är att domänspecifika språk kan ha en pedagogisk nytta i fysikundervisning. Den rigorösa naturen hos Haskell och domänspecifika språk gör att den fysikproblem- lösningen de används för också blir rigorös, utan möjlighet till intuitiva men felaktiga genvägar. Detta tankesätt tror vi kan främja lärande om det integreras i traditionell fysikundervisning. Nyckelord: Domänspecifika språk, Klassisk mekanik, Fysikundervisning, Läromaterial, Funktionell programmering, Haskell 3https://dslsofmath.github.io/BScProj2018/ 4https://github.com/DSLsofMath/BScProj2018 vii https://dslsofmath.github.io/BScProj2018/ https://github.com/DSLsofMath/BScProj2018 Förord Denna rapport behandlar kandidatarbetet Matematikens domänspecifika språk, som ge- nomfördes på Chalmers tekniska högskola under vårterminen 2018. Vi som har utfört detta kandidatarbete är tre studenter från civilingenjörsprogrammet Datateknik vid Chal- mers tekniska högskola och en student från det datavetenskapliga programmet vid Göte- borgs universitet. Vi vill tacka Patrik Jansson, vår handledare, som med sina kloka tankar och goda råd agerat som ett fyrtorn när vi seglat på okända domänspecifika hav. Vi vill tacka Åke Fäldt som tagit sig tiden att diskutera sin egen kurs, vårt läromaterial och gett oss tips och råd under utvecklingen. Vi vill tacka de testare, både individer och grupper, som tagit sig tiden att studera och läsa igenom vårt, ibland halvfärdiga, material och gett oss den kritik vi behövt för att sporras till vidareutveckling. Vi vill tacka Jeff Chen vars tankar och idéer om potentiella vidareutvecklingar av projektet gav oss ett helt nytt perspektiv under arbetets gång. Slutligen vill vi tacka Miran Lipovača vars hemsida “Learn You a Haskell for Great Good!” har både inspirerat utformningen av vår hemsida och agerat som ett läromaterial för våra egna inledande studier av det fantastiska programmeringsspråket Haskell. Författarna, Göteborg, maj 2018. ix Innehåll Ordlista xiii 1 Introduktion 1 1.1 Bakgrund . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1 1.2 Projektets mål . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2 1.3 Avgränsningar . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 2 Teori 5 2.1 Domänspecifika språk . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 2.2 Syntax och semantik . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 2.3 Litterat programmering och Literate Haskell . . . . . . . . . . . . . . . . 7 2.4 Lärandeteorier . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 3 Genomförande 11 3.1 Konstruktion av läromaterialet . . . . . . . . . . . . . . . . . . . . . . . 11 3.1.1 Sökande efter områden att behandla . . . . . . . . . . . . . . . . 11 3.1.2 Implementation av domänspecifika språk för områdena . . . . . . 12 3.1.3 Skriva lärotext . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12 3.2 Möten och återkoppling . . . . . . . . . . . . . . . . . . . . . . . . . . . 13 4 Resultat 15 4.1 Läromaterialet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15 4.1.1 Översikt . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15 4.1.2 Dimensioner . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17 4.1.3 Matematisk analys . . . . . . . . . . . . . . . . . . . . . . . . . . 18 4.1.4 Vektorer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19 4.1.5 Exempelproblem . . . . . . . . . . . . . . . . . . . . . . . . . . . 20 4.1.6 Partikelmekanik . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21 4.2 Möten och återkoppling . . . . . . . . . . . . . . . . . . . . . . . . . . . 21 5 Diskussion 23 5.1 Genomförandediskussion . . . . . . . . . . . . . . . . . . . . . . . . . . . 23 5.2 Resultatdiskussion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24 5.2.1 Om läromaterialets fokus på matematik och Haskell snarare än fysik 25 5.2.2 Lämpliga områden för domänspecifika språk . . . . . . . . . . . . 26 5.2.3 Domänspecifika språk, fysik och pedagogiska aspekter . . . . . . . 27 5.3 Vidareutvecklingsmöjligheter och behov av ytterligare kunskap . . . . . . 28 5.4 Etiska aspekter . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29 xi Innehåll 6 Slutsatser 31 Bibliography 33 A Läromaterialet I xii Ordlista Datastudent En student med bakgrund inom data och IT. Dimensioner Syftar på fysikaliska dimensioner. DSL Förkortning av Domain Specific Language, engelska för domänspecifikt språk. DSLsofMath Förkortning av Domain Specific Languages of Mathematics, vilket är en valbar kurs i årskurs 2 på Chalmers tekniska högskola. Fysik för ingenjörer En fysikkurs som är obligatorisk för studenter på civilingenjörs- programmet Datateknik på Chalmers. Den ges i årskurs 2 och innehåller grunderna i klassisk mekanik, termodynamik och vågrörelselära. Literate Haskell Litterat programmering i Haskell. Se avsnitt 2.3 Läromaterialet Syftar på den pedagogiska text som projektet resulterat i. Semantik Vad meningar (skapade i en syntax) har för betydelse. Se avsnitt 2.2. Syntax Grammatiken för ett språk, som beskriver hur meningar konstrueras i det. Se avsnitt 2.2. Åke Fäldt Föreläsare och examinator i kursen Fysik för ingenjörer. xiii Ordlista xiv 1 Introduktion Detta kapitel beskriver projektets bakgrund, mål och avgränsningar. 1.1 Bakgrund På civilingenjörsprogrammet Datateknik på Chalmers tekniska högskola ingår den obli- gatoriska fysikkursen Fysik för ingenjörer. Tentastatistiken för denna kurs [1] är ganska dålig5. Vi tror att många studenter på Datateknik tycker att denna kurs är svår eller ointressant och att detta leder till att en betydande andel får underkänt. Detta tror vi kan lösas med avstamp från kursen Domain Specific Languages of Mat- hematics (“DSLsofMath”), med den svenska titeln Matematikens domänspecifika språk. Kursen är valbar på kandidatnivå för studenter på Chalmers och Göteborgs universitet. Konkret presenterar DSLsofMath matematik som derivator, komplexa tal och matriser ur ett programmeringsperspektiv i Haskell, vilket är ett programmeringsspråk datastu- denterna redan är bekanta med. DSLsofMath-kursens skapare, Cezar Ionescu och Patrik Jansson, har beskrivit avsikten med kursen i en artikel [2]. Det direkta målet med kursen är att förbättra den matematiska utbildningen för datavetare och den datavetenskapliga utbildningen för matematiker, där den grundläggande idén bakom kursen är: “[. . . ] att uppmuntra studenterna att närma sig matematiska domäner från ett funktionellt programmeringsperspektiv: att ge beräkningsbevis (calculational proofs); att vara uppmärksamma på syntaxen för matematiska uttryck; och, slutligen, att organisera de resulterande funktionerna och typerna i domänspecifika språk.” [2] Det programmeringsperspektiv som kursen använder sig av bottnar i så kallade domän- specifika språk. Kortfattat kan ett domänspecifikt språk beskrivas som ett programme- ringsspråk som skapats för ett väl avgränsat område. Detta område kan vara databashan- tering, algebraiska uttryck eller till och med fysik. Språket kan antingen vara implemen- terat inuti ett annat programmeringsspråk eller implementerat helt fristående. I kursen och projektet är de implementerade i Haskell. 5Andel underkända på ordinarie tentamen från läsår 2014 till 2017: 34%, 76%, 18%, 57%. 1 1. Introduktion Idén bakom projektet är att använda domänspecifika språk för att ur ett alternativt perspektiv presentera fysik. Likt det sätt DSLsofMath presenterar kopplingar mellan matematik och programmering ska projektet på motsvarande sätt visa på kopplingar mellan programmering och fysik och därmed underlätta lärandet. För att förtydliga ges här en analogi: Studenterna har svårt för matematik → DSLsofMath. Studenterna har svårt för fysik → Detta projekt. Detta projekt kan vara av intresse för studenter, pedagoger och föreläsare inom de berörda områdena eftersom projektet ger ett nytt perspektiv på fysik som inte bara är annorlunda utan också mer rigoröst. Förhoppningsvis blir det även relevant för de som är intresserade av domänspecifika språk i stort och kanske till och med för programledningen som kan se denna rapport som ett skäl att introducera innehåll av detta slag i fysikkurser. Angående tidigare forskning och studier har en kurs på MIT, inte helt olik DSLsofMath, tidigare givits som berör både fysik och domänspecifika språk. Classical Mechanics: A Computational Approach gavs av Gerald Sussman och Jack Wisdom senast år 2008 [3]. Denna kurs på avancerad nivå behandlar de fundamentala principerna för klassisk me- kanik med hjälp av beräkningsidéer för att precist formulera principerna av mekanik, med början i Lagranges ekvationer och avslut i perturbationsteori (teori för approxima- tioner av matematiska lösningar). I kursens bok [4] förklaras fysikaliska fenomen genom att visa datorprogram för att simulera dem, skrivna i språket Scheme. Denna typ av kurs är ovanlig och är, till projektgruppens kännedom, den enda kursen bortsett från DSLsofMath som knyter samman fysik, programmering och matematik på en symbolisk nivå för att förklara koncepten. Skillnaden mot vårt projekt är att vi använder Haskell istället för Scheme, enbart behandlar fysik från Fysik för ingenjörer samt gör det på en nivå anpassad för datastudenter på Chalmers. Även tidigare har det genomförts ett kandidatarbete på Chalmers med anknytning till DSLsofMath. Vårterminen 2016 genomfördes kandidatarbetet Programmering som un- dervisningsverktyg för Transformer, signaler och system. Utvecklingen av läromaterialet TSS med DSL av fem studenter från Datateknik och Teknisk Matematik på Chalmers [5]. Arbetet bestod av utveckling av läromaterial med tillhörande programmeringskod, upp- gifter och lösningar, som komplement till existerande kurser i signallära. Till sist finns det ett arbete som liknar detta arbete i både syfte och programmeringsspråk, vilket utfördes av Scott N. Walck vid Lebanon Valley College [6]. Syftet med det projektet var att fördjupa studenters förståelse av fysik, med fokus på elektromagnetisk teori, genom att uttrycka fysiken med hjälp av funktionell programmering. Skillnaden är att detta projekt ska förklara fysik från grunden. 1.2 Projektets mål Målet med detta kandidatarbete är att angripa fysik från ett programmeringsperspektiv, förhoppningen är då att fysik ska bli både roligare och intressantare för datastudenter, 2 1. Introduktion och därmed också enklare. Detta liknar premissen bakom kursen DSLsofMath och kandi- datarbetet från 2016, som istället för fysik behandlade matematik respektive signallära. Mer konkret ska det ovanstående målet uppnås genom att skapa ett läromaterial. Läro- materialet ska bestå av domänspecifika språk som modellerar fysik, skrivna i Haskell, sammanvävt med en förklarande lärotext. Läromaterialet ska vara enkelt för läsaren att ta till sig, vilket ska åstadkommas genom ett lättsamt språk, publicering på en hemsida samt fri tillgång till källkoden. Ett parallellt mål är att, efter att ha tillägnat sig erfarenhet, diskutera huruvida fysik och domänspecifika språk går att kombinera och om det finns en pedagogisk nytta i att göra det. 1.3 Avgränsningar Läromaterialet begränsas till att enbart hantera de fysikaliska områden som ingår i kursen Fysik för ingenjörer. Denna avgränsning valdes dels eftersom det är den fysik gruppmed- lemmarnas kunskaper är begränsad till, och dels för att det är denna kurs som projektet kan bli mest relevant för, eftersom kursen ingår i datastudenternas obligatoriska kursplan. Vidare ska en prioritering av innehållet i Fysik för ingenjörer göras. Kursen behandlar grunderna inom klassisk mekanik, termodynamik och vågrörelselära samt en stor mängd tillämpad matematik, exempelvis differentialkalkyl. I första hand behandlas mekaniken, för att sedan i mån av tid även behandla termodynamik och vågrörelselära eftersom det är i den ordningen kursen behandlar områdena. Fokuset läggs även på de områden datastudenter haft svårt för. För att pröva den pedagogiska nyttan kommer enbart en informell testning att göras. Detta då en rigorös undersökning hade krävt mycket tid för att välja lämpliga testgrupper, analysera återkopplingen samt dokumentera testningsförloppet. Denna tid läggs istället på att skapa ett intressant innehåll. Projektet fokuserar mer på att skapa innehåll än att göra efterforskningar på, och tilläm- pa, pedagogiska teorier och riktlinjer. Denna avgränsning valdes eftersom det är hur innehållet kan se ut som är intressant och nytt, inte hur ett pedagogiskt läromaterial kan skrivas på bästa sätt. Den pedagogiska aspekten kommer inte ignoreras helt, fokuset på den kommer bara att vara mindre. 3 1. Introduktion 4 2 Teori I detta kapitel beskrivs fyra koncept av central betydelse för projektet. Dessa koncept är domänspecifika språk, begreppen syntax och semantik, litterat programmering samt lärandeteorier. 2.1 Domänspecifika språk Ett domänspecifikt språk är ett språk som är avgränsat till en specifik domän. Nyckelor- den är språk, specifik och domän. En domän är ett område, till exempel textformatering eller matlagning. Specifikt syftar det på att det är just detta område som fokus läggs på. Med språk menas ett sätt att uttrycka saker inom domänen. Svenska och Java är två exempel på språk. Domänspecifika språk är vanligt förekommande i programmeringssam- manhang, HTML är ett domänspecifikt språk för textformatering, SQL för databashan- tering och CSV för tabeller. Domänspecifika språk används inte bara i programmering utan förekommer även i andra mer vardagliga sammanhang. Inom domänen matlagning är steka, grilla och fritera an- vändbara ord, likaså inom domänen ridning är grimma, box och galopp användbara ord. Är personen bekant med domänen vet den vad som menas med grimma och det är ett kort och väldefinierat sätt att uttrycka sig. Men detta språk (här i form av ord och begrepp) blir svårtolkat utanför domänen. Ett recept kan inte förklaras i termer av grimmor, boxar och galopper. Precis som domänspecifika språk i vardagen passar domänspecifika språk inom programmering bäst för sin egen domän. SQL är bra för att hantera en databas men inte för att skapa ett spel. Motsatsen till ett domänspecifikt språk är ett generellt språk. I vardagen är naturliga språk som svenska och engelska generella medan ryttarbegreppen ovan är domänspecifika. Precis som i vardagen finns det i datavärlden generella programmeringsspråk, till exempel C++ och Java. Dessa språk har inte en specifik domän utan kan användas till flera olika, Java kan till exempel användas till både databaser och spel. Nackdelen med dessa generella språk är just att de är så generella. Eftersom domänspecifika språk inte behöver vara användbara utanför den specifika domänen kan de inkludera specifik syntax och ha en inbyggd funktionalitet som inte hade passat i ett generellt språk. 5 2. Teori Ett domänspecifikt språk kan antingen implementeras som ett fristående språk eller bäd- das in i ett redan existerande språk. De domänspecifika språk som utvecklats inom detta projekt är inbäddade i programmeringsspråket Haskell. Haskell är ett lämpligt val ef- tersom det är enkelt att skapa datatyper som bygger upp det domänspecifika språket. Att Haskell är ett högnivåspråk är också en fördel då programmeraren slipper program- meringstekniska detaljer som minneshantering och kan istället fokusera på programmets innehåll och betydelse. Slutligen möjliggör mönstermatchning att de konstruktorer som bygger upp datatyperna i det domänspecifika språket enkelt kan brytas isär och manipu- leras. För vidare läsning om domänspecifika språk rekommenderas DSL for the Uninitiated [7]. 2.2 Syntax och semantik I samband med domänspecifika språk dyker begreppen syntax och semantik upp. Syntax är reglerna för hur enheter i språket, till exempel ord och skiljetecken, sammanslås till komplexa strukturer som meningar och satser. Semantiken är betydelsen av sådana kom- plexa strukturer i ett språk. Inom aritmetik6 är tal och operationer syntax medan värdet av uttrycket är semantiken. Till exempel har det syntaktiska uttrycket 7 ∗ (3 + 10) det semantiska värdet 91, eftersom det är det som det syntaktiska uttrycket betyder. Domän- specifika språk har med syntax att göra eftersom många domänspecifika språk används för att modellera just syntax. För att illustrera visas här ett domänspecifikt språk i Haskell som modellerar en del av syntaxen för aritmetiska uttryck. data Expr = Expr :+: Expr | Expr :*: Expr | Const Double Typen innehåller datakonstruktorer för att representera ändpunkter och förgreningar. I detta exempel är :+: och :*: förgreningar. Med hjälp av dem kan summan respektive produkten av två andra uttryck representeras. Ändpunkterna representeras av Const. Med hjälp av datakonstruktorerna ovan kan aritmetiska uttryck konstrueras. Till exempel kan 7 ∗ (3 + 10) modelleras som expr = Const 7 :*: (Const 3 :+: Const 10) Konstruktorn :*: får som sina två argument uttrycken Const 7 och Const 3 :+: Const 10. Det är alltså en produkt av två deluttryck. Ett syntaktiskt uttryck kan visualiseras med ett träddiagram, ibland kallat syntaxträd. Exempeluttrycket ovan illustreras i figur 2.1. För att beräkna semantiken hos ett syntaktiskt uttryck representerat i Haskell används en 6Aritmetik är den gren inom matematiken som behandlar räkning av tal. 6 2. Teori Figur 2.1: Ett exempeluttryck från synatxen Expr visualiserat i ett träddiagram. beräkningsfunktion. I fallet med aritmetiska uttryck är semantiken ett numeriskt värde. För Expr kan beräkningsfunktionen se ut som evaluate :: Expr -> Double evaluate (e1 :+: e2) = evaluate e1 + evaluate e2 evaluate (e1 :*: e2) = evaluate e1 * evaluate e2 evaluate (Const v) = v Det finns tre speciella saker att observera. Den första är att eftersom syntaxen innehåller tre olika sorters element, här motsvarat av de tre datakonstruktorerna, används tre fall i funktionen evaluate som beräknar vardera av dem. Den har därför ett fall för :+:, ett för :*: och ett för Const. Den andra saken att notera är hur ett fall implementeras. Här är e1 :+: e2 syntax för addition av de två uttrycken e1 och e2. Semantiken av detta är inom aritmetik definerad som summan av värdena hos de två deluttrycken. Implementationen av detta fall ska därför vara evaluate e1 + evaluate e2. Ett liknande resonemang ger svaret på hur beräkningen av de två resterande fallen ska se ut. Den tredje saken värd att poängtera är beräkningsfunktionens typsignatur, Expr -> Double. Den gör nämligen att evaluate, och beräkningsfunktioner i allmänhet, kan tol- kas som en översättning från syntax (här Expr) till semantik (här Double). 2.3 Litterat programmering och Literate Haskell Litterat programmering (engelska literate programming) är ett alternativt sätt att pro- grammera som introducerades av Donald Knuth [8]. Istället för att skriva ett program främst för datorer att exekvera, så skrivs programmet främst för människor att läsa. Jämfört med traditionella program får dokumentationen en ökad betydelse. I traditionella 7 2. Teori program är programkoden den viktiga delen. I litterata program är däremot dokumen- tationen minst lika viktig. Den används för att förklara koden, sätta den i relation till andra delar, med mera. Detta jämnbördiga förhållande syns konkret genom att titta på hur källkoden är skriven i ett litterat program. Det kan till exempel se ut som i figur 2.2 där källkoden och dokumentationen är sammanvävda på ett jämnbördigt sätt, där den ena inte är viktigare än den andra. How does all this tie together ? First the type is decided , for instance > type ExampleType = Quantity T.Length Double then a value of that type is created > exampleValue :: ExampleType > exampleValue = Quantity V.length 5.3 Note that the Quantity data type has both value -level and type -level dimensions . As previosuly mentioned , value - level in order to pretty print and type -level to only permit legal operations . Figur 2.2: Ett exempel på hur en källfil till litterat programmering kan se ut, tagen direkt från källkoden till läromaterialet. I exemplet är koden skriven i Literate Haskell. Rader som börjar med > markerar att det är programkod, medan rader utan markerar att det är dokumentation. Literate Haskell är litterat programmering för Haskell [9]. Att programmera i Literate Haskell går till på samma sätt som vanlig Haskell, med skillnaden att programkod och text vävs ihop i en och samma fil. Det kan se ut som i figur 2.2. Filen, med tillägget .lhs, går att använda direkt med Haskell-kompilatorn GHC. All text ignoreras och programkoden behandlas som om den var en vanlig Haskell-fil. Filen kan också kompileras till en läsbar typsatt rapport eller hemsida. Det som används i detta projekt är Pandoc [10]. Med Pandoc kan texten märkas upp med både Markdown (används i projektet) och LATEX. Det går att exportera till bland annat HTML (som i läromaterialet) och PDF (som i den här rapporten). 2.4 Lärandeteorier I detta projekt är lärandeteorier om motivation, lärande i grupp, interaktion och snabba belöningar relevanta. Motivation är en persons vilja att göra något och i undervisningssammanhang vill läraren eller författaren att studenten ska lära sig materialet, studenten behöver alltså vara mo- tiverad för att lära sig. Motivation kan ha flera källor, till exempel att studenten tycker materialet är intressant eller att det finns belöningar i form av tillfredsställelsen från ett högt betyg. 8 2. Teori Motiverande design innebär att systematiskt utforma undervisningen på ett sådant sätt att studenten blir motiverad till att lära sig. Det handlar om att använda olika tekniker för att väcka och behålla motivation. För detta finns det ett flertal olika modeller men i detta projekt används enbart den så kallade ARCS-modellen [11]. ARCS är en förkortning av “Attention, Relevance, Confidence and Satisfaction”, på svens- ka “uppmärksamhet, relevans, självförtroende och tillfredsställelse”. Precis som namnet antyder innehåller modellen fyra delar som vardera behandlar en aspekt av motivation. • Attention handlar om att fånga uppmärksamhet och väcka nyfikenhet. • Relevance handlar om att tillgodose studentens behov så att materialet upplevs som relevant. • Confidence handlar om att övertyga studenten att hen kan lyckas lära sig materialet. • Satisfaction handlar om att ge studenten tillfredsställelse efter att ha lärt sig något så att hen vill fortsätta lära sig. Det finns olika strategier för hur de olika delarna genomförs i praktiken, här följer en översikt för Attention7. För att fånga studentens uppmärksamhet och intresse finns tre allmänna strategier. Den första är varseblivning, att något plötsligt händer som studenten blir medveten om. Det kan till exempel åstadkommas genom överraskande information, en förändring i ljuset i en föreläsning eller att humor vävs in. Den andra är att väcka nyfikenhet. Ett par sätt för det är att involvera mystik i miljön och att ställa frågor. Det tredje sättet är variation. Då handlar det om olika struktur och ordning på undervisningen, till exempel att inte alltid utforma en lektion som föreläsning, demonstration och sedan övning, utan variera det med andra inslag, exempelvis ett filmklipp. Lärandeteorier om hur elever lär sig i grupp är också relevanta. Utifrån det sociokulturella perspektivet som Vygotskij utvecklade [12] lär sig elever av varandra. Eleverna befinner sig i sin närmsta utvecklingszon8, där eleverna kan hjälpa varandra att förstå innebörden av definitioner och uttryck genom att sätta ord på det de vill kommunicera. Denna typ av kommunikation kan hjälpa elever sätta fingret på vad de inte förstår. Med denna bakgrund kan parprogrammering vara fördelaktigt. Dels för att eleverna kan lära sig av varandra, dels för att de genom att kommunicera internaliserar ämnet och bygger en djupare förståelse. Parprogrammering kan även lämpa sig för att begränsa flyktförsök, där elever medvetet eller mindre medvetet börjar ägna sig åt något annat. Två andra aspekter på lärande är interaktion och snabba belöningar. Eftersom internet- plattformars interaktion med eleven är begränsad i jämförelse med då eleven är i skolan och har tillgång till lärare, så brukar internetbaserade läroplattformar förlita sig på be- havioristiska element (former av respons) i form av rätt eller fel svar [12]. Evolutionärt sett har snabba belöningar varit fördelaktigt framför långsiktiga som kräver långsiktigt engagemang (exempelvis öva inför en tenta) vilket beskrivs i boken Dansa på deadline: 7Eftersom projektet har ett begränsat fokus på de pedagogiska aspekterna, se avsnitt 1.3, har enbart Attention tagits hänsyn till. Av detta skäl är enbart denna del beskriven här. 8Den zon där målet för lärandet ligger på en nivå som är för hög för en elev att klara på egen hand, men som eleven klarar om den får vägledning och stöd. 9 2. Teori Uppskjutandets psykologi [13]. Dessa två aspekter återkommer i kapitel 5 10 3 Genomförande Projektets genomförande bestod av fyra delar. Den största delen var konstruktionen av själva läromaterialet i vilken det ingick sökande efter lämpliga områden, implementation av domänspecifika språk och skrivande av lärotext. De tre andra delarna var publicering av läromaterialet på en hemsida, återkoppling på läromaterialet med en testgrupp samt möten med Åke Fäldt, examinator och föreläsare för Fysik för ingenjörer. Mötena med Fäldt hade två syften: att hitta problemområden i fysikkursen och att få återkoppling på läromaterialet. Alla de olika delar i projektet genomfördes samtidigt men de finns här beskrivna separat. 3.1 Konstruktion av läromaterialet Läromaterialet består av fem kapitel som vardera behandlar separata områden. Skapan- det av dem skedde fristående men de innehöll alla de tre faserna sökande, implementation och skrivande, som såg likartade ut för dem alla. Det fanns dock visst överlapp mellan de fristående processerna. Sökandet gav ofta flera områden samtidigt och implementa- tion och skrivande genomfördes ofta parallellt. För att tydliggöra processerna är de dock beskrivna separat. 3.1.1 Sökande efter områden att behandla Ett domänspecifikt språk modellerar ett specifikt och avgränsat område. Därför var det naturligt att söka och tänka i termer av avgränsade områden inom fysiken. För att rent praktiskt hitta områden att behandla kontaktades Åke Fäldt. Dessutom studerades kur- sens bok (University Physics [14]) och dess övriga material. Av speciellt intresse var de kapitel som behandlade mekanik (i enlighet med projektets mål att börja med klassisk mekanik), de områden Fäldt pekat ut som svåra för studenter samt de kapitel som an- vände sig av en specifik syntax. Domänspecifik syntax var av intresse att finna då en betydlig del av domänspecifika språk är modellering av just syntaxen. Denna sökande- process innefattade inte bara att hitta fysikaliska områden utan även att organisera dem i relation till varandra, för att kunna implementera dem på ett bra sätt och presentera dem i en pedagogisk ordning. 11 3. Genomförande 3.1.2 Implementation av domänspecifika språk för områdena Implementationen av domänspecifika språk var en iterativ process. Det finns inte bara ett rätt sätt att skriva ett domänspecifikt språk på, därav gjordes försök med flera olika varianter för att se vad som fungerade bäst. I flera fall har implementationer gjorts om från grunden om det visat sig att implementationen kunde gjorts bättre eller hade bris- ter. Dessutom gjordes, i varierande mån, fördjupande litteraturstudier av domänspecifika språk, fysik och Haskell för att kunna implementera de domänspecifika språken på bästa sätt. Vad som ansågs vara en bra, eller åtminstone tillräckligt bra implementation var i huvud- sak baserat på gruppmedlemmarnas erfarenhet av Haskell och diskussion inom gruppen och med handledaren, det viktigaste var att de var lättförståeliga. Därför användes inte alltid den programtekniskt elegantaste implementationen utan den längre versionen fö- redrogs för att göra läromaterialet så lättläst som möjligt. Dock avstods det inte från användning av mer avancerade funktioner i Haskell när materialet motiverade dem, men då alltid med en uttömmande förklaring om hur det fungerade och utan krav på tidigare kunskap hos läsaren. Efter att ett domänspecifikt språk implementerats skrevs tester till det. Det som var intressant att testa var huruvida domänens lagar gällde i det domänspecifika språket som modellerade domänen. Till exempel var det för det domänspecifika språket om vektorer aktuellt att testa om vektoraddition var kommutativ, och så vidare. Testerna gjordes med hjälp av QuickCheck [15] vilket är ett testningsverktyg i Haskell som genererar många och slumpmässiga testfall. Att lagarna gällde för de domänspecifika språken verifierades med andra ord genom testa för ett stort antal exempelvärden. Inga bevis, utan enbart tester, gjordes för att kontrollera att lagarna gällde. 3.1.3 Skriva lärotext Generellt under skrivningen togs det hänsyn till en specifik underaspekt i ARCS-modellen, nämligen humor. Språket i lärotexten har varit lättsamt, vardagligt och talspråkligt för att hålla kvar uppmärksamheten hos läsaren. Det har även ritats roliga bilder för att ge ytterligare humoristiska drag. Lärotexten och programkoden skrevs sammanvävt i samma fil, i Literate Haskell. Litterat programmering passade bra ihop med hur läromaterialet skulle se ut då det betonade det jämnbördiga förhållandet mellan programkod och förklaringar. För att läromaterialet skulle vara lättförståeligt var det också viktigt att presentera materialet i den ordning som en mänsklig läsare, och inte datorn, tyckte var enklast. Avsnitt 2.3 beskriver hur litterat programmering fungerar i allmänhet och ger en bra bild av hur det såg ut även i detta projekt. Under skrivandet av lärotexten lades övningar till. Dessa skapades genom att modifiera befintlig lärotext, istället för att förklara allting uppmanar den läsaren då och då att göra nästa steg i implementationen själv. När ett kapitel var avslutat lades dessutom extra 12 3. Genomförande övningar till i slutet, dessa övningar var ofta vidareutvecklingar av det domänspecifika språk som redan implementerats. 3.2 Möten och återkoppling För att få återkoppling på läromaterialet hölls ett kort och informellt möte med en test- grupp. Testgruppen bestod av tre andra studenter på Chalmers som gick tredje året på Datateknik och Informationsteknik. De hade alla klarat kursen Fysik för ingenjörer eller motsvarande och även klarat minst en kurs i Haskell. Däremot hade de inte läst DSLsof- Math eller motsvarande. Domänspecifika språk var med andra ord nytt för dem. Under mötet gavs läromaterialet en kort presentation och bakgrund. Sedan fick de på egen hand läsa materialet och deras spontana reaktioner och svar på frågor noterades. Det hölls även två möten med Åke Fäldt. Ett möte hölls relativt tidigt i projektet, 2018- 03-02, och ett andra relativt sent, 2018-04-11. Under mötena presenterades läromaterialet i sig och tanken med det, nämligen att presentera fysik ur ett annat perspektiv, ett programmeringsperspektiv. Diskussionen kretsade sedan kring svåra områden i Fysik för ingenjörer, vad läromaterialet skulle kunna bidra med för kunskaper till studenter samt dess eventuella roll i relation till fysikkursen. 13 3. Genomförande 14 4 Resultat I detta kapitel redovisas det resulterande läromaterialet, vilket består av fem kapitel. Det är publicerat på en hemsida och dess källkod är fritt tillgänglig. Även resultaten från mötena med testgruppen och Åke Fäldt redovisas. 4.1 Läromaterialet Detta avsnitt innehåller en översikt av läromaterialet samt ett axplock av innehållet ur vardera kapitel. Axplocken exemplifier delar av läromaterialet och implementationerna av de domänspecifika språken. De fullständiga implementationerna är inte inkluderade (och förklarade) eftersom det är precis det läromaterialet innehåller. Rapporten skulle då bli en kopia av läromaterialet. Istället finns hela läromaterialet i bilaga A samt på hemsidan [16] där det blev publicerat. De avsnitt i rapporten som beskriver läromaterialets innehåll är inga exakta kopior ord-för-ord utan de har anpassats till rapporten. 4.1.1 Översikt Läromaterialet är en löpande text där Haskell-kod och lärotext sammanvävts. Det ser ut som i figur 4.1a. Lärotexten förklarar både fysik, Haskell och hur de relaterar till varandra. I texten följer läsaren med i implementationen av ett domänspecifikt språk och det visas hur det används. Tanken är att läsaren parallellt programmerar det som texten förklarar, för att på så sätt även få praktisk färdighet i det som presenterats. För detta syfte finns det även övningar tillagda direkt i den löpande texten, se figur 4.1b, som ofta innebär att läsaren själv ska implementera en liten del av det domänspecifika språket. Det finns också övningar i slutet av kapitlet som ofta innebär större vidareutvecklingar av de domänspecifika språken. Språket i lärotexten är enligt projektgruppen lättsamt9 och i detta syfte finns det även bilder tillagda. Figur 4.2 är ett exempel på en bild ur läromaterialet. Notera speciellt den medvetet oseriösa ritningstekniken som är tänkt att vara rolig och muntra upp läsaren. 9Diskuteras utförligare i avsnitt 5.2. 15 4. Resultat (a) Lärotexten är mot den ljusgrå bakgrun- den medan Haskell-kod är mot den mörkgrå. (b) Exempel på en övning. Övningen ligger som en del av den löpande texten. Figur 4.1: Ett smakprov av det resulterande läromaterialet. Figur 4.2: Exempel på en bild. Bilden visar hur en hund springer och hoppar upp på en stillastående vagn. Läromaterialet innehåller fem kapitel som vardera behandlar ett område inom fysik och matematik. Fokuset är på klassisk mekanik samt den matematik som tillhör området. De behandlade områdena är: • Dimensioner • Matematisk analys • Vektorer • Exempelproblem • Partikelmekanik Dimensioner behandlar fysikaliska dimensioner, storheter och enheter inom fysiken. Fy- sikaliska dimensioner införs på typnivå i Haskell för att visa likheten mellan Haskells typsystem och hur dimensioner hanteras inom fysiken. Typnivåprogrammering10 används för att göra likheterna så tydliga som möjligt. I matematisk analys behandlas differentialkalkyl och integralkalkyl för en variabel. Först bestäms den semantiska domänen för analys i en variabel: reella funktioner av ett argu- ment; och en datatyp för syntax för uttryck av funktioner inom denna domän konstrue- 10Vanligtvis manipuleras värden när programmerering sker i Haskell och andra språk. Typnivåpro- grammering är precis som vanlig programmering med skillnaden att den sker på typnivån, det vill säga, att typer modifieras. För en utförligare förklaring av typnivåprogrammering, se läromaterialet [16]. 16 4. Resultat ras. Därefter analyseras syntax och semantik för differenser, derivator, och integraler; och funktioner implementeras för att utföra dessa operationer både approximativt numeriskt, och symboliskt med ett datatypen för syntaxen. Slutligen appliceras de implementerade funktionerna för att visualisera grafer av operationerna. Vektorer behandlar vektorer och vektoroperationer. Vektorer modelleras med hjälp av en typklass som dikterar vilka funktioner som varje modell av en vektor måste implementera. Generella vektoroperationer såsom addition och skalärprodukt implementeras sedan med hjälp av dessa funktioner vilket skapade ett mycket generellt och lättanvänt gränssnitt. QuickCheck användes för att verifiera lagarna som gäller för olika vektoroperationer, vilket gav en generell säkerhet kring att implementationerna var korrekta. I exempelproblem tillämpas de tre tidigare kapitlen på två vanliga mekanikproblem, nämli- gen krafter på lådor och gungbräda. I krafter på lådor används det domänspecifika språket för vektorer till att beräkna de krafter som verkar på en låda som glider ner för ett plan. I gungbräda visas hur momentjämviktsberäkningar kan göras med det domänspecifika språket för dimensioner. Partikelmekanik. En repetition av gymnasieskolans fysik. Lägesenergi, rörelseenergi, gra- vitation och så vidare. Den modelleras med vektorer vars komponenter består av mate- matiska uttryck tagna från kapitlet om matematisk analys. Förhoppningen är att detta område inte ska presentera någon ny fysik för läsaren utan istället visa hur redan känd fysik direkt går att översätta till läromaterialets domänspecifika språk. Läromaterialet blev publicerat på en hemsida [16] och all källkod finns tillgänglig på projektets GitHub [17]. På GitHub finns även ett antal delvis färdigställda områden, till exempel bevisföring. Texten i läromaterialet är skriven på engelska. 4.1.2 Dimensioner I detta avsnitt visas delar av hur implementationen av dimensioner ser ut i läromaterialet. Den fullständiga implementationen innehåller tre delar: 1. Dimensioner på värdenivå 2. Dimensioner på typnivå 3. Datatyp för storheter Dimensioner på värdenivå används för att enkelt kunna skriva ut dimensioner i GHCi. Dimensioner på typnivå används för att ge typsäkerhet till dimensioner, så att till exempel en längd och en massa inte kan adderas, likt att ett värde av typ Double och Integer inte kan adderas i Haskell. Till sist kombineras de två varianterna av dimensioner till en datatyp för storheter som aritmetiska operationer kan utföras på. Dimensioner kan ses som en produkt av de 7 basdimensionerna11, med en indiviudell exponent till varje basdimension. Datatypen, på värdenivå, som används ser därför ut 11Längd, massa, tid, elektrisk ström, temperatur, substansmängd och ljusstyrka. 17 4. Resultat som följande data Dim = Dim Integer -- Length Integer -- Mass Integer -- Time Integer -- Current Integer -- Temperature Integer -- Substance Integer -- Luminosity deriving (Eq) Varje fält i datatypen representerar exponenten för motsvarande basdimension. Om ex- ponenten är 0 betyder det att den basdimension inte är inkluderad i dimensionen. Några exempel ges för att förtydliga. length = Dim 1 0 0 0 0 0 0 mass = Dim 0 1 0 0 0 0 0 time = Dim 0 0 1 0 0 0 0 velocity = Dim 1 0 (-1) 0 0 0 0 acceleration = Dim 1 0 (-1) 0 0 0 0 area = Dim 2 0 0 0 0 0 0 Hastighet skrivs vanligtvis som m s men ekvivalent är att skriva m1 ∗ s−1 vilket förklarar varför värdena ovan ser ut som de gör. I resterande del av detta kapitel i läromaterialet visas hur multiplikation och division samt hur en utskriftsfunktion, som skriver ut ett värde snyggt, kan implementeras. Därefter följer ett antal delkapitel som innehåller testning, typnivådimensioner och storheter. 4.1.3 Matematisk analys I kapitlet om matematisk analys skapas en syntax för funktionsuttryck och symbolisk derivering och integrering implementeras. Dessutom analyseras syntax och semantik hos uttryck som dyker upp inom matematisk analys, till exempel ∆-operatorn. Syntaxen för funktionsuttryck inleds med data FunExpr = Exp | Log | Sin | Cos | Asin | Acos vilket är några av de elementära funktionerna. Näst följer aritmetiska operationer. För att kunna definera dem på funktioner och inte algebraiska uttryck görs nedanstående tolkning f OPr→r g = x 7→ (f(x) OPr g(x)) vilket utökar FunExpr med fler konstruktorer. | FunExpr :+ FunExpr | FunExpr :- FunExpr | FunExpr :* FunExpr 18 4. Resultat | FunExpr :/ FunExpr | FunExpr :^ FunExpr Även konstruktorer för den oberoende variablen, konstanter, funktionskomposition, ∆, derivering och integrering behövs. | Id | Const RealNum | FunExpr :. FunExpr | Delta RealNum FunExpr | D FunExpr | I FunExpr En utförligare förklaring av syntaxen FunExpr finns i läromaterialet. I läromaterialet analyseras derivering utförligt med gränsvärden, kvoter och approximati- va metoder. Dessutom motiveras och implementeras symbolisk derivering. Den görs med en funktion derive som har ett fall för vardera av konstruktorerna i FunExpr. Några av fallen är derive (f :* g) = derive f :* g :+ f :* derive g derive (f :+ g) = derive f :+ derive g derive Exp = Exp 4.1.4 Vektorer Kapitlet om vektorer inleds med en genomgång av vektorer och operationer på dem parallellt med att en första implementation till dem skrivs. Implementation ser ut som följer data Vector2 n = V2 n n type Scalar = Double type VectorTwo = Vector2 Scalar magnitude :: VectorTwo -> Scalar magnitude (V2 x y) = sqrt (x^2 + y^2) add :: VectorTwo -> VectorTwo -> VectorTwo add (V2 x1 y1) (V2 x2 y2) = V2 (x1 + x2) (y1 + y2) dotProd :: VectorTwo -> VectorTwo -> Scalar dotProd (V2 ax ay) (V2 bx by) = ax * bx + ay * by Eftersom vektorer i tre dimensioner ser snarlik ut leder det till väldigt mycket dupli- cerad kod. En andra implementation görs därför som är mer generell. Grunden är den nedanstående typklassen class Vector vector where vmap :: (n -> n) -> vector n -> vector n vzipWith :: (n -> n -> n) -> vector n -> vector n -> vector n 19 4. Resultat vfold :: (n -> n -> n) -> vector n -> n som innehåller de tre funktioner som behövs för att genomföra vektoroperationerna magnitude, add och dotProd. De kan nämligen skrivas om enbart med hjälp av de funk- tioner som finns i typklassen Vector på följande sätt magnitude :: (Floating n, Vector vec) => vec n -> n magnitude = sqrt . vfold (+) . vmap (**2) add :: (Num n, Vector vec) => vec n -> vec n -> vec n add = vzipWith (+) dotProd :: (Num n, Vector vec) => vec n -> vec n -> n dotProd v1 v2 = vfold (+) $ vzipWith (*) v1 v2 Allt som behöver göras för vardera datatyp för vektorer av olika längd är därmed att göra den en Vector-instans. Så här ser det ut för Vector2 instance Vector Vector2 where vmap f (V2 x y) = V2 (f x) (f y) vzipWith f (V2 x y) (V2 x’ y’) = V2 (f x x’) (f y y’) vfold f (V2 x y) = f x y Resterande del av vektor-kapitlet behandlar kryssprodukt, vektorlagar och tester av dem. 4.1.5 Exempelproblem Dessa problem är implementationer eller lösningar på fysikuppgifter som har förekommit på tentamen i Fysik för ingenjörer. De använder de andra modulerna i läromaterialet för att göra beräkningarna (exempelvis dimensionsanalys eller vektoroperationer). Av exempelproblemen finns en gungbräda och en låda på ett lutande plan. Då källkoden för dessa problem endast är menade att lösa den specifika uppgiften, och inte alla varianter på gungbrädor eller lådor på lutande plan, så kan de inte kallas för domänspecifika språk, utan är istället implementationer som använder tidigare domänspecifika språk. Exemplet med gungbrädan har två massor på gungbräda som befinner sig i jämvikt. Upp- giften är att finna en okänd sträcka mellan en av vikterna och balanspunkten. Exemplet använder dimensionsanalys för att representera hävarmseffekten av de olika massorna. Genom att ställa upp förhållanden och lösa ut den okända sträckan, så går det att beräk- na den okända sträckan. Sist görs en säkerhetskontroll där den okända sträckan används för att räkna ut hävarmsmomenten, vilket är den sista kontrolleringen att man inte har gjort några logiska fel. Exemplet med en låda på ett lutande plan undersöker krafterna på en låda på ett lutande plan, såsom gravitationen, normalkraften från det lutande planet, och resultantkraften, vilka representeras genom vektorer från vektormodulen. Detta exemplet tar både hänsyn till statisk friktion (då lådan befinner sig stillastående) och kinetisk friktion (då lådan befinner sig i rörelse). 20 4. Resultat 4.1.6 Partikelmekanik Implementationen av partikelmekanik är en kombination av de domänspecifika språken för vektorer och matematisk analys. Anledningen till detta är att partiklars position, hastighet och acceleration modelleras med vektorer, dessutom är de krafter som påverkar partiklar även de modellerade som vektorer. Sedan används matematisk analys för att göra beräkningar på dem. Därför är det naturligt att modellera partikelmekanik med hjälp av vektorer vars komponenter är uttryck som implementeras av matematisk analys. Datatypen för en partikel är type Mass = FunExpr type VectorE = Vector3 FunExpr data Particle = P { pos :: VectorE -- Position as a -- function of time. -- Unit m , mass :: Mass -- Mass. Unit kg } Ett exempelvärde är particle :: Particle particle = P (V3 (3 * Id * Id) (2 * Id) 1) 3 Eftersom komponenterna i vektorerna är funktionsuttryck är det enkelt att beräkna en partikels hastighet och acceleration. velocity :: Particle -> VectorE velocity = vmap D . pos acceleration :: Particle -> VectorE acceleration = vmap D . velocity Det går även att beräkna nettokraften på en partikel med hjälp av Newtons andra lag. type Force = VectorE force :: Particle -> Force force p = vmap (* m) a where m = mass p a = acceleration p I läromaterialet behandlas även rörelseenergi, lägesenergi, arbete och gravitation. 4.2 Möten och återkoppling Återkopplingen från testgruppen var till övervägande del positiv. Testgruppen tyckte läromaterialet var ett intressant och roligt sätt att presentera fysik på. De tyckte att 21 4. Resultat bilderna tjänade sitt syfte i att muntra upp läsaren. Mötet var dock för kort för att det skulle framgå huruvida läsaren lärde sig mest fysik eller mest Haskell. Det framgick heller inte om läromaterialet uppmuntrade testgruppen att vilja lära sig mer fysik. Åke Fäldt hade en överlag positiv syn på läromaterialet12. Fäldt tyckte att det fanns flera saker läromaterialet kunde bidra med. En var att läromaterialet ger ett annat perspektiv på fysiken, en annan var den rigorösitet som domänspecifika språk innefattar. Eftersom de domänspecifika språken måste vara väldefinierade betyder det att alla fysikaliska koncept måste göras entydiga och väldefinierade. Följden blir att operationerna enbart kan göras på det definierade sättet. Dessutom måste dimensionerna stämma. Fäldt menade att detta var bra egenskaper med läromaterialet och att det rigorösa tankesätt samt den metodik som förmedlas hade varit till nytta för problemlösning i fysikkursen. Fäldt nämnde även områden i Fysik för ingenjörer som var svåra för studenter, vilket användes vid sökandet efter områden, se avsnitt 3.1.1. Roger Johansson, programansvarig på datateknik, och datas nämnd för studier (DNS) var båda positiva till projektets initiativ och målsättning. Dessa möten var viktiga fram- förallt för att göra de som styr utbildningen på datasektionerna medvetna om projektets existens. 12Det bör påpekas att det som är återgivet här självklart är en egen tolkning, och kan ha missuppfat- tats, av projektgruppen. Fäldt ska med andra ord inte behöva stå till svars för vad som står här. 22 5 Diskussion I detta kapitel diskuteras projektets genomförande, resultat, vidareutvecklingsmöjligheter och etiska aspekter. Till att börja med vill vi säga att hur domänspecifika språk kan kombineras med fysik inte var något vi visste när projektet startade. En stor del av arbetet i början av projektet ägnades därför åt att försöka komma på olika sätt att använda dem ihop med olika fysikaliska områden. Det gjordes många experiment innan vi hittade ett sätt att skapa domänspecifika språk för fysik som var annat än triviala implementationer av formler, till exempel att formlen för rörelseenergi, Ek = mv2 2 , kan skrivas som ek m v = m * v * v / 2 i Haskell. Detta experimenterande ledde till att vi såg en slags strategi för hur de kan kombineras, vilket blev den metodik som beskrivs i avsnitt 3.1. Det vi vill poängtera är med andra ord att det har varit oklart hur projektet skulle kunna föras framåt eftersom det inte funnits någon tydlig väg att följa. 5.1 Genomförandediskussion Under projektets genomförande har det gjorts flera val av teorier och metoder att an- vända. Självklart behöver inte dessa val vi gjorde vara de bästa. Därför kommer vi här att kritisera dem och föreslå andra möjligheter. Närmare bestämt kommer mötet med testgruppen, urvalet och Literate Haskell att diskuteras. Det sätt återkopplingen gjordes under projektet kan kritiseras på flera sätt. För det första bestod testgruppen av enbart tre personer. För det andra hölls mötet under en ytterst kort tid, ungefär en timme. Mötet hade behövt vara längre för att låta testgruppen i lugn och ro arbeta igenom ett par kapitel, inklusive att följa med i programmeringen som gjordes i läromaterialet. För det tredje var vi inte tydliga med målet med återkopplingen, nämligen om de tyckte det var meningsfullt att lära ut fysik med hjälp av domänspecifika språk. Det gjorde att de heller inte kunde tänka på dessa frågor. Med tanke på dessa tre brister i återkopplingens genomförande är alla slutsatser dragna med den som stöd ytterst osäkra. Det går även att kritisera hur urvalet av områden gick till under projektet. Dels kan det ha lett till att enbart två domänspecifika språk för fysik implementerades (dimensioner 23 5. Diskussion och partikelmekanik). Dels skedde urvalet ur implementatörens perspektiv (det vill säga vårt) och inte ur användarens perspektiv (studenten som ska nyttja läromaterialet). Med det menar vi att områden valdes utifrån hur det implementationsmässigt hängde ihop, till exempel att matematisk analys är grunden till flera tillämpningar. Istället hade områden kunnat väljas utifrån de fysikaliska problem studenter ska lösa i Fysik för ingenjörer, till exempel block och talja eller momentjämvikt, och utifrån det utforma domänspecifika språk. Till sist kan vi kritisera den allmänna metoden som valdes för utformningen av läroma- terialet, nämligen att skriva varje kapitel som en löpande text om hur ett domänspecifikt språk implementeras eller tillämpas. Nackdelen är att det blir en passiv inlärning, även om det till en viss utsträckning finns övningar och läsaren uppmuntras implementera koden parallellt. Literate Haskell har definitivt bidragit till dessa passiva tendenser. Li- terate Haskell är en programfil som är väldigt väl beskriven hur programmet fungerar, vilket leder till att man ser den som en text att läsa istället för ett program att köra och experimentera med. Under projektets genomförande hade det därför varit av intresse att undersöka alternativa sätt att utforma lärotexten som uppmuntrat ett mer aktivt läran- de. Det hade till exempel kunnat vara att presentera idén bakom fysikaliska dimensioner, och sedan låta studenten själv skapa implementationen. En fingervisning i form av ett enkelt exempel på en möjlig lösning kan vara ett sätt att göra detta. 5.2 Resultatdiskussion Detta avsnitt inleds med en övergripande diskussion om det resulterande läromaterialet och för vem läromaterialet kan vara relevant, för att sedan övergå till en mer generell diskussion kring kombinationen av domänspecifika språk och fysik. I projektets mål och avgränsningar stod det att vi skulle börja med klassisk mekanik, för att i mån av tid även behandla termodynamik och vågrörelselära. I avsnitt 4.1 nämns att de tre grundläggande områdena dimensioner, matematisk analys och vektorer är färdi- ga, samt de komposita områdena partikelmekanik, gungbräda och krafter på lådor. Med andra ord har mekanik påbörjats, men inte termodynamik eller vågrörelselära. Det som återstår enligt oss när det kommer till mekanik är att tillämpa de grundläggande områ- dena på fler fysikaliska problem utöver gungbräda och krafter på lådor. Vi tror att de tre grundläggande områdena som är färdiga räcker. Förutom fler tillämpningar kan mer för- djupande områden implementeras, till exempel bevisföring, något som redan påbörjats, se avsnitt 4.1. En annan del av målet var att läromaterialet skulle vara lättillgängligt genom sitt språk- bruk, publicering på en hemsida och fri tillgång till källkoden. Vi kan konstatera att de senare två har genomförts. Vi passar även på att säga att vi tycker att en lättanvänd hemsida är trevligare att använda än PDF-filer eftersom de inte har sidbrytningar, fas- ta sidmarginaler som använder skärmutrymme, med mera. Detta är visserligen mindre detaljer, men tillsammans påverkar de upplevelsen i stort. Vi tycker även att språket i läromaterialet är någorlunda lättsamt då vi skriver talspråkligt och vardagligt, och för- 24 5. Diskussion klarar svårigheterna grundligt. Språket hade dock kunnat vara vänligare. Till exempel beskriver vi olika koncept som “väldigt enkla” fastän läsaren kanske inte alls tycker det. Vi knyter här även an till lärandeteorierna i avsnitt 2.4, som nämnde interaktion och snabba belöningar. Vårt läromaterial har visserligen ingen interaktiv sida, men typsyste- met i Haskell kan ändå fungera som en fingervisare när programmeraren gör rätt eller fel. Det går exempelvis inte att räkna med dimensioner på ett felaktigt sätt, och funktions- komposition fungerar endast om båda funktionernas typdefinitioner (typer på argument och returvärde) stämmer överens. När det kommer till snabba belöningar kan den glädje programmeraren ser när koden kompilerar ses som en sådan. Läromaterialet innefattar även strategiskt placerade roliga bilder för att ge impulsiva glädjereaktioner. Läromaterialet kan vara relevanta för flera grupper. Visserligen är målgruppen datastu- denter, och vi har personligen dragit nytta av det, men vi tror att det kan vara relevant för fler än så, till exempel kan läromaterialet även vara intressant för fysiklärare. Fäldt nämnde att han tyckte att det rigorösa tankesätt läromaterialet skolar in läsaren i kan vara användbart även i traditionell fysikundervisning. Det kan därför vara intressant att undersöka hur ett sådant här läromaterial kan integreras i undervisningen. En del av projektets mål var att diskutera kombinationen av domänspecifika språk och fysik. I de tre följande avsnitten diskuterar vi därför läromaterialets fokus på matematik och Haskell istället för fysik, vilka fysikaliska områden som var lämpliga att göra do- mänspecifika språk till samt om det finns en pedagogisk nytta i att kombinera de två. Diskussionen är till största del baserad på våra erfarenheter efter att ha implementerat ett flertal domänspecifika språk relaterade till fysik, men de är även baserade på uppfatt- ningar från testgruppen och Fäldt. 5.2.1 Om läromaterialets fokus på matematik och Haskell sna- rare än fysik Målet med läromaterialet var att lära ut fysik på ett roligt och lättförståeligt sätt. Dock syns det i resultatet, avsnitt 4.1, att mest fokus lagts på att förklara och lära ut matematik och Haskell. Det finns flera anledningar till varför så är fallet. Problemet med att prata om en egen implementation av fysik är att fysik inte är ett helt eget område. Snarare kan fysik betraktas som en kombination av tillämpad matematik, experimentering, och problemlösning. Det blir därför naturligt att när den faktiska im- plementationen av fysikaliska beskrivningar och lagar sker, så är matematiken i centrum. Att fysik är tillämpad matematik illustreras i figur 5.1, som även visar mer generellt hur en kedja av områden är tillämpningar av varandra. Anledningen till att stor fokus ibland läggs på Haskell är att de koncept som används är viktiga för läsaren att förstå, men vi vill förutsätta så lite förkunskaper som möjligt så att även oerfarna Haskell-programmerare ska kunna följa med i boken. Ett syfte med läro- materialet är också att väcka intresse hos läsaren, och vi tror att detta kan uppnås genom att visa paralleller mellan funktionell programmering, matematik, och implementationen 25 5. Diskussion Figur 5.1: Purity (C) Randall Munroe ( xkcd.com) CC BY-NC. Bilden beskriver hur fysik är en tillämpning av matematik. Det är i själva verket så att en kedja av områden kan betraktas som tillämpningar av varandra. av fysik. Hade andra val gjorts i projektets tidigare skede, hade det kanske sett annorlunda ut. Tidigt valde vi att söka efter områden som vi ansåg vara fristående och väl avgränsade, se avsnitt 3.1.1, och implementera dessa var för sig. Detta sätt att påbörja projektet har påverkat allting som kom därefter. Om vi istället hade utvecklat läromaterialet som en kombination av olika områden från början hade det kanske inte varit lika främmande att även baka in problemlösning i läromaterialet och på så sätt fått mer fysikorienterade domänspecifika språk. Något annat som kan ha påverkat fokusen är valet av Haskell som implementeringsspråk. Vi hävdar i teorikapitlet 2.2 att Haskells typer och fokus på mönstermatchning gör det idealt för implementering av domänspecifika språk, men medför inte nödvändigtvis att det är idealt för implementering av fysik. Det är möjligt att ett annat språk eller till och med en annan paradigm hade lett till att fokus hade hamnat på fysiken framför matematiken. 5.2.2 Lämpliga områden för domänspecifika språk När domänspecifika språk implementerades visade det sig att vissa områden lämpade sig bättre än andra. Exempel på ett lämpligt och ett mindre lämpligt område är vektorer re- spektive lutande plan13. Vad som skiljer dem åt är enligt oss att lämpliga områden består av tydliga data och operationer medan mindre lämpliga områden består av egenskaper och samband. Inom området vektorer är vektorer data och till exempel vektoraddition en operation. I 13Läromaterialet behandlar fortfarande lutande plan, men inte som ett eget domänspecifikt språk. Istället tillämpas det domänspecifika språket för vektorer. 26 https://xkcd.com/435/ https://xkcd.com https://creativecommons.org/licenses/by-nc/2.5/ 5. Diskussion matematik defineras (en tvådimensionell) vektor som ~v = [ v1 v2 ] och vektoraddition som ~u + ~w = [ u1 u2 ] + [ w1 w2 ] = [ u1 + w1 u2 + w2 ] I Haskell kan en datatyp för vektorer defineras som data V = V Double Double och vektoraddition som va :: V -> V -> V (V u1 u2) ‘va ‘ (V w1 w2) = V (u1+w1) (u2+w2) Det finns enligt oss en tydlig likhet mellan matematik och Haskell i detta fall, och även i för andra lämpliga områden, vilket gör att vi tycker det blir enkelt att modellera och förstå områden som vektorer. Egenskaper och samband är enligt oss svårare att modellera meningsfullt. Visserligen kan ekvationer modelleras i Haskell, men då blir det bara en ekvationslösare. Nyckeln, i till exempel lutande plan, är att känna till sambanden och veta när de ska användas. Vi behandlar därför lutande plan genom att tillämpa det domänspecifika språket för vektorer. Att vissa områden var mindre lämpliga var ett oväntat resultat. I början av projektets start trodde vi att domänspecifika språk skulle kunna implementeras till alla typer av områden. 5.2.3 Domänspecifika språk, fysik och pedagogiska aspekter En del av projektets mål är att diskutera huruvida det finns en pedagogisk nytta i att kombinera fysik och domänspecifika språk. Denna fråga diskuteras nedan. I samband med fysik finns det några fördelar med att integrera domänspecifika språk. Domänspecifika språk kan betraktas som “tools for thinking”14 och ger ett nytt perspektiv på fysik och ger den struktur. Dimensioner är ett exempel på detta, se avsnitt 4.1.2. Där konstateras att en godtycklig dimension kan skrivas som de sju basdimensionerna med tillhörande exponenter, vilket kanske inte är så man brukar se på dimensioner, men som ger dem en väldefinierad struktur. Domänspecifika språk bidrar även med rigorösitet till fysik. Enbart de definierade operationerna går att använda, vilket leder till att genvägar i fysikaliska beräkningar inte går att göra på det sätt som är möjligt vid räkning med papper och penna. Detta tyckte även Åke Fäldt var en bra aspekt, se avsnitt 4.2. Med hjälp av domänspecifika språk är det dessutom möjlighet att väcka intresse för fysik. En student som inte är intresserad av fysik kanske skulle bli det om fysik presenteras i 14Uttryckt i Patrik Janssons egna ord, föreläsare i kursen DSLsofMath. 27 5. Diskussion samband med Haskell och domänspecifika språk, där paralleller mellan dem visas. Denna tanke stöds även av testgruppen15, se avsnitt 4.2 År 2016 genomfördes ett kandidatarbete på Chalmers liknande detta [5]. Det kandidat- arbetet resulterade också i ett läromaterial, skillnaden är att det arbetet behandlade signallära. Grundidén är dock densamma: att använda domänspecifika språk för att ge struktur till ett annat område. Dessutom finns kursen Classical Mechanics: A Computa- tional Approach [3] som också använde domänspecifika språk till att ge struktur till fysik. Detta tycker vi visar på att det finns ett akademiskt intresse för att använda domänspe- cifika språk i syfte att lära ut, och att idén som vi presenterar i denna rapport även går att applicera på andra områden. Nyttan att strukturera upp områden i väl avgränsade och tydligt definierade delar kanske anses som uppenbar, men frågan om vilket verktyg som ska användas för detta är inte lika uppenbar. Vi hävdar att domänspecifika språk är ett sådant verktyg. Det finns dock problem med att använda domänspecifika språk till att lära ut fysik. Ett problem är att den kreativa problemlösning som ingår är fysik är svår att fånga upp i domänspecifika språk16. Ett annat problem är att det finns risk att fokus glider från fysik till domänspecifika språk. Ett läromaterialet om renodlad fysik med ett lättsamt språk och noggrann förklaring av koncepten hade säkert varit mycket uppskattat, det sätt som Khan Academy [18] beskriver fysik är ett sådant exempel. En större målgrupp hade också kunnat nås då. Avslutningsvis tror vi att domänspecifika språk med fördel kan integreras i traditionell fysikundervisning och på så sätt fånga upp de delar domänspecifika språk gör bra i fysik: strukturera, uppmuntra rigorös problemlösning och väcka intresse. Men samtidigt förlita sig på traditionella metoder till stor del i bland annat problemlösning och inte låta fokuset glida för långt från fysik till domänspecifika språk. 5.3 Vidareutvecklingsmöjligheter och behov av yt- terligare kunskap Läromaterialet innehåller domänspecifika språk för de matematiska områdena analys och vektorer. Dessa områden används sedan för att koda upp och lösa uppgifter av mer fysi- kaliska slag, till exempel krafter på lådor. Med andra ord hanteras fysikaliska områden genom att tillämpa matematiska domänspecifika språk och inte genom att konstruera fysikaliska domänspecifika språk. En vidareutveckling hade därmed varit att göra precis det, att inte tillämpa matematiska domänspecifika språk utan att göra fysikaliska do- mänspecifika språk. Det kan till exempel vara saker som ett språk för ett lutande plans komponenter, ett språk för vilka krafter som verkar på fysikaliska kroppar i mekanik- problem eller till och med ett språk för något så abstrakt som fysikalisk problemlösning i allmänhet. Vi vet inte hur ett domänspecifikt språk av detta slag kan se ut, vilket är anledningen till att vi gick den andra vägen, som vi diskuterade i avsnitt 5.2.1. Att göra 15Eftersom mötet med testgruppen var väldigt kort är det dock svårt att dra några säkra slutsatser. 16Enligt oss, och vi vet inte hur det skulle kunna göras. 28 5. Diskussion fler fysikorienterade domänspecifika språk hade därför varit en möjlig vidareutveckling. En annan möjlig vidareutveckling är att göra en rigorös studie kring de pedagogiska aspekterna hos kombinationen av fysik och domänspecifika språk. Detta projekt innehöll enbart en mindre sådan studie. Det som kan vara intressant att undersöka är om stu- denter tycker att fysik blir intressantare genom en kombination av detta slag och kanske därför studerar mer i fysikkursen. Det hade också varit intressant att undersöka om det rigorösa tankesätt domänspecifika språk förmedlar (se avsnitt 5.2.3) spiller över och gör nytta inom traditionell fysikundervisning. Det är för dessa två frågor det främsta beho- vet av ytterligare kunskaper ligger. Ett av målen med detta projekt var trots allt att förbättra fysikkunskaper (genom ökat intresse eller mer rigorösitet) och då är det viktigt att undersöka om det faktiskt blir så i praktiken. Även det befintliga läromaterialet kan byggas vidare på. I sin nuvarande form behandlas varken termodynamik eller vågrörelselära alls. Dessutom finns det aspekter inom den klassiska mekaniken som fattas. Slutligen finns det en mycket intressant vidareutveckling som inte alls har behandlats i detta projekt, nämligen att använda matematiska och fysikaliska domänspecifika språk som ett syntaktiskt lager mellan användare och en underliggande komplex kodbas. I många fall kan dessa kodbaser vara implementerade på sätt som inte förefaller vara intui- tivt, och saknar typsäkerhet. I dessa fall kan det vara användbart med ett domänspecifikt språk med hög typsäkerhet som tvingar användaren att endast skriva korrekta uttryck och som döljer den bakomliggande komplexiteten. Tänk till exempel på kod i Matlab. Där är det lätt hänt att missa någon detalj i sin implementation så att beräkningarna blir fel utan att Matlab klagar. Uttrycket är korrekt men semantiken är fel. Med ett syntaktiskt lager som kräver att de fysikaliska dimensionerna stämmer överens hade vis- sa misstag kunnat upptäckas vid kompilering istället för att kanske inte upptäckas alls. Denna idé framfördes till oss av Jeff Chen17 på Chalmers, men är även någonting som har genomförts på andra områden, till exempel inom molekylär dynamik [19]. 5.4 Etiska aspekter En bakomliggande tanke vi haft genom hela projektet är att läromaterialet ska vara fritt tillgängligt för alla, därför har vi valt att publicera det på en hemsida. Denna hemsida använder grundläggande HTML och CSS samt javascript. Javascript är dock inget strikt krav för funktionaliteten. Eftersom hemsidan är lättviktig bör den fungera väl även på gamla datorer och telefoner, till skillnad från tunga PDF-filer och många moderna hem- sidor. Läromaterialet blir på detta sätt tillgängligt även för studenter i länder med sämre internetuppkoppling. Tanken om tillgänglighet ligger även bakom valet att låta källkoden vara fritt tillgänglig. Visserligen är läromaterialet i princip hela källkoden, det vill säga har läsaren läromate- rialet har den källkoden. Men att ha tillgång till källkoden direkt har dock fördelar som 17Jeffs sida på Chalmers: http://www.cse.chalmers.se/~yutingc/. 29 http://www.cse.chalmers.se/~yutingc/ 5. Diskussion att läsaren kan följa med i versionshistoriken, se kommentarer och alternativa implemen- tationer som inte syns i den slutgiltiga produkten samt att det blir enklare att modifiera källkoden och lära sig om hemsidans uppbyggnad. Det handlar om transparens, att visa att skaparen är positiv till granskning och till att låta andra bygga vidare på ens ska- pelser. Genom att sluta oss till skaran som skapar öppen källkod hoppas vi att fler inom samhället i stort ska gå över till denna modell. Valet att skriva på engelska har också att göra med tillgängligheten. Fler kan engelska än svenska. På detta sätt kan läromaterialet komma fler till gagn. En möjlig negativ etisk aspekt är förstås att enbart studenter som kan Haskell kan dra nytta av detta läromaterial. Om det skulle integreras i traditionell fysikundervisning som ett frivilligt extramaterial skulle vissa studenter få sämre möjligheter att lära sig. Även om en introduktion till Haskell inkluderats i fysikkursen är det tveksamt huruvuda de studenter som inte kunde Haskell sedan innnan skulle kunna tillgodogöra sig innehållet. 30 6 Slutsatser Projektets mål var att konstruera ett läromaterial som modellerar fysik med hjälp av domänspecifika språk samt att diskutera hur väl det fungerar och om det finns en pe- dagogisk nytta i det. Bakgrunden låg i att projektgruppen ville väcka intresse för fysik hos datastudenter genom att presentera det ur ett programmeringsperspektiv. Det skul- le förhoppningsvis kunna förbättra den mindre bra tentastatistiken i kursen Fysik för ingenjörer. Resultatet blev ett läromaterial bestående av domänspecifika språk i Haskell sammanvävt med en lärotext som förklarar dem. Det innehåller kapitel för dimensioner, matematisk analys, partikelmekanik, vektorer och tillämpningar av dem på fysikaliska problem. Det ingår även programmeringsövningar. Läromaterialet publicerades på en hemsida som är fritt tillgänglig för alla att besöka. För att undersöka den pedagogiska nyttan hölls två möten med Åke Fäldt, föreläsare och examinator för Fysik för ingenjörer. Det framgick från mötena med Fäldt att det fanns en klar pedagogisk nytta med det tillvägagångssätt som vi använt för att beskriva fysik. Den rigorösa struktur som Haskell tvingar en att använda ger inte utrymme för en student att hoppa över delar av förståelsen för ett fysikproblem. Istället tvingas studenten att implementera hela lösningen från grunden och detta kan ge en djupare förståelse för problemet och fysiken i stort. Det faktiska resultatet från detta tillvägagångssätt, läromaterialet, testades av en test- grupp. Från denna grupp fick vi mycket positiv kritik och de tyckte att läromaterialet var pedagogiskt, roligt och intressant. Men för att verkligen kunna dra några slutsatser från detta krävs en mycket mer noggrann undersökning huruvida studenter blir bättre på fysik med hjälp av ett läromaterial av detta slag. Till sist vill vi säga vi anser att det material vi har producerat har följt våra mål väl eftersom det är roligt, lättläst och intressant. Och även om den pedagogiska nyttan av materialet inte är ordentligt testat tycker vi alla i projektgruppen att vi har dragit stor nytta av att utveckla det. 31 6. Slutsatser 32 Litteraturförteckning [1] G. Johansson, “Statistik över kursresultat”, 2018. [Online]. Tillgänglig: http : //document.chalmers.se/doc/00000000-0000-0000-0000-00001C968DC6, hämtad: 2018-01-30. [2] C. Ionescu och P. Jansson, “Domain-Specific Languages of Mathematics: Presenting Mathematical Analysis Using Functional Programming”, i Proceedings of the 4th and 5th International Workshop on Trends in Functional Programming in Education, Sophia-Antipolis, France and University of Maryland College Park, USA, 2015, ss. 1-15. [Online]. Tillgänglig: https://doi.org/10.4204/EPTCS.230.1, hämtad: 2018-01- 30. [3] G. J. Sussman och J. Wisdom, “Classical Mechanics: A Computational Approach”, 2008. [Online]. Tillgänglig: https://ocw.mit.edu/courses/earth-atmospheric-and- planetary-sciences/12-620j-classical-mechanics-a-computational-approach-fall- 2008/, hämtad: 2018-01-30. [4] G. J. Sussman, J. Wisdom och M. E. Mayer, Structure and Interpretation of Clas- sical Mechanics. Cambridge, MA, USA: MIT, 2001. [Online]. Tillgänglig: https: //mitpress.mit.edu/sites/default/files/titles/content/sicm/book.html, hämtad: 2018-03-07. [5] F. Lindahl, C. Rosvall, P. Ngo, J. Jonsson och J. Olsson, “Programmering som under- visningsverktyg för Transformer, signaler och system: Utveckling av läromaterialet TSS med DSL”, Chalmers tekniska högskola, Göteborg, Sverige, 2016. [6] S. N. Walck, “Learn Physics by Programming in Haskell,” 2017. [Online]. Tillgänglig: https://arxiv.org/abs/1412.4880v1, hämtad: 2018-05-14. [7] D. Ghosh, “DSL for the Uninitiated”, Queue, vol. 9, nr. 6, s. 10-21, jun. 2011. [On- line]. Tillgänglig: https://doi.org/10.1145/1989748.1989750, hämtad: 2018-03-07. [8] D. Knuth, “Literate Programming”, The Computer Journal, vol. 27, nr. 2, ss. 97-111, jan. 1984. [Online]. Tillgänglig: https://doi.org/10.1093/comjnl/27.2.97, hämtad: 2018-03-14. [9] Haskell Wiki, “Literate Programming”, 2017. [Online]. Tillgänglig: https://wiki. haskell.org/Literate_programming, hämtad: 2018-03-14. 33 http://document.chalmers.se/doc/00000000-0000-0000-0000-00001C968DC6 http://document.chalmers.se/doc/00000000-0000-0000-0000-00001C968DC6 https://doi.org/10.4204/EPTCS.230.1 https://ocw.mit.edu/courses/earth-atmospheric-and-planetary-sciences/12-620j-classical-mechanics-a-computational-approach-fall-2008/ https://ocw.mit.edu/courses/earth-atmospheric-and-planetary-sciences/12-620j-classical-mechanics-a-computational-approach-fall-2008/ https://ocw.mit.edu/courses/earth-atmospheric-and-planetary-sciences/12-620j-classical-mechanics-a-computational-approach-fall-2008/ https://mitpress.mit.edu/sites/default/files/titles/content/sicm/book.html https://mitpress.mit.edu/sites/default/files/titles/content/sicm/book.html https://arxiv.org/abs/1412.4880v1 https://doi.org/10.1145/1989748.1989750 https://doi.org/10.1093/comjnl/27.2.97 https://wiki.haskell.org/Literate_programming https://wiki.haskell.org/Literate_programming Litteraturförteckning [10] Pandoc, “Pandoc: a universal document converter”, 2018. [Online]. Tillgänglig: https: //pandoc.org/, hämtad: 2018-03-14. [11] J. M. Keller, Motivational Design for Learning and Performance: The ARCS Model Approach. New York, New York, USA: Springer, 2010. [12] U. P. Lundgren, R. Säljö, C. Liberg (Red.), “Lärande Skola Bildning”, 2 uppl., Stockholm, Natur & Kultur, 2012. [13] A. Rozental, L. Wennersten, “Dansa på deadline: Uppskjutandets psykologi”, 1 uppl.,ss. 41, Stockholm, Natur & Kultur, 2014. [14] H. D. Young och R. A. Freedman, University Physics with Modern Physics, Harlow, England: Pearson Education Limited, 2015. [15] Hackage, “QuickCheck: Automatic testing of Haskell programs”, 2018. [Online]. Till- gänglig: https://hackage.haskell.org/package/QuickCheck, hämtad: 2018-04-26. [16] B. Werner, E. Sjöström, J. Johansson och O. Lundström, “Learn You a Phy- sics for Great Good!”, 2018. [Online]. Tillgänglig: https://dslsofmath.github.io/ BScProj2018/, hämtad: 2018-03-14. [17] B. Werner, E. Sjöström, J. Johansson och O. Lundström, “BScProj2018”, 2018. [Online]. Tillgänglig: https://github.com/DSLsofMath/BScProj2018, hämtad: 2018- 03-14. [18] Khan Academy, “Khan Academy | Free Online Courses, Lessons & Practise”, 2018. [Online]. Tillgänglig: https://www.khanacademy.org/, hämtad: 2018-04-11. [19] E. H. Müller, J. Grant och W. R. Saunders, “A Domain Specific Language for Performance Portable Molecular Dynamics Algorithms,” 2017. [Online]. Tillgäng- lig: https://arxiv.org/abs/1704.03329, hämtad: 2018-04-20. 34 https://pandoc.org/ https://pandoc.org/ https://hackage.haskell.org/package/QuickCheck https://dslsofmath.github.io/BScProj2018/ https://dslsofmath.github.io/BScProj2018/ https://github.com/DSLsofMath/BScProj2018 https://www.khanacademy.org/ https://arxiv.org/abs/1704.03329 A Läromaterialet Denna bilaga innehåller en ögonblicksbild av hur läromaterialet såg ut 2018-05-30. I Learn You a Physics for Great Good! >>> WORK IN PROGRESS <<< 1. Introduction About this book So what's a DSL? Getting started 2. Calculus Introduction Function expressions Differential calculus Integral calculus Plotting graphs Syntax trees 3. Linear algebra Vectors 4. Dimensions Introduction Value-level dimensions Testing of value-level dimensions Type-level dimensions Quantities Testing of Quantities Usage 5. Newtonian Mechanics Single particle mechanics 6. Examples Teeter Box on an incline © Björn Werner, Erik Sjöström, Johan Johansson, Oskar Lundström (2018), GPL Learn You a Physics for Great Good! >>> WORK IN PROGRESS <<< Introduction / About this book [src: Introduction/About.lhs] Previous: Table of contents Table of contents Next: So what's a DSL? About this book You've arrived at Learn You a Physics for Great Good, the #1 stop for all your beginner-to- intermediate needs of learning Physics through the use of Domain Specific Languages (DSLs). This book was written as a BSc thesis project at Chalmers University of Technology as an offshoot of a bachelor's level elective course Domain Specific Languages of Mathematics. The goal of the the project and the reason for the existence of this book, is to help (primarily CS) students learn physics better. We think that the use of domain specific languages to teach the subject will help set these students in the right mindset to learn physics efficiently and properly. An observed problem has been that students base their mental models completely or partially on intuition and incorrect assumptions, instead of on definitions and proved theorems where validity is ensured. This may be a bad habit stemming from the way math and physics is taught in earlier stages of the education, and we think that DSLs will inherently force students into the right mindset for learning this subject well! Further, many textbooks on physics are incredibly thick and boring, so we've decided to emulate the great and good Learn You a Haskell for Great Good in order to provide som comic relief in between all the dramatic definitions. In this book, we will study physics through the lens of DSLs. We will need to pay close attention to definitions, throughly ponder any non-trivial syntax, and verify (via tests or proofs) that the things we do are actually correct. The areas covered include such things as: dimensional analysis, vectors, calculus, and more! The book is aimed at you who have some knowledge of Haskell. If you know what a class and an instance is, you're probably good to go! Even if you don't we're sure you could pick it up as we go. We believe in you! If you wonder about the weird code blocks at the start of many chapters, they are there to declare the chapters as Haskell modules. All chapters are written in Literate Haskell, and can be used with GHC/GHCi directly as source code. Therefore, you may choose to read each chapter as documented source code, rather than text with examples. [src: Introduction/About.lhs] Previous: Table of contents Table of contents Next: So what's a DSL? © Björn Werner, Erik Sjöström, Johan Johansson, Oskar Lundström (2018), GPL module Introduction.About where Learn You a Physics for Great Good! >>> WORK IN PROGRESS <<< Introduction / So what's a DSL? [src: Introduction/WhatIsADsl.lhs] Previous: About this book Table of contents Next: Getting started So what's a DSL? In general, a domain specific language is simply a computer language for a specific domain. It's NOT a synonym for jargon! DSLs can be specialized for markup, like HTML; for modelling, like EBNF; for shell scripting, like Bash; and more. The languages we will construct will mostly concern modelling of physics and mathematics. We will create data structures in Haskell to represent the same physics calculations that we write on paper, in such a way that we can write functions to, for example, analyze the expressions for validity. Look, we'll demonstrate. Let's say we want to model a language that is a subset to the common algebra we're all familiar with. Our language will consist expressions of a single variable and addition. For example, the following three expressions are all valid in such a language: module Introduction.WhatIsADsl where x + x x (x + x) + (x + x) When implementing a DSL, we typically start with modelling the syntax. Let's first declare a data type for the language Then we interpret the textual description of the language. "Our language will consist of expressions of a single variable and addition". Ok, so an expression can be one of two things then: a single variable or two expressions added together. And that's it, kind of! However, a DSL without any associated functions for validation, symbolic manipulation, evaluation, or somesuch, is really no DSL at all! We must DO something with it, or there is no point! One thing we can do with expressions such as these, is compare whether two of them are equal. Even without using any numbers, we can test this by simply counting the s! If both expressions contain the same number of s, they will be equal! We can now test whether our expressions are equal. And NOW that's it (if we want to stop here)! This is a completely valid (but boring) DSL. We've modelled the syntax, and added a function that operates symbolically on our language. This is a very small and simple DSL, and you've likely done something similar before without even realizing you were constructing a DSL. It can really be that simple data Expr = X | Add Expr Expr x x eq :: Expr -> Expr -> Bool eq e1 e2 = count e1 == count e2 where count X = 1 count (Add e1 e2) = count e1 + count e2 ghci> eq (Add (Add X X) X) (Add X (Add X X)) True In other DSLs we may also look at evaluation and the semantics of a language, i.e. what is the actual type of the result when we evaluate or "compute" our expressions. Throughout this book we'll construct and use DSLs in many different ways. Different parts of the physics we look at will require different DSL treatments, basically. There is no one model to use for all DSLs. [src: Introduction/WhatIsADsl.lhs] Previous: About this book Table of contents Next: Getting started © Björn Werner, Erik Sjöström, Johan Johansson, Oskar Lundström (2018), GPL Learn You a Physics for Great Good! >>> WORK IN PROGRESS <<< Introduction / Getting started [src: Introduction/GettingStarted.lhs]Previous: So what's a DSL?Table of contentsNext: Introduction What you need to dive in To just follow along and implement the same stuff we do, a single document loaded into GHCi will do. For this, you just need to install the Haskell Platform. If you want to automatically install any required dependencies, like Hatlab which will be used later on, install Stack. Stack is a build system that will automatically get dependencies and build the project for you. If you want to build the code the same way we do, this is what you'll need. With Stack installed and our repository cloned, enter the Physics directory and type stack build. Stack should now download and compile all necessary dependencies, such that they are avaiable when you load a module in GHCi. If you need to sharpen up your skills If you need to freshen up on your Haskell, Learn You a Haskell for Great Good is a great book that covers all the important stuff in a humorous manner that really holds your attention. module Introduction.GettingStarted where If you still don't really get what DSLs are all about, try reading the "notes" (almost a full book really) for the course on DSLs of math at Chalmers. If you're studying at Chalmers, it is even better to actually take the course! If there's some part of the material that you still think is unclear (or maybe even wrong? Blasphemy!), please open an issue on the github repo!. We'll look into it! [src: Introduction/GettingStarted.lhs]Previous: So what's a DSL?Table of contentsNext: Introduction © Björn Werner, Erik Sjöström, Johan Johansson, Oskar Lundström (2018), GPL Learn You a Physics for Great Good! >>> WORK IN PROGRESS <<< Calculus / Introduction [src: Calculus/Intro.lhs] Previous: Getting started Table of contents Next: Function expressions What is calculus? Plain equations where no values change over time are all fine and well. The importance of being able to solve basic problems like “If Jenny has 22 apples, and Richard has 18 apples: how many apples do they have together?” cannot be understated, but they’re not especially fun! “An unstoppable car has an constant velocity of 141.622272 km/h. How many kilometers has it driven after a day?”. To solve more interesting problems like this, we need calculus. Calculus is the study of stuff that continuously change over time (or some other continuous variable). For example, a distance that changes over time is equivalent to a velocity. You can have rates of changes with respect to other units, like length, as well, but those are not as common. There are two major branches of calculus, differential calculus and integral calculus. Differential calculus is all about those rates of changes and graph slopes. Differences, differentials, derivatives, and the like. Integral calculus, on the other hand, is all about accumulation and areas. Sums, integrals, and such. module Calculus.Intro where In this chapter we’ll expore the syntax of diffences, the problem with differentials, symbolic differentiation, and numeric and symbolic integration. [src: Calculus/Intro.lhs] Previous: Getting started Table of contents Next: Function expressions © Björn Werner, Erik Sjöström, Johan Johansson, Oskar Lundström (2018), GPL Learn You a Physics for Great Good! >>> WORK IN PROGRESS <<< Calculus / Function expressions [src: Calculus/FunExpr.lhs] Previous: Introduction Table of contents Next: Differential calculus Semantics, syntax, and stuff What is a value in calculus? What kind of values do functions in calculus operate on and produce? Let's look at derivatives to get an idea of what the semantic value of calculus is. Hmm, these examples left me more confused than before. The differentiation function seems to take an expression as an argument, and return the differentiated expression, with regards to a variable. But what is an expression represented as a semantic value? It's not a number yet, the variable in the body needs to be substituted first in order for the expression to be computable. Is it some kind of function then? Well, yes it is! If we reinterpret the differentiation expressions above, it makes more sense. module Calculus.FunExpr (FunExpr (..), RealNum, RealFunc) where import Test.QuickCheck = 2x dx2 dx = f ′(x) df(x) dx can be written as which is really equivalent to or with more descriptive function names . So the type of unary real functions seems like a great fit for a semantic value for calculus, and it is! Great! But... how do we represent a real number in Haskell? There is no Real type to use. Well, for the sake of simplicity we can just say that a real number is basically the same as a Double, and really it is (basically). The problem with Double is that it's of finite precision, so rounding errors may occur. We'll have to keep that in mind when doing calculations! Now, to the syntax. We've concluded that real functions are really what calculus is all about, so let's model them. We create a data type FunExpr that will represent symbolic expressions of functions in our language. FunExpr is very expressive! First of all, there are the elementary functions. We can't have them all, that would get too repetitive to implement, but we'll put in all the fun ones. = 2x dx2 dx D(x2) = 2x with regards to x D(x ↦ x2) = x ↦ 2x D(square) = double type RealNum = Double type RealFunc = RealNum -> RealNum data FunExpr = Exp | Log | Sin | Cos | Asin | Acos Then, there are the arithmetic operators. "But wait", you say, "Aren't arithmetic operators used to combine expressions, not functions?". We hear you friend, but we will do it anyways. We could make a Lambda constructor for "VAR EXPR" expressions and define the arithmetic operators for the expression type, but this would make our language much more complicated! Instead, we'll restrain ourselves to single variable expressions, which can be represented as compositions of unary functions, and define the arithmeric operators for the functions instead. And then there's that single variable. As everything is a function expression, the function that best represents "just a variable" would be , which is the same as the function. In a similar vein, the constant function. Then there's function composition. If you didn't already know it, it's defined as Finally, the real heroes: the functions of difference, differentiation, and integration! They will be well explored later. But for now, we just define the syntax for them as ↦ f OPr→r g = x ↦ (f(x) OPr g(x)) | FunExpr :+ FunExpr | FunExpr :- FunExpr | FunExpr :* FunExpr | FunExpr :/ FunExpr | FunExpr :^ FunExpr x ↦ x id | Id const(c) = x ↦ c | Const RealNum f ∘ g = x ↦ f(g(x)) | FunExpr :. FunExpr | Delta RealNum FunExpr | D FunExpr | I FunExpr Even more finally, we add a deriving modifier to automatically allow for syntactic equality tests between FunExprs. Nice! This syntax tree will allow us to do symbolically (at the syntax level) what we otherwise would have to do numerically (at the semantics level). Before we move on, we just have to fix one thing: the operator precedence! If we don't do anything about it, this will happen Now this is obviously wrong. Plus doesn't come before times, unless I accidentaly switched timelines in my sleep. To fix this, we have to fix the fixity. infixl allows us to make an operator left-associative, and set the precedence. A structure with class Now that we've defined the basic structure of our language, we can instantiate some useful classes. There are three in particular we care for: Show, Num, and Arbitrary. Try modifying FunExpr to derive Show, so that our expressions can be printed. Consider now how GHCi prints out a function expression we create deriving Eq ghci> Id :+ Id :* Id == (Id :+ Id) :* Id True -- Medium precedence infixl 6 :+ infixl 6 :- -- High precedence infixl 7 :* infixl 7 :/ -- Higher precedence infixl 8 :^ -- Can't go higher than this precedence infixl 9 :. deriving (Eq, Show) Well that's borderline unreadable. Further, the grokability of a printed expression is very inversely proportional to the size/complexity of the expression, as I'm sure you can imagine. So if the derived Show is bad, we'll just have to make our own Show! Not much to explain here. It's just one way to print our syntax tree in a more readable way. What's interesting is how we can now print our expressions in a much more human friendly way! ghci> carAccel = Const 20 ghci> carSpeed = Const 50 :+ carAccel :* Id ghci> carPosition = Const 10 :+ carSpeed :* Id ghci> carPosition Const 10.0 :+ (Const 50.0 :+ Const 20.0 :* Id) :* Id showFe :: FunExpr -> String showFe Exp = "exp" showFe Log = "log" showFe Sin = "sin" showFe Cos = "cos" showFe Asin = "asin" showFe Acos = "acos" showFe (f :+ g) = "(" ++ showFe f ++ " + " ++ showFe g ++ ")" showFe (f :- g) = "(" ++ showFe f ++ " - " ++ showFe g ++ ")" showFe (f :* g) = "(" ++ showFe f ++ " * " ++ showFe g ++ ")" showFe (f :/ g) = "(" ++ showFe f ++ " / " ++ showFe g ++ ")" showFe (f :^ g) = "(" ++ showFe f ++ "^" ++ showFe g ++ ")" showFe Id = "id" showFe (Const x) = showReal x showFe (f :. g) = "(" ++ showFe f ++ " . " ++ showFe g ++ ")" showFe (Delta h f) = "(delta_" ++ showReal h ++ " " ++ showFe f ++ ")" showFe (D f) = "(D " ++ showFe f ++ ")" showFe (I f) = "(I " ++ showFe f ++ ")" showReal x = if isInt x then show (round x) else show x where isInt x = x == fromInteger (round x) instance Show FunExpr where show = showFe ghci> carPosition (10 + ((50 + (20 * id)) * id)) Still a bit noisy with all the parentheses, but much better! Another class we can instantiate for our FunExpr is Num. This class allows us to make use of the native Haskell functions and operators for numeric operations, instead of writing our own constructors. This sometimes improves the readability of the code. Third but not least, we'll instantiate Arbitrary. This class is associated with the testing library QuickCheck, and describes how to generate arbitrary values of a type for use when testing logical properties with quickCheck. For example, a property function could be formulated that states that the :* constructor of FunExpr is associative. The implementation itself is not very interesting. We generate a function expression that tends to contain mostly elementary functions, arithmetic operations, and a generous dose of constants; with a light sprinkle of differences. We won't include derivatives as all elementary functions have elementary derivatives anyways, and integrals may cause cause approximation errors if we have to numerically compute them at evaluation. frequency "chooses one of the given generators, with a weighted random distribution". By assigning probabilities of generating certain functions more often than others, we can restrain the growth of the generated expressions in complexity. instance Num FunExpr where negate e = Const 0 :- e (+) = (:+) (*) = (:*) fromInteger = Const . fromInteger abs = undefined signum = undefined instance Arbitrary FunExpr where arbitrary = frequency [ (10, genElementary) , (10, genBinaryOperation) , (10, return Id) , (20, fmap Const arbitrary) , (10, genBinaryApp (:.)) , (5 , genBinaryApp Delta) ] where genElementary = elements [Exp, Log, Sin, Cos, Asin, Acos] [src: Calculus/FunExpr.lhs] Previous: Introduction Table of contents Next: Differential calculus © Björn Werner, Erik Sjöström, Johan Johansson, Oskar Lundström (2018), GPL genBinaryApp op = fmap (\(f, g) -> f `op` g) arbitrary genBinaryOperation = elements [(:+), (:-), (:*), (:/), (:^)] >>= genBinaryApp Learn You a Physics for Great Good! >>> WORK IN PROGRESS <<< Calculus / Differential calculus [src: Calculus/DifferentialCalc.lhs] Previous: Function expressions Table of contents Next: Integral calculus Deep, dark, differences A difference is, in it’s essence, quite simply the result of applying the operation of subtraction to two real number terms. Nice, great job, we’re done here, let’s move on. … Just kidding, of course there’s more to it than that. In calculus, the term difference carries more meaning than usual. More than just a subtraction of arbitrary values, differences lie at the heart of calculations regarding rate of change, both average and instantaneous. module Calculus.DifferentialCalc (deriveApprox, derive, simplify) where import Calculus.FunExpr minuend − subtrahend = difference Quotients of differences of functions of the same time describe the average rate of change over the time period. For example, an average velocity can be described as the difference quotient of difference in position and difference in time. where is the position at time . In the context of calculus, we use a special syntax for differences: the delta operator! With this, the previous defini