In terms of education I disagree about the importance of "LR" (really meaning bottom-up, table driven, automatically generated) parsers vs recursive descent (top-down, typically hand written), for a couple of reasons:
1) Real world compilers are almost always hand written recursive descent. They just turn out to be more flexible, easier to maintain, generate better error messages, etc.
2) Teaching compiler writing as part of a computer science degree is somewhat of a tradition, but the number of students who will ever write a compiler (even for a small DSL, let alone a real language is minimal). I think it's a useful exercise to show how these things are structured and teach general "divide-and conquor" decomposition of complex programs, but that's about it. Given the number of moving parts in a compiler, the emphasis should be on an overview of all the parts and how they fit together, not going overboard on parsing and teaching two different parsing techniques. To the extent that any Comp-Sci student will ever end up needing to write a parser at some point in their career (say for a DSL, or to parse some data format), then recursive descent is the more useful one to know.
Parser generators seem largely an historical approach from a time (1970's) when computers were so slow that the speed of a table driven parser was a major advantage, and the idea is firmly implanted in the heads of those of us that grew up reading Aho & Ullman's compiler-writing "Dragon Book". I think they still serve a purpose, but perhaps for more fringe use cases rather than writing actual compilers for full-blown languages!
Having said all that, there's a lot of fun in writing a parser generator, regardless of how useful the end result may be! I wrote a full LR(1) - not YACC-like LALR(1) - parser generator in Modula-2 back in the early 80's, at a time when the text books told you this was impractical/impossible due to the size of a canonical Knuth LR(1) parser.
1) Real world compilers are almost always hand written recursive descent. They just turn out to be more flexible, easier to maintain, generate better error messages, etc.
2) Teaching compiler writing as part of a computer science degree is somewhat of a tradition, but the number of students who will ever write a compiler (even for a small DSL, let alone a real language is minimal). I think it's a useful exercise to show how these things are structured and teach general "divide-and conquor" decomposition of complex programs, but that's about it. Given the number of moving parts in a compiler, the emphasis should be on an overview of all the parts and how they fit together, not going overboard on parsing and teaching two different parsing techniques. To the extent that any Comp-Sci student will ever end up needing to write a parser at some point in their career (say for a DSL, or to parse some data format), then recursive descent is the more useful one to know.
Parser generators seem largely an historical approach from a time (1970's) when computers were so slow that the speed of a table driven parser was a major advantage, and the idea is firmly implanted in the heads of those of us that grew up reading Aho & Ullman's compiler-writing "Dragon Book". I think they still serve a purpose, but perhaps for more fringe use cases rather than writing actual compilers for full-blown languages!
Having said all that, there's a lot of fun in writing a parser generator, regardless of how useful the end result may be! I wrote a full LR(1) - not YACC-like LALR(1) - parser generator in Modula-2 back in the early 80's, at a time when the text books told you this was impractical/impossible due to the size of a canonical Knuth LR(1) parser.