Uppsatsen behandlar programmeringsspråket F# med mål att undersöka hur användbart det är för företag idag jämfört med andra språk. Arbetet är uppdelat i två delar. En teoretisk del redogör for språkets upplägg som hybridspråk och undersöker fördelarna hos den funktionalitet som hämtats från det objektorienterade samt det funktionella paradigmet respektive. Den andra delen består av en enkätundersökning som utförts där vi frågat systemutvecklare i Sverige om användandet av F# i deras verksamhet, samt vilka tankar de har kring språkets upplägg och framtid inom arbetsmarknaden. Slutligen jämförs vår teoretiska slutsats med resultatet från vår undersökning för att kunna avgöra om F# är något som är värt för företag att investera i, eller om det inte bidrar tillräckligt för att vara värt besväret.Resultatet blev att trots att det ger ett antal nya möjligheter i teorin då man kombinerar objektorienterad och funktionell programmering, så innebär detta i praktiken bara att slå ihop två komponenter som redan kunde kopplas samman sedan innan. Inget revolutionerande presenteras i F# och därför finns det heller ingen anledning för företag att bygga om sina existerande system - även om många respondenter i undersökningen fann konceptet intressant. / This essay processes the programming language F# in an attempt to discover its usefulness within companies today compared to other languages. The work is split into two parts. A theoretical part examines the structure of F# as a hybrid language and assesses the benefits of the functionalities that has been implemented from both the object oriented as well as the functional paradigm respectively. The second part presents the results of a performed survey where we have asked system developers in Sweden regarding the use of F# in their company, along with their thoughts regarding the structure and future of the language. Lastly, our theoretical analysis is compared with the results from our survey to determine whether F# is worth company’s investments, or contributes too little to be worth the hassle.2The results showed that despite combining object oriented and functional programming in theory opens up a number of new possibilities, it practically just means making a new language from two components which could already be connected. No revolutionary aspects are presented along with F# and therefore there is no reason for companies to rebuild their existing systems for this - even though many respondents of the survey found it an interesting concept.

Rapporten beskriver design, utveckling och testning av det funktionella shaderspråket FSL i syftet att avgöra om funktionell paradigm gör shaderspråk enklare att förstå och använda än den existerande imperativa paradigmen. Implementationen presenterar tekniker för att kompilera de funktionella språkkonstruktionerna typinferens, funktionsvärden och automatisk generalisering till HLSL. För jämförelse introduceras också språket PSL, en imperativ motsvarighet till FSL. Resultatet bedöms genom ett blindtest där FSL och PSL presenteras till två separata grupper och testas genom tre provuppgifter. Undersökningen visade att personer som testade det funktionella språket svarade mer negativt på språkets designbeslut, men att båda grupperna presterade lika bra på uppgifterna. Förslag på hur arbetet kan användas som grund för en djupare studie om funktionell grafikprogrammering presenteras. Till sist diskuteras olika sätt att bygga på FSLs tekniska bas för att implementera andra funktionella språkverktyg.

Tecken finns på att det objektorienterade paradigmet börjar tappa sinstatus som den oomstridda lösningen inom systemutveckling. Nya idéerkommer in och ställer grundläggande programmeringsprinciper påända. Vad kan ett deklarativt förhållningsätt tillföra och vad innebär detatt programmera funktionellt? Variabler är en viktig komponent i denprogrammering som huvudsakligen bedrivs idag. Variabler tillhör detimperativa paradigmet i vilket programmeraren i hög grad beskriverhur beräkningar skall utföras av datorn. Detta står i kontrast till detdeklarativa paradigmet – i vilket funktionell programmering normaltplaceras – där man har en högre abstraktionsgrad, saknar variabler ochendast beskriver att något skall göras – inte hur. I funktionellprogrammering kan inte något tillstånd i samma bemärkelse som iimperativ – procedurell eller objektorienterad – programmering finnas.Upprepningar måste göras med rekursion och program ärdeterminerade. Både fördelar och nackdelar finns med detta, det blirlättare att resonera kring ett program men samtidigt kan sidoeffekter,som att skriva något till en fil, inte förekomma i rent funktionellaprogram. Eftersom detta är en vanligt förekommande uppgift idatorprogram idag måste det hanteras på något sätt. Att kombinerafunktionella och objektorienterade språk innebär visserligen enkompromiss där man förlorar en del av de fördelar som finns med rentfunktionella program men är samtidigt en naturlig utveckling från detobjektorienterade arbetssätt vilket för närvarande är så dominerande.Följande uppsats ämnar att förklara den funktionella programmeringen,redogöra för de aspekter som gör den intressant och beskriva dess platsi framtidens program- och systemutveckling.Tecken finns på att det objektorienterade paradigmet börjar tappa sinstatus som den oomstridda lösningen inom systemutveckling. Nya idéerkommer in och ställer grundläggande programmeringsprinciper påända. Vad kan ett deklarativt förhållningsätt tillföra och vad innebär detatt programmera funktionellt? Variabler är en viktig komponent i denprogrammering som huvudsakligen bedrivs idag. Variabler tillhör detimperativa paradigmet i vilket programmeraren i hög grad beskriverhur beräkningar skall utföras av datorn. Detta står i kontrast till detdeklarativa paradigmet – i vilket funktionell programmering normaltplaceras – där man har en högre abstraktionsgrad, saknar variabler ochendast beskriver att något skall göras – inte hur. I funktionellprogrammering kan inte något tillstånd i samma bemärkelse som iimperativ – procedurell eller objektorienterad – programmering finnas.Upprepningar måste göras med rekursion och program ärdeterminerade. Både fördelar och nackdelar finns med detta, det blirlättare att resonera kring ett program men samtidigt kan sidoeffekter,som att skriva något till en fil, inte förekomma i rent funktionellaprogram. Eftersom detta är en vanligt förekommande uppgift idatorprogram idag måste det hanteras på något sätt. Att kombinerafunktionella och objektorienterade språk innebär visserligen enkompromiss där man förlorar en del av de fördelar som finns med rentfunktionella program men är samtidigt en naturlig utveckling från detobjektorienterade arbetssätt vilket för närvarande är så dominerande.Följande uppsats ämnar att förklara den funktionella programmeringen,redogöra för de aspekter som gör den intressant och beskriva dess platsi framtidens program- och systemutveckling. / There are signs that the object-oriented paradigm is beginning to lose itsstatus as the undisputed answer in system development. New ideas arearriving and they are flipping fundamental programming principlesupside down. What can a declarative approach bring and what does itmean to program in a functional fashion? Variables are an importantcomponent in the type of programming that is generally conductedtoday. Variables belong to the imperative paradigm in which theprogrammer to a large extent describe how calculations are to bepreformed by the computer. This is in contrast to the declarativeparadigm – in which functional programming is usually placed – wherethe level of abstraction is higher, variables are missing and where youonly describe that something is to be performed – not how. In functionalprogramming there cannot be any state in the same sense as inimperative – procedural or object-oriented – programming. Repetitionhas to be performed with recursion and programs are deterministic.There are both benefits and disadvantages with this, reasoning about aprogram is easier but at the same time there cannot be any use of sideeffects,like writing something to a file, in a purely functional language.Since that is a common task in computer programs today the dilemmahas to be dealt with in some way. Combining functional and objectorientedlanguages does mean making a compromise where some of thebenefits of purely functional programs are lost but it is also a naturalevolution from the object-oriented methods that are currentlydominating. The following thesis will show what functionalprogramming is, explain which aspects make it interesting and describeits place in the program and system development of the future.There are signs that the object-oriented paradigm is beginning to lose itsstatus as the undisputed answer in system development. New ideas arearriving and they are flipping fundamental programming principlesupside down. What can a declarative approach bring and what does itmean to program in a functional fashion? Variables are an importantcomponent in the type of programming that is generally conductedtoday. Variables belong to the imperative paradigm in which theprogrammer to a large extent describe how calculations are to bepreformed by the computer. This is in contrast to the declarativeparadigm – in which functional programming is usually placed – wherethe level of abstraction is higher, variables are missing and where youonly describe that something is to be performed – not how. In functionalprogramming there cannot be any state in the same sense as inimperative – procedural or object-oriented – programming. Repetitionhas to be performed with recursion and programs are deterministic.There are both benefits and disadvantages with this, reasoning about aprogram is easier but at the same time there cannot be any use of sideeffects,like writing something to a file, in a purely functional language.Since that is a common task in computer programs today the dilemmahas to be dealt with in some way. Combining functional and objectorientedlanguages does mean making a compromise where some of thebenefits of purely functional programs are lost but it is also a naturalevolution from the object-oriented methods that are currentlydominating. The following thesis will show what functionalprogramming is, explain which aspects make it interesting and describeits place in the program and system development of the future.

Because of its security, high availability, and automatic memory management, the JVM (Java Virtual Machine) is a desirable execution environment. However, since the JVM was originally made for Java, which is an objectoriented language, it is hard for languages with other paradigms to run on it. This thesis explores the challenges of compiling a functional language for the JVM. We implement a backend generating JVM bytecode as an extension to the compiler of MCore, a minimal functional language based on the lambda calculus. The backend features two different ways of compiling functions. One generates classes representing functions and their environment at compile-time, and one creates these function classes dynamically at runtime. The two different versions of compiling functions are compared in regards to execution speed of the outputted bytecode, compiler output size, and recursion depth. The results show that the two different ways of compiling functions perform well on different metrics. / På grund av sin säkerhet, tillgänglighet och automatiska minneshantering är JVM:en (Java Virtual Machine) en önksvärd exekveringsmiljö. På grund av att JVM:en ursprungligen skapades för programmeringsspråket Java, som är ett objektorienterat språk, så är det svårt för språk som följer andra paradigmer att köra på JVM:en. Denna uppsats undersöker utmaningarna som uppstår vid kompilering av ett funktionellt språk på JVM:en genom en litteraturstudie. Vi implementerar en backend som genererar JVM bytekod som en utökning av kompilatorn för MCore, ett minimalt funktionellt språk baserat på lambdakalkylen. Backenden implementeras med två tekniker för att kompilera funktioner. Den ena genererar klasser som representerar funktioner och deras miljö under kompileringstiden och den andra genererar dessa funktionsklasser dynamiskt vid körtid. Vi jämför de två teknikerna med avseende på den producerade bytekodens exekveringstid, storlek och rekursionsdjup. Resultaten visar att de två kompilationsteknikerna av funktioner presterar olika på olika mätningar.

In the intelligence community, intelligence is defined as the right information to the right party at the right time. This definition also applies to business intelligence used by government and financial institutions, patient information used by healthcare providers and meteorological and geological reports provided by research institutions and environmental agencies. Modern software development has to tackle the problems associated with building large and complex distributed systems that have to deliver business value in a reliable and timely fashion; even the best prediction has no value if it is delivered after the fact. It is imperative that the producers in a larger system are responsible for publishing their output to minimize the lead-time for consumers. Using regular web services, the consumer can only check for new data by polling the producer. In a system with many consumers, resources are wasted handling these status requests. Instead of the client interacting with service provider, the client should be reacting to it. The reactive programming model supports building systems with these properties. On the .NET platform, the Reactive Extensions library provides functionality for creating reactive applications by composing functions that operate on asynchronous event streams. The library provides powerful tools for building reactive programs, unfortunately it does not contain an abstraction for inter-process event streams that is needed for building distributed reactive systems. This thesis presents the design and implementation of a framework for creating and using observable web services as a means to bridge the inter-process gap that exist when building a system using Reactive Extensions. The solution is based on a conceptual modeled created by extending the web service architecture. The solution is implemented as a framework made up by two parts; a service component used for creating observable web services and client component that connects to an observable web service and generates code used for subscribing to events exposed by that service. The client subscription functionality integrates with Reactive Extensions, making it possible to build reactive and distributed systems. Integration tests are used to verify that the implementation fulfils the requirements specified for the conceptual model. / I underrättelsevärlden definieras en underrättelse som väsentlig information förmedlad till rätt instans vid rätt tidpunkt. Samma definition gäller för omvärldsanalys som används av regeringar och finansinstitut, patientinformation som används av vårdaktörer och metrologiska och geologiska rapporter som tillhandahålls av forskningsinstitut och miljöorganisationer. Modern mjukvaruutveckling måste lösa problem associerade med att bygga stora, komplexa och distribuerade system som på ett tillförlitligt sätt ska leverera företagsnytta i rätt tid; även den bästa förutsägelsen är utan värde om den levereras för sent. Det är absolut nödvändigt producenter i ett större system ansvarar för att publicera sitt data så att konsumenter kan agera med så lite ledtid som möjligt. Vid användande av vanliga webtjänster måste klienten aktivt fråga om ny data finns tillgänglig. I ett system med många användare slösas resurser på att hantera statusefterfrågningar. Istället för att klienten interagerar interaktivt med tjänsten, borde den istället reagera reaktivt. Med den reaktiva programmeringsmodellen stöds systemkonstruktion med dessa egenskaper. På .NET-plattformen tillhandahåller kodbiblioteket Reactive Extensions funktionalitet för att skapa reaktiva applikationer genom skapandet av funktioner som arbetar med asynkrona händelseströmmar. Biblioteket tillhandahåller kraftfulla verktyg för utformningen av reaktiva program, dock innehåller den inte en abstraktion för arbete med händelseströmmar som rör sig mellan olika processer, en nödvändighet för skapandet av distribuerade reaktiva system. Denna uppsats presenterar den bakomliggande designen och implementationen av ett ramverk för skapandet och användandet av observerbara webtjänster vars syfte är att brygga händelseströmmar mellan olika processer. Lösningen är baserad på en konceptuell modell som bygger på arkitekturen för webbtjänster. Den är implementerad som ett ramverk som består av två delar; en tjänstekomponent som används för att skapa observerbara webbtjänster och klientkomponent som ansluter till en observerbar webbtjänst och genererar kod som används för att prenumerera på händelser som exponeras av denna tjänst. Prenumerationsfunktionaliteten är skapad för att fungera med Reactive Extensions och gör det möjligt att bygga reaktiva och distribuerade system. Integrationstest används för att kontrollera att ramverket uppfyller de krav som anges för den konceptuella modellen.

The Stream API was added in Java 8. With the help of lambda expressions (anonymous functions), streams enable functional-style operations on sequences of elements. In this project, we evaluate how streams perform in comparison to imperative loops in terms of execution time, from the perspective of how streams are commonly used in public GitHub repositories. Additionally, two algorithms are implemented with and without streams, to assess the impact of stream usage on algorithmic performance. Parallel streams are only examined briefly due to their infrequent usage. We find that sequential streams in general are slower than imperative loops. However, stream performance heavily relies on how many elements are being processed, which is referred to as input size. For input sizes smaller than 100, most stream pipelines are several times slower than imperative loops. Meanwhile, for input sizes between 10 000 and 1 000 000, streams are on average only 39% to 74% slower than loops, and in some cases, they even slightly outperform them. Additionally, we observe that using streams when implementing algorithms in some cases leads to much slower execution times, while in other cases, it barely affects the execution time at all. We conclude that stream performance primarily depends on input size, presumably because of the high overhead abstraction cost of creating streams, but their performance also depends on other factors, such as operation type and pipeline length. / Med Java 8 introducerades streams. Med hjälp av lambda-uttryck (anonyma funktioner) möjliggör streams användandet av funktionella operationer på sekvenser av element. I detta projekt mäter vi hur streams presterar i jämförelse med imperativa loopar med hänsyn till exekveringstid, från perspektivet av hur streams vanligen används i publika GitHub-projekt. Parallella streams undersöks endast i begränsad utsträckning, på grund av hur sällan de används. Resultaten visar att streams överlag är långsammare än imperativa loopar. Skillnaden i prestanda beror dock starkt på indatastorleken, det vill säga hur många element som streamen bearbetar. För indatastorlekar mindre än 100 element är streams ofta flera gånger långsammare än deras imperativa motsvarigheter. Samtidigt är streams i genomsnitt endast 39% till 74% långsammare än imperativa motsvarigheter för indatastorlekar mellan 10 000 och 1 000 000 element, och i några fall är de till och med något snabbare än imperativ kod. Vidare observerar vi att användning av streams vid implementation av algoritmer i vissa fall leder till mycket längre exekveringstider, medan det i andra fall knappt påverkar exekveringstiden alls. Vi drar slutsatsen att prestandan av streams främst beror på indatastorlek, men också på andra faktorer, såsom operationstyp och hur många operationer som används i en pipeline.