\noindent{}A goal shared between all programming languages is to provide a certain level of abstraction: an assembly language allows you to abstract from the binary instructions and memory positions; Low-level imperial languages, like FORTRAN, were the first to allow you to abstract from the processor architecture of the target machine; and nowadays writing a program requires little knowledge of the actual workings of the hardware on which the program is executed.

Freuder states that the ``Holy Grail'' of programming languages would be where the user merely states the problem, and the computer solves it and that constraint modelling  is one of the biggest steps towards this goal to this day \autocite*{freuder-1997-holygrail}.
Different from imperative (and even other declarative) languages, in a \cml{} the modeller does not describe how to solve the problem, but rather provides the problem requirements.
You could say that a constraint model actually describes the solution to the problem.

In a constraint model, instead of specifying the manner in which we can find the solution, we give a concise description of the problem.
We describe what we already know, the \parameters{}, what we wish to know, the \variables{}, and the relationships that should exist between them, the \constraints{}.

This type of combinatorial problem is typically called a \gls{csp}.
The goal of a \gls{csp} is to find values for the \variables{} that satisfy the \constraints{} or prove that no such assignment exists.
Many \cmls\ also support the modelling of \gls{cop}, where a \gls{csp} is augmented with a \gls{objective} \(z\).
In this case the goal is to find a solution that satisfies all \constraints{} while minimising (or maximising) \(z\).

Although a constraint model does not contain any instructions on how to find a suitable solution, these models can generally be given to a dedicated solving program, or \solver{} for short, that can find a solution that fits the requirements of the model.
