To pull that off, we need to parse source code written in a variety of programming languages. The X-Ray feature analyses trends and patterns in the evolution of individual source code files. The changing point was that we developed X-Ray for the CodeScene software analysis tool. Over the past year I had to reconsider my parse strategies. Instaparse is more pleasant but too memory hungry for most of my applications. Boost Spirit, for example, doesn't scale in cognitive terms, kills system builds and it's horrible to debug the grammar. Unfortunately I've never seen an embedded parser library scale beyond simple cases like this. It's a low-ceremony refactoring that often simplifies the code a lot. When regular expressions grow too complex I replace them with an embedded parser. An embedded parser library has the advantage of being just another dependency No extra tooling required. That's why I started to experiment with embedded parser libraries like Boost Spirit for C++ and Instaparse for Clojure.

However, for simple tasks it feels like overkill to pull in yet another tool with additional build steps, etc. It was surprisingly straightforward although with a bit too much boilerplate code for my taste. My first parser used Flex/Bison to interpret a test description and feed the results to an application that generated test data. The most well-known is probably Lex/Yacc and its free alternative Flex/Bison. There are several parser generators to chose from. Unfortunately I've never been compensated that way, so let's leave that here and move on to discuss ANTLR instead. Trust me - I'd be a rich man if I had a penny for every block of code with nested loops, conditionals and primitive string operations that I've replaced with a simple parser invocation. Knowing when and how to write a parser is likely to save you a lot of time, bugs and headaches. In fact, I'll claim that parsing is one of the most neglected skills of many programmers.

And some skills are as useful today as they were two decades ago when I started.

At the same time, few technologies are genuinely new. The software industry is a tumultuous place to be New languages and frameworks pop-up all the time and it takes effort just to keep up. During that time a lot of technologies have passed by, often leaving few reasons to mourn their demise (yes, COM, I'm looking at you). I've been a professional programmer for 20 years now. The Definitive ANTLR 4 Reference by Terence Parr

Antlr 4 documentation