What's the alternative? Just curious. I use REs when I need REs, and when I need one it's because the alternative seems to be to write a whole string parser or some clunky seriously code-verbose combination for finds, splits, replaces, etc that is even harder to read that an regex.
But then I guess I grew up with REs and have no real issue with them. Be nice if advanced RE syntax had evolved a little more standardly and didn't diverge into flavours, which it did but hey.
Grammars and parsers. Overkill for small ad-hoc parsing tasks where regex really shine but advisable for more complex tasks. This is where Raku (formerly Perl 6) really shines, having recursive-descent parsing as a first-class language construct is quite the game changer.
Indeed. The very point. That REs shine for small ad hoc jobs. Grammars and parsers are from a different context altogether. To epitomise the role of REs consider a job I example that simply wants detect all lines that contain one word somewhere before the other. This is trivially simple in an RE and preciously whence their definition stems (as in I can write that on the command line for a grep or find) and the niche in which their ubiquity reigns. That small need right now for a mildly complex pattern test or field extraction.
Yes, I think we fully agree here, my original response was maybe not clear enough. For the things regex were made for, there's IMO no better solution. But I've also seen too many people implement what effectively become super brittle parsers with them, which is also not the right thing to do.
The main reason I mentioned Raku is that Larry Wall deserves a lot of the credit for modern regex implementations, after all they generally try to be Perl compatible. So it's interesting to see which shortcomings he perceived (Raku regexes are quite different from PCRE) and also that he decided that there is a space for grammars on the language level.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
What's the alternative? Just curious. I use REs when I need REs, and when I need one it's because the alternative seems to be to write a whole string parser or some clunky seriously code-verbose combination for finds, splits, replaces, etc that is even harder to read that an regex.
But then I guess I grew up with REs and have no real issue with them. Be nice if advanced RE syntax had evolved a little more standardly and didn't diverge into flavours, which it did but hey.
Grammars and parsers. Overkill for small ad-hoc parsing tasks where regex really shine but advisable for more complex tasks. This is where Raku (formerly Perl 6) really shines, having recursive-descent parsing as a first-class language construct is quite the game changer.
Indeed. The very point. That REs shine for small ad hoc jobs. Grammars and parsers are from a different context altogether. To epitomise the role of REs consider a job I example that simply wants detect all lines that contain one word somewhere before the other. This is trivially simple in an RE and preciously whence their definition stems (as in I can write that on the command line for a grep or find) and the niche in which their ubiquity reigns. That small need right now for a mildly complex pattern test or field extraction.
Yes, I think we fully agree here, my original response was maybe not clear enough. For the things regex were made for, there's IMO no better solution. But I've also seen too many people implement what effectively become super brittle parsers with them, which is also not the right thing to do.
The main reason I mentioned Raku is that Larry Wall deserves a lot of the credit for modern regex implementations, after all they generally try to be Perl compatible. So it's interesting to see which shortcomings he perceived (Raku regexes are quite different from PCRE) and also that he decided that there is a space for grammars on the language level.