True, but it should only be done after getting a working compiler, to get good error handling and messages.

From my experience most people don't use parser generator tools due to lack of knowledge that they even exist.

People don't use parser generator tools because you wind up doing more work than needed to integrate it with the rest of your compiler. The reason to use a parser generator is not for ease of use or rapid development (because they are harder to use and slower to develop with) but for performance and reliability.

The first one isn't such a big deal for most programming languages, the second one is. Throw in better error handling and tricks like sub-file incremental and/or heuristical compilation (for IDEs), and the generators don't make much sense anymore.

> People don't use parser generator tools because you wind up doing more work than needed to integrate it with the rest of your compiler.

I don't think you can make such a sweeping generalisation. Both JavaCC and Antlr have saved me a lot of time when doing DSLs in the past and both are well documented and easy to use. It would have been much more work for me to write the parsers by hand in Java. Both could also generate my own hand-rolled AST easily and so I do not see why integration would be a problem for most projects. I agree that generators do not scale to large compilers or projects with special needs, but that is not most projects.

That makes sense after having a language reaching 1.0 in production use.

Not so much when prototyping, when it isn't even clear if the language is going to get any users beyond the design team.

My last few languages have all been prototyped by hand, but they were all live languages (with continuous re-parsing and interpretation), so I didn’t have much choice :). I havent bothered with ANTLR since grad school.