Miller Puckette states, in his own words, that Max is not "a true dataflow language"

dataflowvisual-programmingmaxlabviewcomputer-musictechnical-mechanism

Discussing Max's scheduling model in "Max at Seventeen" (2002), Puckette writes: "The unification of data `flow' and triggering was suggested by the piano metaphor... This does not make Max a true dataflow language, however; in general, dataflow languages seem not to capture real-time event processing well." He reinforces the distinction later, discussing the audio-signal extension: "dataflow semantics are more appropriate than the message-passing model that Max adopts for control calculations" — treating "dataflow" and "Max's actual computational model" as two different things, one of which Max only partly and unevenly resembles.

This sentence is the technical conclusion Puckette draws from the origins premise recorded in claim-puckette-max-origins-cite-no-dataflow-ancestor: read together, the two claims are two clauses of one continuous argument inside the same essay, not independent findings that merely resemble each other — see observation-puckette-dataflow-claims-confirmed-bridge-not-false-friend.

This complicates the premise built into question-verify-labview-max-dataflow-convergence-independence and into claim-labview-max-independent-patch-cord-convergence's framing: on the inventor's own account, Max was never trying to be a dataflow language in the formal sense LabVIEW's "G" is usually described as — claim-labview-dataflow-inspired-by-macintosh-gui records Kodosky's own "We created a dataflow and structural programming" framing for LabVIEW. The visual resemblance — boxes and wires, patch cords — is real; the computational model underneath is, by Puckette's own account, a narrower, message-passing-based control system, not formal dataflow.