>>He has several arguments; performance is only one of them. First -- I noted that I limited my comment to scripting languages. I did discuss most of the rele

>>He has several arguments; performance is only one of them. First -- I noted that I limited my comment to scripting languages. I did discuss most of the relevant arguments in the article, so I really don't see what your point is? It doesn't matter for the scripting languages that a regexp lib is large (it is linked in and used anyway), so I ignored that. I also ignored the Unicode point, since it is generally supported in scripting languages' regexp engines. I did touch on speed and development speed. Shorter code is also generally easier to understand; a simple regexp can often replace 10-20 lines. In my edit, 10++ hours before your comment, I discussed when full grammars where a better alternative -- so I handled Pike's accusation of treating Regexps as a "panacea for all text processing". (I have used regexps as lexers for grammars. But only for parsers of less than a few hundred lines.) (I am not going to touch Pike's argument if I and others really grokk regular expressions, because I thought I did understand them until I read "Mastering Regular Expressions". Maybe there are some more satori insights waiting? I do consider myself a little bit familiar with them from automata theory, implementing state engines and usage [Edit: and my considered opinion is that re:s are often a good solution for scripting languages.])