4 ms·
I actually think your Perl and specifically regex example where spot on, in my career I have only worked with probably 4 programmers who really understood and c
by kls 6y ago
I actually think your Perl and specifically regex example where spot on, in my career I have only worked with probably 4 programmers who really understood and could think in regex, which gave them the tools to solve extremely complicated parsing problems rather simply. The rest of the teams just relied on those people to do their regex thinking for them. The sad part, it regex it rather simple to learn and just takes a little effort but people treat it like it is black magic.
- kazinator 6y agoA lot of regex-based solutions are not robust against bad input. Bad input doesn't always mean that the regexes don't match! Regexes have a very happy home inside lexical analyzers for tokenizing languages. Lexers define what is correct input and match every case with some regex pattern. If there is no match, then the input doesn't contain a valid token: the lexer can loudly complain (logging an error that can be treated as fatal by the overall compile job), drop an input character and try matching again. The typical regex solutions in Perl (Awk, ...) scripts go like this: "look for this flimsy, minimal regex somewhere in the stream and assume it's the right thing, then match this other regex in the same line and---woo hoo!--that's our item. Oh, false positives, schmozitives." Basically, if we were to pin it down to a single difference in principles is that using regexes for searching for something small in something large is different from matching an entire input in its totality (and then getting at the desired parts). Searching is the quick and dirty thing that's easy to reach for.