At first I thought that it's data-driven in the same sense that Lisp is. The concept describing Lisp's phenomenon is called Homoiconicity [0], or "code as data"

At first I thought that it's data-driven in the same sense that Lisp is. The concept describing Lisp's phenomenon is called Homoiconicity [0], or "code as data", but Homoiconicity means that "all code can be accessed and transformed as data, using the same representation". Emphasis mine. A lisp program could transform its own representation, because it's just a list of lists; but, a "noodle graph" programming system doesn't necessarily have the ability to parse its own structure; but I guess it could, all that is really needed is for the program to be treated as data, as in something the program itself could manipulate. I guess that's the meaning of data, something a program in question could potentially manipulate; and that's the difference between "data-driven" (or homoiconic) and code-as-code programming: the code-as-code program can't manipulate its structure as a first-class citizen. I started out saying that a data-driven program isn't necessarily homoiconic, but I'm finishing with the realization that it is, they're synonyms. Also, I'll add that data-driven doesn't contrast with programmer-centric workflow, because it's still programming, that hasn't changed. The question is what you're programming with. [0] https://en.wikipedia.org/wiki/Homoiconicity https://en.wikipedia.org/wiki/Homoiconicity