This is a program that executes and produces an output. It also has state - every step of executing that DSL is creating and manipulating a piece of state that builds up a declarative description of what the final output should look like.

The other thing you list, input, is optional. I write programs that don't take any input all the time. Monte Carlo simulation, for example. The entire demoscene is largely devoted to creating incredibly sophisticated programs that don't take any input. Postscript is a full, Turing-complete language whose primary purpose is to create programs that generally don't take any input

Programs that produce diagrams should be (and are) written in a programming language. They accept input, execute, and produce output. Diagrams themselves do not execute and have state (unless they are interactive[0]). There's a difference.

[0] https://app.ilograph.com

Be aware the poster has a history of being very active on posts related to diagramming tools to discourage his competitors' solutions and/or promote his own tool without disclosing affiliation.

My counterpoint would be: If you can write data visualizations with code, why not write diagrams too?

Why not write recipes in code too?

Or a screenplay?

(Because there are better formats for them)

Recipes absolutely should be written in code. If I could view source, copy the recipe yaml, and paste into my personal recipe manager app, it would be much more convenient.

Screenplays... are already written in code, partly. If they weren't, they'd include quotation marks and "she said" after every line.

I think this is too loose of a definition of code...

Yaml isn't really code in the same sense as python is, and Shakespeare didn't write in code in the same sense that the diagrams in this article are.

Well, you're right about that, but then they were your examples.

I think the counter-point to that would be that if you're writing infrastructure as code, and your architects are using a specific language anyways (Python in this case), it makes more sense for data governance and editing reasons to just keep things in the existent ecosystem and not worry about having to procure another license.

Vs. Cooking or Writing which aren't coding practices unto themselves.

How about music as code…Sonic-Pi would like to offer a counterpoint :)

https://sonic-pi.net/

You can do it, certainly, but it is overkill. It also limits your potential editors to people who know Python and are willing to install it on their machine. In contrast to Python (or other programming languages), a language like YAML or JSON can be learned in minutes by just about anyone.