Gameplay programming is vital for video game development and benefits from good tools and techniques. However, techniques are still used in the industry that involves describing how the computer operates. Reactive programming is a way to describe eventful and stateful computer programs declaratively, focusing on what the program should accomplish. This thesis uses the reactive library UniRx with the game engine Unity 5 to create an FPS with reactive techniques, and discusses the advantages and disadvantages of these. Object-oriented reactive programming is used to combine reactive objects with Unity’s component-based framework without using wrappers for non-reactive objects. The results include static methods for observable user input, patterns when defining game components with reactive content, and communication between game objects through interface components. It can be concluded that reactive programming for game programming enables the programmer to describe and understand game logic in a declarative manner. However, combining UniRx and Unity 5 led to complex patterns. Suggestion for future work is using reactive programming with game engines that allows to design game objects that are fully reactive. / Gameplay-programmering är avgörande för utveckling av videospel och har nytta av bra verktyg och tekniker. Dock används tekniker i spelbranschen som kräver att programmeraren beskriver hur datorn utför uppgifter. Reaktiv programmering är ett sätt att beskriva händelserika och föränderliga datorprogram med fokus på vad programmet ska utföra. Denna avhandling använder det reaktiva biblioteket UniRx med spelmotorn Unity 5 för att skapa en FPS med reaktiva tekniker, samt diskuterar fördelarna och nackdelarna med dessa. Objektorienterad reaktiv programmering används för att kombinera reaktiva objekt med Unity’s komponentbaserade ramverk utan att använda wrappers för icke-reaktiva objekt. Resultaten inkluderar statiska metoder för observerbar användarinput, programmeringsmönster för definition av spelkomponenter med reaktivt innehåll och kommunikation mellan spelobjekt via gränssnittskomponenter. Man kan dra slutsatsen att reaktiv programmering för spelprogrammering gör det möjligt för programmeraren att beskriva och förstå spellogik på ett deklarativt sätt. Kombinationen av UniRx och Unity 5 ledde emellertid till komplexa mönster. Förslag till framtida arbete är att använda reaktiv programmering med spelmotorer som gör det möjligt att designa spelobjekt som är helt reaktiva.

Functional reactive programming (FRP) is a paradigm extending functional languages with primitives which operate on state. Typical FRP systems contain many dozens of such primitives. This thesis aims to identify a minimal subset of primitives which captures the same set of behavior as these systems, and to provide an axiomatic semantics for them using first-order linear temporal logic, with the aim of utilizing these semantics in formal verification of FRP programs. Furthermore, we identify several important properties of these primitives and prove that they are satisfied using the Coq proof assistant.

Reaktiv programmering är ett programmeringsparadigm som har utvecklats för att underlätta byggande av händelsedrivna reaktiva applikationer. Dess förespråkare hävdar att det kan leda till ökad kodkvalitet, men få studier har utförts för att underbygga dessa påståenden empiriskt. Denna studie syftade till att undersöka skillnaden i kodkomplexitet och kodläsbarhet mellan traditionell imperativ programmering och reaktiv programmering. En fallstudie utfördes där koden för ett befintligt öppen källkodsprojekt omstrukturerades, vilket resulterade i en imperativ version och en reaktiv version av samma kod. Verktyg för statisk källkodsanalys användes för att undersöka om några förändringar i kodläsbarhet och kodkomplexitet kunde upptäckas. Vidare diskuteras huruvida resultaten av den senaste teknikens läsbarhetsmätvärden ger en exakt förutsägelse av kodläsbarheten i reaktiva kodbaser, eller om kanske dessa mätvärden behöver modifieras för att göra dem tillämpliga på det reaktiva paradigmet. Våra resultat visar att läsbarheten påverkades negativt av reaktiv programmering när den mättes med senaste teknikens läsbarhetsmätvärden, men kodkomplexiteten minskades betydligt. / Reactive programming is a programming paradigm that has been proposed to facilitate building eventdriven reactive applications. It is claimed by its proponents to increase code quality, but few studies have been performed to substantiate these claims empirically. This study aimed to explore the difference in code complexity and code readability between traditional imperative programming and reactive programming. A case study was performed where the code of an existing open source project was restructured, resulting in an imperative version and a reactive version of the same code. Static analysis tools were used to investigate if any changes in code readability and code complexity could be detected. Furthermore, it is discussed whether the results of the state-of-the-art readability metrics give an accurate prediction of code readability in reactive code bases, or if perhaps these metrics need to be modified to make them applicable to the reactive paradigm. Our findings show that the readability was negatively affected by reactive programming when measured with state-of the-art readability metrics, however code complexity was decreased significantly

Concurrency in programming is a way of interleaving tasks in order to enhance the performance of an application. Previous research has found that concurrency errors are hard to avoid, hard to find, and that they often degrade performance of the application. Reactive programming provides an abstraction, to make it easier to implement complex concurrent and asynchronous tasks. When programming reactively in Java, it is often done with a reactive framework, where RxJava and Project-Reactor are two of the more popular choices. Blocking a thread that is not supposed to be blocked will result in concurrency errors, without the Java compiler providing a warning. In order to find incorrect blocking, a tool called BlockHound can be used. BlockHound wraps the original code, intercepts any blocking calls, and provides an error if the blocking call was used incorrectly. In this study, BlockHound was used to detect erroneous blocking calls in open source projects which use RxJava or Project-Reactor. A JavaAgent was created to automate the process of adding BlockHound to a project. The selection of projects to test was done by evaluating the community usage, and selecting the projects with the most amount of stars and forks, as this indicates that the projects are widely used. The projects were tested with BlockHound, and the errors were saved to external log files for analysation. The study found that a considerable percentage of the projects investigated exhibited blocking violations. These violations were all caused by a low number of system calls, made from methods in threads that forbid blocking. Generalizable solutions to the violations were applied, and considered successful. / Samtidighet (concurrency) inom programmering är ett sätt att kombinera olika uppgifter, för att få utökad prestanda i ett program. Tidigare forskning har visat att concurrencybuggar är svåra att undvika, svåra att upptäcka och att dem ofta försämrar programmets prestanda. Reaktiv programmering skapar en abstraktion som gör det enklare att implementera komplexa samtidiga och asynkrona uppgifter. Reaktiv programmering i Java används ofta med hjälp av ett reaktivt ramverk, där två av de mer populära är RxJava och Project-reactor. Att blockera i en tråd som inte tillåter blockering kommer skapa concurrency buggar, som Javas kompilator inte varnar för. För att upptäcka felaktiga blockeringar kan ett verktyg som heter BlockHound användas. BlockHound omsluter den ursprungliga koden, fångar eventuella blockeringar, och skickar ett felmeddelande om en felaktig blockering har upptäckts. I den här studien har BlockHound använts för att hitta felaktiga blockeringar i open source projekt som använde sig av antingen RxJava eller Project-reactor. En JavaAgent skapades för att automatisera processen att lägga till BlockHound i projekten. Processen att välja projekt för testning gjordes genom att utvärdera hur stor användningen av projekten var, samt genom att välja de projekt med mest antal stjärnor och forks, eftersom de ger en bra indikering på att projekten används brett inom området. Projekten testades sedan med BlockHound, och loggarna sparades manuellt till externa loggfiler för analys. Studien fann att en betydande procent av projekten som undersöktes innehöll felaktiga blockeringar. Orsaken till dessa var ett fåtal systemanrop som kallades från trådar som inte tillåter blockering. Generaliserbara lösningar till dessa buggar testades, och ansågs vara lyckade.

Le web est une plate-forme universelle pour développer des applications riches en interactions avec les utilisateurs et des services distants. Ces interactions sont implémentées sous forme d’évènements asynchrones pouvant survenir à n’importe quel instant de l’exécution de l’application. JavaScript, le langage du web, gère les évènements asynchrones de façon peu abstraite, ce qui rend l’écriture, la vérification et la maintenance d’applications interactives difficile. La contribution de cette thèse est l’élaboration et l’implémentation du langage Hiphop.js qui dote JavaScript d’abstractions de plus haut niveau pour gérer les évènements asynchrones. Hiphop.js est une implémentation JavaScript de constructions temporelles du langage réactif synchrone Esterel. Grâce à ces constructions, le flot de contrôle d’une application Hiphop.js est explicite. Il est donc possible de savoir précisément quand et sous quelles conditions un évènement est traité par simple lecture du code source de l’application. Ceci facilite la vérification et la maintenance de l’application. L’intégration profonde du langage Hiphop.js avec l’environnement dynamique du web est une part importante des travaux entrepris dans cette thèse. Les programmes sont construits et compilés pendant l’exécution de l’application JavaScript ce qui permet d’adapter automatiquement le traitement des évènements asynchrones en fonction des changements de l’environnement au cours de l’exécution (par exemple, la connexion ou déconnexion de participants pendant une visioconférence). / The web is an universal platform used to develop applications interacting with users and remote services. These interactions are implemented as asynchronous events that can be fired anytime. JavaScript, the mainstream language of the web, handles asynchronous events using low-level abstractions that makes it difficult to write, verify, and maintain interactive applications. We have addressed this problem by designing and implementing a new domain specific language called Hiphop.js. It offers an alternative to JavaScript event handling mechanism by reusing temporal constructions coming from the synchronous programming language Esterel. These constructions make the control flow of the program explicit and deterministic. Hiphop.js is embedded in JavaScript and suits the traditional dynamic programming style of the Web. It is tighly coupled to JavaScript with which it can exchange values and access any data structures. It can also support dynamic modifications of existing programs needed to support on-demand download on the Web. It can run on both end of Web applications, namely on servers and on clients. In this thesis, we present Hiphop.js, its design and implementation. We overview its programming environment and we present the prototypical web applications we have implemented to validate the approach.

In today’s society the need for more hardware efficient software since some people think that the doubling of computer power for the same price that Moore’s law predicted is no more. Reactive programming can be a step in the right direction, this has led to an increase in interest in reactive programming. This object of this thesis is to evaluate the possibility of using reactive programming and R2DBC in Java to communicate with a relation database. This has been done by creating two Spring applications one using the standards JDBC and servlet stack and one using R2DBC and the reactive stack. Then connecting them to a MySQL database and selecting and inserting values in to and from it and measuring the CPU usage, memory usage and execution time. In addition to this the possibilities to handle BLOBs in a good enough way were researched. The study shows that there are both advantages and disadvantages with using R2DBC it has basic support and it is based on good idea but at the time of this thesis it still needs more development before it can be used fully.

Software performance is of interest to all who want to lower their hardware costs and provide services with speedy responses to users, to this end reactive programming can be employed. Therefore it is important to measure the performance of tools such as reactive frameworks and to compare and contrast them with each other in order to improve the development of these tools, and help provide developers with the information they need when searching for a reactive framework that suits their project. To achieve this the study will aim to indicate the reproducibility of the research on reactive framework performance conducted by Ponge et al. on three commonly used reactive frameworks. Further, a root cause analysis to identify the sources of the identified bottlenecks will be carried out and complemented by suggestions for improving the performance of those parts in the reactive frameworks that are causing performance issues. An analysis of how performance correlates with the cyclomatic complexity of the frameworks will also be presented. We find, that in some test cases, the performance of the frameworks differs depending on the machine used, and that the latest framework versions do not show a marked performance increase. Further, we discover hotspots in the Mutiny framework and reason about potential synchronization bottlenecks. We attempt to find a novel use case for cyclomatic complexity as an indicator for performance but find that no correlation exists between cyclomatic complexity and performance for reactive frameworks.

Previous research has shown that the reactive paradigm is suitable for programming by voice, due to its frequent use of expressions used in common English. However, the software used in the previous research (Talon) does not support reactive programming. To our knowledge, no other programming-by-voice software has built-in support for RxJava. The main focus of this study is the development and testing of a vocal programming environment that recognizes RxJava operators and commands. This is done by writing custom scripts that form a RxJava-adapter for a software called Serenade. The purpose of the adapter is to determine to what degree customization can improve the programming-by-voice experience, in terms of reduced cognitive and vocal load. The testing process also reveals challenges related to programming-by-voice in reactive Java, as well as challenges related to creating custom voice commands for Serenade. The results indicate that Serenade is superior to Talon, requiring on average 45\% fewer words to produce the same code. When the default version of Serenade is compared to the custom version with custom voice commands, the improvement is 19\%. The study also concludes that there are many challenges facing speech recognition when used in a programming environment. The custom script feature in Serenade, while still having some limitations, is advanced and allows the user to create complex custom voice commands.

Functional and reactive programming patterns provide powerful sets of tools for dealing with complexity and scalability. These stand in stark contrast to the imperative programming patterns which permeate the industry. This report seeks to investigate the extent to which a set of common imperative programming languages can be used to implement such functional and reactive patterns, and what the implications of doing so are. This is done by implementing and using a framework based on such patterns in Java, Kotlin, Objective-C, and Swift. The results show that this is possible in all of these languages, but the extent to which this can be considered idiomatic is questionable. Upholding immutability and referential transparency is highlighted as the main source of concern in this regard. / Funktionella och reaktiva programmeringsmönster förser utvecklare med kraftfulla abstraktioner för att hantera komplexitet och skalbarhet. Dagens industri förlitar sig dock till en majoritet på imperativa programspråk, där dessa mönster inte nödvändigtvis kan utnyttjas. Syftet med denna rapport är därför att undersöka hur sådana mönster kan tillämpas i imperativa programspråk. Detta görs genom att studera implementationen och användandet av ett ramverk för funktionell och reaktiv programmering i fyra programspråk: Java, Kotlin, Objective-C och Swift. Rapporten finner att de mönster undersökta i denna rapport går att implementera med existerande språkfunktioner för alla dessa språk, men frågan om detta kan anses idiomatiskt är oklar. Det huvudsakliga problemet är att säkerställa att funktioner skrivs utan sidoeffekter och att datastrukturerna som används inte är muterbara.

Functional Reactive Programming (FRP) offers a declarative way to express reactive systems such as animations, user interfaces and games. Various topics related to FRP like optimization, generalization and debugging were studied. However, the use of FRP in distributed systems has not been investigated extensively. Focused on the use of the Dunai FRP library implemented in the Haskell programming language, the aim of this thesis is to develop and evaluate a way to apply FRP to distributed systems. A library is implemented to extend Dunai with means to create distributed systems. There is support for the Client/Server network architectural model and algorithms to synchronize applications across a network. As the synchronization of distributed systems has been a topic of research for decades, this thesis explores whether developed ideas, such as Time Warp (Jefferson, 1985), can be expressed in FRP. Additionally, Client Side Prediction (Bernier, 2001) and Dead Reckoning (DIS Steering Committee, 1994) are used to predict server reactions on client-side. An exemplary application demonstrates the implementation. The application is then evaluated in a performance test and a user test. TimeWarp synchronization has a significant impact on performance. Despite this, the application is playable up to a latency of 100 ms. The result of Dead Reckoning is acceptable, whereas Client Side Prediction is not usable. The thesis shows that the developed way can be used to run FRP on distributed systems. Further work should focus the performance to enable more complex applications. Moreover, Dead Reckoning can be improved to a smoother result. Non-trivial changes are necessary to make Client Side Prediction usable.:1 Introduction ... 1 2 Functional Reactive Programming ... 4 2.1 The Arrow Type Class ... 5 2.2 The Dunai FRP Library ... 7 2.2.1 Monadic Stream Functions ... 7 2.2.2 Combining Monads ... 8 2.2.3 Monads in Monadic Stream Functions ... 9 2.3 The BearRiver FRP Library ... 10 2.4 Executing FRP ... 11 3 Synchronization of Distributed Systems ... 13 3.1 Distributed Systems ... 13 3.2 Consistency of Distributed Systems ... 14 3.3 Client/Server Architecture ... 15 3.4 Time Warp Synchronization ... 16 3.5 Dead Reckoning ... 17 3.6 Client Side Prediction ... 19 4 Cloud Haskell ... 21 4.1 Exchanging Messages ... 22 4.2 Fault Tolerance ... 23 4.3 The Cloud Haskell Platform ... 23 5 Concept ... 25 5.1 Concept of the Implemented Library ... 25 5.2 Concept of the Sample Application ... 27 5.3 Functional Requirements ... 28 5.4 Non-Functional Requirements ... 30 6 Implementation ... 32 6.1 Client/Server Architecture ... 33 6.1.1 Establishing Connections between Clients and Servers ... 33 6.1.2 Distributed Execution of FRP ... 35 6.1.3 Implementation of Servers ... 36 6.1.4 Implementation of Clients ... 38 6.2 Time Warp Synchronization ... 39 6.2.1 Rollbacks of Monadic Stream Functions ... 39 6.2.2 Executing FRP using Time Warp Synchronization ... 41 6.3 Dead Reckoning ... 45 6.4 Client Side Prediction ... 46 7 Evaluation ... 48 7.1 Evaluation of Functional Requirements ... 48 7.2 Concept of the Performance Test ... 52 7.3 Concept of the User Test ... 53 7.4 Results of the Performance Test ... 54 7.5 Results of the User Test ... 56 8 Summary ... 60 Bibliography ... A Listings ... M List of Figures ... O List of Tables ... P Glossary .. Q Abbreviations ... U