A better question would be, why yet another C knockoff on top of XML bloat? It just seems so uninspired. 3D drawing ought to be a slam-dunk for a dedicated DSL: pure functional composition (objects described in terms of relationships with each other), homoiconic (so code can generate code directly; no need for XML middleware makework).

Plus pure FP code should time-independent in its evaluation, so it doesn’t take a genius to imagine the benefits of (safely!) introducing a time axis on top of that. Procedural generation, animation; great potential there.

This is not all idle speculation, BTW: I wrote a semi-declarative DSL for 2D artwork production that blew its traditional imperative rivals out of the water while also being easy enough for non-programmers to use. So I know there’s potential there, and I’d be fascinated to see what kind of language someone with a mind for 3D math could shape for the task. Plus as a trained sculptor turned automation junkie who can’t stand GUI-based 3D drawing apps (they just don’t fit my head), I’d love to try something with a language-based interface instead.

See also:

- PostScript, a complete concatenative programming language for 2D drawing (incidentally, Adobe used to do a vector-based 3D drawing tool too: https://web.archive.org/web/19991127092153/http://www.adobe....)

- Alan Kay’s Maru/Nile/Gezira stack (or how to write a full 2D graphics engine in 500LOC: https://news.ycombinator.com/item?id=10540031).