represent a graphical user interface with which the user interacts, while the controller mediates between those two to keep them separated. In TOP and TOSD, both model and view can be readily recognised. The result of the Domain Modelling phase can be seen as the application’s model, while the optionally customized GUI can be seen as the application’s view. Identifying the controller is less obvious. In a sense, editors can be seen as generic controllers that automatically mediate between model and view. We choose to not describe TOP as an MVC framework, because one does not implement controllers whilst doing Task-Oriented Programming.
7.5
Conclusion and Future Work
We have shown a systematic approach, called TOSD, to developing a complex, multi-user TOP program. TOSD is enabled by the fact that we can neatly separate various aspects of an application. This same separation of concerns also enables a flexible approach to applying TOSD. The individual phases do not have to be applied in a fixed order. As a consequence, the TOSD approach, and by extension TOP, can be used in any software- engineering approach, be it agile or a more traditional waterfall.
Section 7.3.1 and Section 7.3.3 discuss the ability to place and connect devices, and then reason about the impact of damage on the availability of these devices. This ability is still in an early form. More sophisticated reasoning that includes support for redundant systems and reasoning about amounts of resources is required to make this feature more realistic and usable in a real-life situation. Additionally, a fire in a room may have consequences outside of that room as well. An adjacent room may contain ammunition or other explosives, for example, increasing the priority of putting out the fire quickly. We want to add this kind of information to the application as well.
In collaboration with the Royal Netherlands Navy, we aim to interface the prototype C2 application with real ship’s systems. Doing so allows us to access real sensor data and reason about real-life FFDC scenarios. This can make the application usable in real-life FFDC drills.
TOSD can currently only be applied by manually ensuring that the various con- cerns are separated. We are currently studying context-aware IDEs, which could aid in structurally applying TOSD during task-oriented programming.
Chapter 8
Conclusions
For this thesis we set out to create a prototype of a part of a C2 system using a wide array of functional programming tools. At the centre of our tool set sits iTasks, an implementation of the TOP paradigm in Clean. Along the way towards the C2 prototype, we have significantly expanded and improved our collection of tools.
Tonic, which implements the concept of blueprints, is the most significant new tool in our tool set. Blueprints are graphical representations of the monadic structure of code. We have seen how to generate both static and dynamic blueprints for a large class of programs and which challenges are encountered in the process.
In the process of learning how to draw the blueprints we generate from code, we developed a novel way to draw Scalable Vector Graphics in a web browser. From this graphics language we later extracted a powerful layout language that can be used in mul- tiple di↵erent domains, including the layout of tasks. With this new layout language, we were able to maintain separation of concerns in the implementation of iTasks programs. In this chapter we first evaluate several aspects of blueprints in Section 8.1. We define more clearly what blueprints are not, after which we make a first attempt at validating the usefulness of blueprints. Next, we give an overview of the potential future applications of blueprints in Section 8.2. We then discuss graphics and layout in Section 8.3, after which we discuss separation of concerns in Section 8.4, and applications in C2 in Section 8.5. Finally, we wrap up in Section 8.6.
8.1
Blueprints
In this section we evaluate the concept of blueprints. It is important to realise what blueprints are not, namely a way to do visual programming. Next, we reflect on to whether blueprints succeed in their aim to improve understanding of monadic code. Lastly, we look at how blueprints can be used in Haskell.
8.1.1
Generating Blueprints
Chapter 5 showed how blueprints can be generalized to visualize any monadic program. To do so for static blueprints, a notion of sequential composability of computations is all that is needed, which is what is provided by the monadic bind combinator. We can generate static blueprints for all monadic programs. This is even true for types that have been implemented as a monad, but do not adhere to the monad laws.
Dynamic blueprints are not so easily generalized in a lazy language, however. The order in which blueprint nodes are highlighted, must match the intuitive notion of “the right order”. I.e., a bind’s left-hand computation must intuitively be highlighted before its right-hand side computation. Highlighting only happens when a computation is fully evaluated, so for successful highlighting, the left-hand side must be evaluated before the right-hand side. This is not always the case in a lazy language. In fact, a bind’s arguments do not necessarily need to be evaluated completely at all. After the evaluation of a bind,
the only thing we know for certain is that the bind’s left-hand side argument is reduced to weak head normal form (WHNF). We also know that if a bind’s right-hand side argument is (partially) evaluated, the left-hand side argument has to have been reduced to WHNF first. Hence, the blueprint arrows signify the order in which monadic computations are reduced to WHNF.
Due to lazy evaluation, the order of evaluation is in general hard to predict. Compiler transformations may influence the evaluation order as well, complicating the situation further. To ensure that monadic computations are reduced in a particular order, it is necessary to thread a state through the monad. In other words, state monads [103] can successfully be visualized dynamically. This is because a computation in a sequence of state-monadic computations requires the state from the previous computation as input, forcing its evaluation first before being evaluated itself. Indeed, both the Task and the IOmonads are state monads and we have seen that both can successfully be dynamically visualized.
8.1.2
What Blueprints are Not: Visual Programming
Visual programming is programming by using graphical elements as building blocks. One way to implement visual programming is by o↵ering a completely graphical language (e.g. Scratch [91]). Another way is to o↵er a graphical modelling formalism from which high- level code is generated (e.g. UML).
Visual programming is often proposed as a way to enable people without program- ming experience to code [94]. A common sentiment seems to be that one need only find the right graphical syntax for this to succeed. This notion disregards the fact that programming is an inherently creative process [49]. Even with the help of graphical formalisms, programming still requires one to be able to think computationally and al- gorithmically. No graphical formalism will instantaneously teach someone to do so.
Tonic is explicitly not aimed at being a visual programming language. With Tonic, code is written first, and only then are blueprints generated. With this approach, textual programming and visualization are used in synergy, as also proposed by e.g. Petre [79]. We do hope that graphical formalisms such as Tonic will lower the barrier for people to take up programming, and possibly enable them to learn faster by being given visual feedback.
8.1.3
Validating Blueprints
In the Tonic papers, we suggest that Tonic’s blueprints may make it easier to communi- cate with domain experts, because the images are more intuitive and less intimidating to them than Clean code. While we have not performed a formal study with domain experts to verify whether this is actually true, we did perform a case study [97] to find out how Tonic is received by bachelor students in the second part of an introductory functional programming course. Like domain experts, these students have little to no experience with monadic programming, although they have been exposed to basic functional pro- gramming concepts in the first part of the course. During this course, the students are introduced to the concept of monads for the first time. Traditionally, the students find monads one of the hardest concepts in this course. We wanted to find out whether Tonic could help with learning about monads, because blueprints could potentially aid visual learners in understanding the course contents better.
Blueprints had a mostly positive impact. In general, students indicated that blueprints helped them to understand both the slides and the exercises. The students found