3 ms·

Pike's argument is relevant for compiled system level languages (C, C++, Java, etc). The regular expression libraries used in scripting languages today (Perl's

by berntb 15y ago

Pike's argument is relevant for compiled system level languages (C, C++, Java, etc). The regular expression libraries used in scripting languages today (Perl's and PCRE) are optimized C code. A lexer in interpreted code is hardly going to beat them in speed. Note that a large part of the reason to use scripting languages is the development speed. Regexps FTW, etc. Edit: I should add -- if I have a problem where I need to parse something complex like a "real" programming language, I go to the LALR libs of course. The right tool for the job. (On second thought -- this is probably what Pike talks about; he doesn't go around solving simple problems, like I do. But no complaints, I've got a job interview tomorrow... :-) )

kragen 15y ago
He has several arguments; performance is only one of them.
- berntb 15y ago
  >>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.])

by berntb 15y ago

kragen 15y ago

He has several arguments; performance is only one of them.

berntb 15y ago
>>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.])