Epost: bopspe@cs.umu.se Hemsida: http://www.cs.umu.se/~bopspe Presentation of I. Name: Disputerat nu vår Forskningsintresset är: Datorstöd för lärandeprocessen Informationsvisualisering Kunskapsrepresentation Informationssökning Verktyg för kunskapsarbete Pedagogik Epost: bopspe@cs.umu.se Hemsida: http://www.cs.umu.se/~bopspe Tel: 786 5349 Rum: D438

Kurslitteratur: Robert W. Sebesta Concepts of Programming Language”, 4th ed.

Schemaändningar 13 April är det två föreläsningar 14 April är det föreläsning + gruppövning 17 April varken föreläsning eller gruppövning 18 April ingen föreläsning 25 April är det en extra föreläsning (repetition av hela kursen)

Laboration 3 Utvärdering av ett programmeringsspråk 2 och 2 mejla senaste 6/4 Ingen programmering Uppsats/rapport Inlämning 25/4 Muntlig redovisning Datum meddelas senare Se web-sidorna för mer information

”Programspråksteori” Diskutera fram vad de har för förväntningar på kursen i termer av: Mål Kursinnehåll Vad programspråksteori innebär Mål för kursen Kursinnehåll Varför studera ”programspråksteori”

Kursinnehåll Allmänt om programmeringsspråk Grundläggande principer för design av programmeringsspråk Visa på de grundläggande byggnadsstenarna hos programmeringsspråk

Mål Bli orienterade om programmeringsspråk Få en förståelse för hur programmeringsspråk är uppbyggda Kunna läsa och förstå en informell beskrivning av ett programmeringsspråk Underlätta inlärandet av nya programmeringsspråk Lättare kunna välja språk

Varför studera programspråk? 1. Om man studerar språkkonstruktioner får man en större bredd att stå på inför kommande programmeringsuppgifter. Överföra saker från ett språk till ett annat även det ”nya” inte stödjer konstruktionen direkt (kan skapa egna funktioner mm). 2. Känner man inte till olika språks egenskaper så är sannolikheten stor att man alltid väljer det språk man ”kan bäst” även om det inte är det språk som passar bäst för tillämpningen. 3.Har man kunskaper om hur olika konstruktioner fungerar så är det lättare att se hur de implementeras i det nya språket. Även bra för att kunna läsa språkmanualer. 4. Kan se var svårigheterna ligger och kanske använda språket som det var tänkt. 5. Det är inte så många som ska skapa nya programspråk, men många program kräver interaktion i någon form och vissa delar där har liknande värderingskriterier 6. Bredare kunskap, ger förståelse för varför vissa språk är populärare än andra 1. Ökad förmåga att uttrycka och förstå begrepp inom programmering 2. Kunskaper för att välja programmeringsspråk 3. Lättare att lära sig nya programmeringsspråk 4. Förstå varför ett språk är implementerat på ett visst sätt 5. Designa nya programmeringsspråk 6. Bredare förståelse av datavetenskap som område

Programmerings domäner Vetenskapliga beräkningar Ursprunget Enkla datatyper (arrayer, matriser) Ofta flyttalsberäkningar FORTRAN ”Business applications” Rapporter Heltal, bokstäver (databaser) COBOL AI- ”symboliska beräkningar” Symbolmanupulering Listor istället för arrayer LISP, Prolog Systemprogrammering OS +hjälpmedel Snabbexekvering Lågnivåegenskaper accepterade C Scriptprogrammering (bla. www) Olika skalprogram Interpreterande PERL, Javascript Tillämningsspråk RPG - rapportgenerering PLEX - AXE-växlar ML- bevisa korrekthet i algoritmer Vetenskapliga beräkningar FORTRAN ”Business applications” COBOL AI- ”symboliska beräkningar” LISP, Prolog Systemprogrammering C Scriptprogrammering (bla. www) PERL, Javascript Tillämningsspråk RPG - rapportgenerering PLEX - AXE-växlar

Krav på bra programspråk Universellt –  alla problem som har en lösning ska gå att programmera i språket (dock ej alltid effektivt) Naturligt – Implementerbara – det måste gå att exekvera varje program som kan skrivas i språket (gäller tex. Inte naturliga språk) Effektiva – (ganska obestämdbar egenskap, kostnads effektivt, minneseffektivt, snabb exekvering, mm. Universellt Lösa alla lösbara problem Naturligt Lösningarna skall kännas naturliga Implementerbara Måste gå att implementera Effektiva Det måste gå att göra en rimligt effektiv implementation av språket (både tids och minnes effektivt)

Kritierier för utvärdering Det existerar många kriterier men läsbarhet, skrivbarhet, tillförlitlighet, kostnader är de viktigaste men det finns också andra som är värda att betrakta Läsbarhet Skrivbarhet Tillförlitighet Kostnader Övriga

Läsbarhet Enkelhet Ortogonalitet Kontrollsatser Många konstruktioner (komponenter) -> svårt att lära sig all -> använder bara en delmängd -> olika personer använder olika delmängder -> svårt att läsa andras kod Många sätt att göra samma sak är inte bra! Ortogonalitet De konstruktioner som finns kan kombineras på ”samma” sätt. Tex. Om det finns arrayer ska man kunna skapa arrayer av alla typer osv. Typ exempel på icke ort. I C kan funktioner returnera structs men inte arrayer. Kontrollsatser Alla vanliga kontrollstrukturer skall finnas tex. Så bör det finnas kontrollsatser för upprepning så att goto kan undvikas GOTO -> spagettiprogram->låg läsbarhet Datatyper och datastrukturer Det bör finnas tillräckligt med datatyper/strukturer för att kunna skapa /abstrahera det man behöver (tex. Boolska variabler underlättar) Ren syntax Variabel namn Längden på identifierarna mm Enkelhet Ortogonalitet Kontrollsatser Datatyper och datastrukturer Ren syntax

Skrivbarhet Enkelhet och ortogonalitet Stöd för abstraktion Hur enkelt det är att skriva/skapa program Allt det redan nämnda påverkar även skrivbarheten tex Enkelhet och ortogonalitet men också Stöd för abstraktion Förmågan att kunna konstruera komplexa strukturer och använda operationer för att senare kunna använda dem på er enkelt sätt (onödiga detaljer göms), tex funktioner Uttryckbarhet Att det finns bekväma , snare än besvärliga sätt att uttrycka beräkningar tex. For i=: 1 to 5 begin …end Istället för I:=1 While (i<=5) do i:=i+1; End; Enkelhet och ortogonalitet Stöd för abstraktion Uttryckbarhet

Tillförlitlighet Typkontroller Undantagshantering ”Aliasing” Underlätter felsökningen/hittandet av fel Undantagshantering Förmågan att hantera oförutsedda fel så division med 0 ”Aliasing” Tillåter man 2 eller flera sätt att referera samma minnes utrymme minskar tillförlitligheten -> man vill minimera detta Läs och skrivbarhet Påverkar även tillförlitligheten Typkontroller Undantagshantering ”Aliasing” Läs och skrivbarhet

Kostnader Är ett samspel mellan många (alla andra) faktorer Utbildning kostar Skriva program kostar Kompilering kostar Exekvering av program kostar Utvecklingsmiljöer/kompilatorer mm kostar Tillförlitlighet kostar Att få Men också dålig tillförlitlighet kostar Underhållandet av program kostar

Övriga kriterier Portabilitet Generalitet ”Well-defined” Portabilitet Hur enkelt kan program flyttas till andra system? (om så är önskvärt) Beror mycket på standariseringsarbete Generalitet Kan språket användas till många typer av applikationer ”Well-defined” Hur bra/tydligt är språket definierat->ett väldefinierat språk är lättare att implemtera, och få det tillförlitligt mm. Portabilitet Generalitet ”Well-defined”

Utmärkande influenser för design Arkitekturen hos maskinerna Von Neumann 99.9% av alla datorer Övriga arktekturer ||-arkitekturer, dataflödes, LISP-maskinen,... ”Hypade” programmeringsmetodiker Strukturerad programmering Dataabstarktion Objektorienterad programmering

Typer av programspråk Imperativa Funktionella Logikspråk de allra vanligaste, bygger på datorark med minnesceller (Von Neumann ark.) FORTRAN , C, Modula 2, och Pascal Funktionella - renare programmeringstil, lättare bevisa korrekthet hos program. Bygger på funktionsbegreppet från matematik. LISP, Haskell, Miranda och ML Logikspråk Bygger på relationer istället för funktioner Skiljer sig mycket från övriga språk, normalt specificerar vi i detalj vad som skall göras, men här är det upp till systemet, dvs vi talar om vad vi vill men inte hur. Prolog Objektorienterade Utbyggnad av de imperativa språken Bygger på en programmering metodik istället för dator ark. Simula, Smalltalk, Eiffel, C++, Java Imperativa FORTRAN , C, Modula 2, och Pascal Funktionella LISP, Haskell, Miranda och ML Logikspråk Prolog Objektorienterade Simula, Smalltalk, Eiffel, C++, Java

”Trade-offs” för språkdesign Tillförlitlighet vs. Beräkningskostnaden Exempel- kontroll av arrayindexering-> ökad kostnad-> ökar tillförlitligheten hos programmen Skrivbarhet vs. Läsbarhet För stor frihet att komponera programmen (kompakta program one-liners) -> minskar läsbarheten Flexibilitet vs. Säkerhet Man vill gärna som programmerare ha ett flexibelt språk (personligen uppskattar jag det) men till en kostad vid felanvändning för säkerheten tex pekare i C Tillförlitlighet vs. Beräkningskostnaden Skrivbarhet vs. Läsbarhet Flexibilitet vs. Säkerhet

Implementeringsmetoder Kompilerande språk Interpreterande språk Hybridsystem Kompilerande språk Interpreterande språk Hybridsystem

Kompilering Översätter hösnivåspråk -> maskinkod Snabb exekvering av programmen Långsam process att översätta Vanligast för produktionsspråk så som C, COBOL, FORTRAN, ADA

Interpretering ”Mjukvaru dator” Hanterar högnivåkommandon istället för maskininstruktioner Ingen översättning av programmet Långsam exekvering av program Allt ovanligare En del LISP implementationer

Hybridsystem Översätter till mellankod Mellankoden skall vara enkel att interpretera Tex. Perl, och de flesta Java implementationerna

Historisköverblick (Självstudier) Årtal och släktskap mellan språk är inte entydigt Nya språk har idéer från ”alla” äldre språk Kapitel 2 kan läsas ganska översiktligt strunta i detaljnivå Försök att komma ihåg ”nytt och bestående”