The dynamic semantics of a programming language formally describe the runtime behavior of any given program. In this thesis, we present Dynamix, a meta-language for dynamic semantics. By writing a specification for a language in Dynamix, a compiler for the language can be derived automatically.

Dynamix specifications compile source programs to the Tim intermediate representation, a language-agnostic target IR designed to be able to be efficiently interpreted or compiled. Dynamix and Tim make use of the continuation-passing style to abstract over control flow, giving language developers fine-grained access to control flow primitives in their specification. A novel abstraction in Dynamix allows the construction of these CPS terms without the traditional friction involved. Dynamix is fully typed and integrated within the Spoofax language workbench. This allows language developers to interact directly with other parts of the workbench, including automatic type signature generation and the ability to query the results of static analysis.

Through case studies for miniStratego and ChocoPy with exceptions, we show that Dynamix is capable of succinctly representing a wide range of source language features and paradigms. Current performance is acceptable, with the foundations for a future efficient compiler for the Tim IR already in place.

It has become a common practice for software developers to analyse monitoring data as a means to understand issues, trends and performance of large-scale software systems. The combination of this practice with the software development workflow can however be cumbersome at times. One recent effort into evaluating the effects of integrating monitoring directly into the software development workflow has been done at the large-scale payment company Adyen in cooperation with the TU Delft. This project is a new attempt at making a flexible, open-source and useful monitoring tool based on the results of that research effort. This report will detail how the system is designed, implemented and the development methodology that was used for its creation. After researching popular monitoring stacks and solutions, an architecture for the Hyperion pipeline was designed that would maximize compatibility with logging setups. The monitoring data is first retrieved from a log source like Logstash or Elasticsearch. It is preprocessed by a pipeline consisting of configurable and flexible plugins. A large range of plugins is supported: functionalities include debugging, transformation, load balancing, and adding new data from third-party systems. There is also extensive support for third-party developers to create their own pipeline plugin to manipulate data in any way required, which allows Hyperion to account for unconventional logging setups. The pipeline typically ends at some type of aggregator, which exposes an interface for developer tools to retrieve metrics. These metrics can be queried with the Hyperion IDE plugin, which visualizes them in the development environment itself. To verify that the designed Hyperion pipeline adheres to the requirements defined in the research report, validation tests have been performed on every module of the system. All code is extensively tested with unit, integration, and container-based system tests. An evaluation of the performance of the pipeline additionally verified the scalability of the system even when provided with a large number of incoming logs. Finally, in order to ensure easy extension and adoption of the Hyperion pipeline a large amount of documentation was written, that explains the architecture of the project and how a third-party developer can adjust and extend it.