I think that there aren't many fans of TeX's design. (Well, I rather like it, but probably because I am not a language designer.) Seibel (http://lambda-the-ultimate.org/node/3613#comment-51120) quotes Knuth as saying (in "Coders at Work"—but the relevant page is not on Google books):
Mostly I don't consider that I have great talent for language design.
Some writers of real compilers (vs. school projects) even today would avoid lex and yacc. Stroustrup, for example, wrote that in hindsight he shouldn't have used yacc for his cfront, apparently it brought him more pain than benefit.
Yacc and lex (and even more modern versions of the parser generators) have good "educational" value, but are far from being the silver bullets in practice.
To add my example: For my first and simple compiler used in the commercial application I used yacc. The start looked simple, then I hated it. It looked to me that I invested more energy in managing to do something "the yacc way" than to actually do something. For my more recent one, much more complex, I avoided yacc using a variant of recursive descent and never came to the point to miss anything, quite the opposite.
The one production compiler I worked on used YACC because we thought it was a good idea, but this was probably correct in that the PhD that did the parser part was a student of Hopcroft. She actually published a paper about error correction based on the work there.
Any compiler I write these days would do what you are saying--recursive descent. There is a nice technique called "chart" that helps with this.
Thanks. Do you mean this: http://en.wikipedia.org/wiki/Chart_parser It seems it's something to be more used for the natural language parsing, less for the programming languages?
That turns out to not be a very good writeup. The published work is http://dl.acm.org/citation.cfm?id=801348 and Dick Vile did a lot of work on it years after that, using it to describe an in-house production language.
