Build systems speed up builds by reusing build step outputs from previous builds when possible.
This requires precise definitions of the dependencies for build steps.
PIE is a build system with precise dependencies, but its task definitions in Java are verbose.
The PIE DSL allows pipeline developers to write concise definitions of PIE tasks, but the PIE framework has evolved and the PIE DSL cannot express many tasks and projects.

This thesis presents PIE DSL 2, which improves on PIE DSL 1 in three areas.
It extends the language itself with a module system, generics and support for suppliers and injected values, which allows it to express more tasks within the DSL.
There are four improvements for the code base.
The first two are a specification of the static semantics in Statix and a new compiler backend that compiles to an AST instead of using string interpolation, both of which extend the features for the DSL that can be expressed.
The second pair is constructors for semantic types and tests, which improve development speed of the DSL.
The final area we improve is the user experience, which we improve by adding documentation for expressions and types in the PIE DSL.

We compare PIE DSL 2 to Java in a case study.
Only a single task can be expressed in the DSL, which means that the boilerplate is not reduced.
Furthermore, the Java ecosystem has better error detection except for nullability.
Finally, the PIE DSL is simpler than Java, but only when the full pipeline is supported by the DSL.
We conclude that the DSL is not better than Java for full projects yet, but for tasks that it can express it is a slight improvement over Java.
This leads to the hypothesis that it has potential to become better if it can express enough tasks.

Due to time constraints, the case study did not use the latest version of the DSL.
In theory the latest version of the DSL can express 11 of the 19 tasks, but this has not been verified experimentally.

Overall, this thesis makes improvements to the PIE DSL and its environment, but that has not translated to the DSL being better than Java.

This report describes the Bachelor End Project, a compulsory course for the Bachelor Computer Science at Delft University of Technology. This course has a group of 4 students complete a project for a real-world company (the client). The client for this project was Relive, a company that has a tracker for outdoor activities with a focus on the experience of the activity. They wanted a route recommendation engine for their users, in particular users that are unfamiliar with the area. The specific task from Relive was to use the Relive database to find popular, dissimilar routes to recommend within an area, and then find context for those recommended routes. The first attempt to find these routes was using a heatmap to see which routes were popular, and then clustering routes to find dissimilar routes to recommend. This had some problems with unwanted biases towards cities, so the second attempt switched it around by first clustering on general area to make sure recommendations are dissimilar, and then using clustering and finding big clusters to see which routes are popular. This last approach worked decently: it can recommend 73% of the expected routes. One of the key problems for now is the long waiting times. There were two kinds of context that were considered: keywords and photos. Keywords can be extracted by processing titles from nearby routes with significant search. Photos are added to routes by the users but may not be relevant as context. Examples of such useless photos are selfies, which also bring privacy concerns. Due to time constraints, giving context was not integrated into the final product. The final product is a web application client and a server for that client. The users interact with the web application, and the recommendation algorithm is run on the server.