CSS与Antlr的相似性

http://www.antlr.org/article/1136917339929/stringTemplate.html这篇文章分析比较了antlr和StringTemplatehttp://www.stringtemplate.org/，其中一段比较有趣，看起来CSS和Antlr还有一定相似性的。StringTemplate则类似于直接在HTML标签中嵌套修饰性标签（如</b>等）。

引用

HTML and CSS Analogy

The situation here is analogous to that with HTML and CSS, and I don't just mean in the way CSS separates the "view" from the "data". CSS is great because instead of embedding, say, "bold" tags inside every "code" tag, you can simply say "everything inside a "code" tag should be in bold", and you say that in just one place. But if you're generating the HTML pages, and you have a 10,000 line program that generates all the HTML, you're surely going to have some sort of START_CODE_STRING constant anyway, and you can easily change that from "<code>" to "<code><b>". The only advantage that staying with CSS gives you is that the CSS could be changed later, after compile time, perhaps even by the person reading the page.
But there is no equivalent advantage (that I can see) in the StringTemplate case. Using StringTemplate to translate C to Java, you'd end up with a simple call to doEverythingRelatedToFunctionDeclarations() inside your parser, and a simple call to showWhateverWasProducedByThatOtherCall() as your output specification.

Another way to look at it is this. Suppose your generated HTML page is extremely dynamic - its look can vary completely based on the input. So you have a huge program that generates the HTML. Does it really matter whether the program generates the entire HTML page vs. having an HTML page that has one huge JSP tag? If you really can specify "the look" all in HTML, and "the data" is all generated, that's one thing. But when you're doing high-level language translation and your output is, say, Java code, there is no clear distinction between "a look" and "data". It's all just "code"! In the HTML-generating situation, by the time you're generating almost the whole page anyway, there's no advantage to even having a little bit of static HTML wrapping all that generated code. And if you're going to have 10,000 lines of code that handles converting any C function call to some equivalent Java code, then does it even make sense to have a "process all function calls here" architecture? It would make more sense to have hundreds of pattern-matching rules: one that replaces printf() calls, another that replaces read() calls, etc.