Any time you’re turning a string of input into something else, what you are doing is parsing.

Even if the word “parser” never appears in your code, the act of interpreting a string as structured data is parsing, and the code that does parsing is a parser.

Programmers write parsers quite a lot, and many of the parsers they write are ad-hoc, ill-specified, bug-ridden, and can’t tell you why your input didn’t parse right.

Writing a parser without realizing you’re writing a parser, usually leads to writing a bad parser. Bad parsers do things like accepting malformed input that causes security holes. When bad parsers do reject malformed input, they rarely emit useful error messages about why it’s malformed. Bad parsers are often written using regex and duct tape.

Try not to write bad parsers. If you need to parse something, consider writing a grammar and using a parser library. (If you’re very ambitious, try a parser combinator library.) But at least try to recall something about parsers you learned once way back in a CS class, before throwing regex at the problem and calling it a day.

(And now the word “parser” no longer makes sense, because of semantic satiation.)

By the way, please don’t write regex to try to validate email addresses. Seriously. There are libraries for that; some of them are even good. When people write their own regex to match email addresses, they do things like forget that the hyphen is a valid character in domain names.