Fear of parsers?
Martin Fowler posts a lot about DSLs these days. In a recent post about ParserFear, he comments on an apparently typical reaction against creating one's own DSLs. That reaction seems to be that parsers are hard to write, and that it's easier to use XML instead because with XML, you get the parser for free. Martin Fowler then continues to explain why in his experience, parsers are not hard to implement, by contrasting a specific XML case with an alternative design using Antlr.
I think he misses the point, though. It's indeed the case that, taken by themselves, parsers are not very hard to write, especially if you stick to simple grammars. However, they could just be a too high investment for too little return.
This reminds me of a different story: A couple of years ago, Erich Gamma answered a few questions about patterns in one of his talks. One question was about which patterns he would not include anymore in the Design Patterns book. Among others, he mentioned the Singleton and the Visitor pattern, and his explanation for not including them was that he deems them too complicated.
Most people react puzzled when they hear this story. Yes, everybody who has tried to implement visitors knows that they are quite complicated, but in contrast, singletons seem extremely simple and straightforward to implement. However, the major point here is that they are too complicated for what they achieve: A singleton only guarantees that you get exactly one instance of a class, not more, not less. You might as well just introduce a global variable with that one instance and don't bother going through the minutiae of implementing the Singleton pattern correctly (which has border cases that you can get wrong after all, depending on what language you have to implement it in).
That's the major point: The effort has to be compared against the benefits you achieve. The same holds for writing parsers for DSLs. A domain-specific syntax simply doesn't buy you that much, but just creates another layer of code that needs to be maintained and can create follow-up problems, for example, when the syntax you designed happens to be too inflexible to be adapted to change requests in future versions of your code.
This is also the main reason why Lispers like s-expression. The rules for s-expressions are extremely simple, but at the same time also very flexible: The first element in a list determines the meaning of an expression, and all other elements are interpreted in terms of that first element. The same in XML: The tag determines the meaning of an expression, and everything that is nested inside it is interpreted in terms of the tag. An advantage of Lisp over XML is that you don't even need separate reading and processing steps of DOMs, since s-expressions are seamlessly embedded in the language itself.
So the main point of "parser fear" is not that parsers are hard, but just too hard for what they buy you.
I think he misses the point, though. It's indeed the case that, taken by themselves, parsers are not very hard to write, especially if you stick to simple grammars. However, they could just be a too high investment for too little return.
This reminds me of a different story: A couple of years ago, Erich Gamma answered a few questions about patterns in one of his talks. One question was about which patterns he would not include anymore in the Design Patterns book. Among others, he mentioned the Singleton and the Visitor pattern, and his explanation for not including them was that he deems them too complicated.
Most people react puzzled when they hear this story. Yes, everybody who has tried to implement visitors knows that they are quite complicated, but in contrast, singletons seem extremely simple and straightforward to implement. However, the major point here is that they are too complicated for what they achieve: A singleton only guarantees that you get exactly one instance of a class, not more, not less. You might as well just introduce a global variable with that one instance and don't bother going through the minutiae of implementing the Singleton pattern correctly (which has border cases that you can get wrong after all, depending on what language you have to implement it in).
That's the major point: The effort has to be compared against the benefits you achieve. The same holds for writing parsers for DSLs. A domain-specific syntax simply doesn't buy you that much, but just creates another layer of code that needs to be maintained and can create follow-up problems, for example, when the syntax you designed happens to be too inflexible to be adapted to change requests in future versions of your code.
This is also the main reason why Lispers like s-expression. The rules for s-expressions are extremely simple, but at the same time also very flexible: The first element in a list determines the meaning of an expression, and all other elements are interpreted in terms of that first element. The same in XML: The tag determines the meaning of an expression, and everything that is nested inside it is interpreted in terms of the tag. An advantage of Lisp over XML is that you don't even need separate reading and processing steps of DOMs, since s-expressions are seamlessly embedded in the language itself.
So the main point of "parser fear" is not that parsers are hard, but just too hard for what they buy you.
posted by Pascal Costanza at 21:02
13 comments
links to this post
