The meaning of a diagram is largely conveyed by relative relationships rather than absolute coordinates. Moreover, diagrams are often underconstrained: relationships needed to convey the intended meaning determine a family of possible solutions, rather than a single unique diagram.
Style takes a constraint-based approach to graphical specification in the spirit of Sketchpad [Sutherland 1964]: diagrams are built up from hard constraints that must be satisfied and soft penalties that are minimized, then unspecified quantities are solved for via numerical optimization. You don't have to provide absolute coordinates as in imperative languages like PostScript or OpenGL. Though an implicit specification can make output more varied, part of the allure of Penrose is the potential to find interesting or surprising examples. Moreover, the approach yields more concise code; for instance, Style programs are much shorter than the SVG files they produce.
An alternative design might be to use an application programming interface (API), though historically APIs have been eschewed for specification languages for good reason. Language provides far more concise expression of complex relationships—imagine styling an entire website via the DOM API’s getElementById() and setStyle() methods, versus a few short lines of CSS. Visual programming languages (like LabView [Elliott et al. 2007] or Grasshopper [McNeel et al . 2010]) might suffice for basic specifications (e.g., vectors should be drawn as arrows), but don’t scale to more complex concepts that are easily expressed via language [Burnett et al. 1995].
A key design challenge is identifying objects that appear in a Substance program. Objects in a given mathematical universe are distinguished not only by their type, but also by their relationships to other objects. A widely-used mechanism for specifying such relationships is through CSS-like selectors. Style adopts a similar mechanism that performs pattern matching on the types, functions, and predicates appearing in a Domain schema.