回波总 - 为什么我不赞同你关于 ANTLR 不适合模板引擎的意见

原创
2019/12/22 10:45
阅读数 1.3K

波总好,

谈谈我对 JFinal Marketing 的一些看法那篇博文的评论中 我们谈论到了 ANTLR, 这里继续和波总谈谈在技术上我对这方面的理解.

先说下 ANTLR 到底什么. ANTLR 官网给自己的定义是:

ANTLR (ANother Tool for Language Recognition) is a powerful parser generator for reading, processing, executing, or translating structured text or binary files. It's widely used to build languages, tools, and frameworks. From a grammar, ANTLR generates a parser that can build and walk parse trees.

简单地说 ANTLR 是一个词法语法分析工具, 它不是一个应用层面的库, 也不是为应用程序开发使用的. ANTLR 的用户是需要定义某种语法, 并实现对该语法文件的解析的库开发者. 对 ANTLR 的应用场景在这篇文章中有更多的介绍.

下面列举几个使用 ANTLR 的项目:

波总在上篇博文评论中谈到:

antrl 会为你生成一个人类根本无法阅读的 parser,这个对于细致打磨是很有害的,因为你根本无法调试这个 parser,出了问题你也无法追踪。

所以波总认为:

我仅仅只是认为 antrl 用于模板引擎并不是个好主意,不是最好的方案,enjoy 的方案更好。 我从头到底都没否定过 antrl 用于别的领域,也没有说 antrl 有任何不好。

这个地方我觉得有点奇怪了, 使用 ANTLR 的直接结果就是生成 Parser, 不仅仅对模板引擎如此, 在所有使用场景下都是一样的. 如果因为"生成了一个人类无法阅读的 parser" 就否定 ANTLR 在模板引擎的应用, 那是不是也应该否定 ANTLR 在包括 Groovy 在内的其他项目中的使用呢? 因为他们也会毫无疑问使用 ANTLR 生成 Parser, 不是吗? 更有趣的是 ANTLR 的作者还专门使用了 ANTLR 开发了模板引擎 StringTemplate 作为 ANTLR 的 showcase, 难道他没有遇到这个 "生成一个人类根本无法阅读的 parser" 的问题, 所以不知道 ANTLR 用于模板引擎并不是个好主意吗?

在这里我的看法是 ANTLR 的生成结果 - 一个 "人类根本无法阅读的" Parser, 根本就不是拿来给人读的, 也不是用来让人直接"细致打磨"的, 从 StringTemplate, 到 twiter query language, 再到庞大复杂的 Groovy, 都不会有人在 ANTLR 的生成结果上做修改打磨, 就像没有人在 Javac 编译之后的字节码文件上做修改打磨一样, 这个 Parser 是一个中间结果, 对于这个中间结果的细致打磨当然应该回到 g 语法文件; 这个道理和 .class 文件中有问题应该回到原始的 .java 源代码去修改一样, 没有人会试图去"打磨"生成的 class 字节码, 对吗?

我并不是 ANTLR 专家, 连用户都算不上. 以上理解很可能有不足之处, 欢迎波总和使用过 ANTLR 的专业同行批评指正.

展开阅读全文
打赏
3
0 收藏
分享
加载中
为什么 antlr 用于模板引擎不是个好主意:
https://my.oschina.net/jfinal/blog/3146036
2019/12/23 02:11
回复
举报
感谢波总百忙之中抽出时间来回复
2019/12/23 04:36
回复
举报
看过波总的博文, 这里就这个话题打个总结吧. 首先波总的意见已经从 "为什么 ANTLR 用于模板引擎不是个好主意" 转换成了 "为什么 ANTLR 用于任何地方都不是个好主意". 其次波总就这个立论做出了比较详尽的阐述, 大赋也就这个立论做了反驳以及详尽的阐述. 我不是这方面的专家, 但也从中学到了很多东西. 从技术上讲我相信波总说的波总的道理, 大赋说的也有大赋的道理. 从沟通交流上来谈, 我认为问题的关键不在于谁的更有理, 而在这些不同的道理其实各自都有适用的 context, 有的 context 也许相互冲突导致用户会面临两难甚至多难选择, 也许不会所以用户可以做出一个更有针对性的选择. 从整个问题空间来看, 各种不同的选择都有存在的意义和价值. 每个人都可以做出自己的选择, 但同时应该尊重起码承认别人做出了不同的选择. 这是我的态度
2019/12/24 04:30
回复
举报
任何人的认知都是有局限性的,在我的认知之外必然会有使用 antlr 的优秀场景,所以罗总注意我博客第一句话中用的是 "多数" 这个词来做限定,我并没有使用 "所有" 来限定。 恰好我自己做过模板引擎,所以在 antlr 是否适合用于模板引擎这个认知上比一般人可能要高,这个标题是更恰当的选择。
2019/12/24 20:34
回复
举报
今天先回复这一个,真心没时间:
https://my.oschina.net/jfinal/blog/3146036
2019/12/23 02:06
回复
举报
支持波总观点,我同样不爱引入一些不太可控的东西。
如果天天都要给不同的语法做引擎,或者想快速验证语法,ANTLR是个好方案。
但是如果要深入细节打磨的产品,ANTLR生成代码相比于自己手工做Parser反而会增加开发成本。

但如果模板引擎如果是预编译型的,不会出现在线编译的场景,Parser的性能反而就不一定是首要打磨的重点了,用ANTLR也不一定不可取。

还有,无论是否编译型,如果对所需要实现的语法较为快速地写出Parser,那也不一定非要用ANTLR,因为多了一层抽象,也多了一层质量负担。
2019/12/22 17:42
回复
举报
不可控是一个主观概念, 对你我不可控, 不等于对其他人都不可控. 实际上 ANTLR 对我也不可控, 所以我没有引入到 Rythm 中. 这不是我认为其他使用 ANTLR 的产品都不可靠的理由, 再进一步说, 即便我内心这样认为, 怕也不会在自己的产品宣传上这样说.
2019/12/23 04:35
回复
举报
我说的不可控是在两个场景下相对手写来说,一是要细致打磨,一是自己能写parser。
2019/12/23 05:59
回复
举报
这都显而易见的,jfinal已经拿实打实的代码说明了。不太可控是基于它多加了一层抽象这一行为来说,就概率来说,抛开它本身经过多少测试云云,自己几百上千行搞定的事情,引入百多行的语法配置,和一个十几万行的包,哪个质量更不可控就不言而喻了。除非你为了快速实现,或者自己不会写parser。
2019/12/23 06:10
回复
举报
该评论暂时无法显示,详情咨询 QQ 群:912889742
同意大佬看法,不能说java生成的字节码不便于人阅读,java就不是一个好的语言。
不能说计算机使用0和1作为存储运算基本单元,不便于人的阅读,就说计算机不是一个好的工具。
也就好像说语文不是最好的表达方式,英国人看不懂,英语才是最好的表达方式。
关键在于人。
2019/12/22 13:22
回复
举报
更多评论
打赏
11 评论
0 收藏
3
分享
返回顶部
顶部