<reponame>simonvandel/TLDR<gh_stars>1-10
%mainfile: ../master.tex
\section{Criteria for Language Design}\label{analsum}

This section will, in light of the preceding two chapters, \cref{part:analysis,part:analysis2}, settle on some criteria for TLDR. The criteria are inspired by those found in \cite{sebesta2015concepts}. However, only those characteristics which differentiate TLDR will be discussed, even though other characteristics will be present in the language.


\subsection{Simplicity, Orthogonality and Syntax Design}

In order to accommodate a user group with programming as a secondary skill set, TLDR should be simple. This would result in strict and straightforward rules regarding interactions. The language should try to keep simple rules regarding orthogonality as well, but not necessarily be highly orthogonal for that reason. The syntax design, should for these reasons, cater towards a mathematical perspective rather than a computer science perspective.

\subsection{Data Types}

Since the users of TLDR will typically have a background in mathematics, or require  the use of some mathematics in order to asses the value of any given result of a simulation, the language should strive towards having data types which allow for representation of traditional mathematical numbers.


\subsection{Type Checking and Exception Handling}

Due to the language targeting high performance computation, the language should try to avoid run-time errors, and catch problems as early as possible. This suggests a strongly typed language, but this will be elaborated further on in \cref{typesys}. For the same reasons, the language will not value exception handling, since edge cases should be fully encompassed in a simulation. However it is worth noticing that the actor model could require exception handling, if communication problems, caused by either race conditions or network conditions, should prove frequent.

\subsection{Readability over Writability}

TLDR values readability over writability, since the problems which the languages aims to support are usually big complex mathematical problems, which quickly can confuse the programmers, if they are not able to understand the code. The size of the problems will also likely popularise the use of external libraries, which will also benefit from readability, since an understanding of the functionalities supplied by a given library is useful when exploring which library best solves the problem.

