Visitor leads to the wrong organization of code for processing AST&#x27;s. It&#x27;s better to simply have big case statement on the types of nodes you have to process.  Here is why. The case statement puts together pieces of code that are related. The method framework, by contrast, puts together pieces of code which do unrelated things, which are only connected by the fact that they apply to the same kind of node. This helps you slightly if you&#x27;re adding a new kind of node, but not if you want to understand at a glance how the same kind of process is orchestrated over forty different nodes: for that, it&#x27;s better to be staring at a case statement. I want to see all the ways that forty different nodes are subject to type checking; I don&#x27;t want to see, simultaneously, how a single node is type-checked, pretty-printed, traversed for constant folding, code-generated.<p>That kind of organization really works well when you don&#x27;t care about the other classes which do that, like device drivers. I don&#x27;t care about how a tty handles write when I&#x27;m working on a network stack&#x27;s write; I don&#x27;t need to see those side by side.<p>Thus even if you give me a language with real OO that has multiple dispatch so that Visitor disappears, I still won&#x27;t do it this way. I&#x27;m going to have a single AST pretty printing function that handles all the cases, a code generating function that handles all the cases and so on.  If someone adds a case, they will just have to add them to half a dozen functions.