The history

The beginnings of AMLs were simply as the soft-layer of a solver, which is still being referred to as just code.

The main advantages were:

• Using the solver without recompiling it (i.e., being the soft scripting layer on top).
• A human-understandable notation for LPs (in particular omitting zeros).
• A small scripting layer to read input, drive the solving process and format and display output.

Quickly algebraic modelling languages acquired several other features:

• The modern algebraic notation for core problem statements and the split into: indices, parameters, decision variables, constraints and objective.
• A split between model files (containing the above and logic) and data files. This allowed for reuse
• Linking the same AML against different solvers, allowing for solver-independence.

Somewhat later there appeared in place of data files a lot of different in-/output options: different file formats, database connectors, …

After 2000

The only new thing appearing after 2000 seems to be the possibility to create visual user interfaces for models with certain annotations.

How much of that is still an advantage in 2020+?

Given a choice of programming stack (i.e., C or related, JVM based, .NET based, Python, …) there is at least one solver-independent API availabe.

• This allows writing the core model as a reusable function in math-like notation.
• All the other things: io-handling, visualisation, orchestration are done easier in your programming stack of choice.
• Documentation generation is a split thing: with programming language tools it is easy to document data (like a structure containing all decision variables), but there is a challenge documenting expressions themselves. And there are implementation concerns leaking into the model description.
• The remaining AML advantages are: stack-independence, model documentation and high-level generation of code/UIs.
  • The procedural parts of an AML are an obstacle complicating analysis of the model.