Now they have two problems

The line is about a developer reaching for regex to solve a problem in text, such as finding every order number in a file. Jamie Zawinski was an early Netscape engineer who has been publicly unimpressed by software ever since. He put it like this: “Some people, when confronted with a problem, think ‘I know, I'll use regular expressions.’ Now they have two problems.”

The joke is simple. The text you need to search, clean up or check is problem one. You write a regular expression to solve it. If the expression becomes a thicket of slashes, brackets and exceptions, understanding the solution becomes problem two. The joke never claims regex is useless. It is saying that a clever shortcut can become another thing you have to solve.

And unlike many famous quotations, this one really is his. He posted it on 12 August 1997 during a newsgroup argument about Perl. A newsgroup was where the internet argued before websites had comment sections. Zawinski was objecting to the idea that regular expressions were the answer to every problem involving text. Somebody later went and found the post, which is more than can be said for most attributions.

He did not invent the joke's shape. A 1988 post made the same joke about a different tool for processing text. The blank is the durable part: “I know, I'll use X.” Now you have X as well as the problem you started with. Zawinski supplied the version that stuck.

The idea behind regular expressions began nowhere near order numbers. Stephen Kleene, a logician, introduced it in a 1951 paper about nerve nets and finite automata. He was describing which patterns a simple theoretical machine could recognise, and he called them regular events. The asterisk a developer types a dozen times a day is named after him: the Kleene star. It means any number of these, including none.

It stayed in the logic literature for seventeen years. In 1968, Ken Thompson showed how a computer could use one of these patterns to search text quickly. Then he put the result in a text editor. Thompson later helped build Unix, so this was nowhere near his most famous work. It was, however, the step that moved regular expressions from a paper about theoretical machines into tools developers actually used.

This is why the joke is slightly unfair. Regular expressions did not begin as a hack. They began as formal mathematics, designed so a machine could recognise a pattern without guessing. For small regular jobs they are fast and precise. Often they are exactly the right tool.

The trouble begins when the patterns stop being small. The regex engines used today have features such as backreferences, lookaheads and lazy quantifiers. They are useful, but they also let a pattern grow beyond Kleene's original theory. The old speed guarantee can disappear with that simplicity.

The computer may be happy, but the next reader may not be. A developer writes a regular expression while holding the whole pattern in their head. The next person sees a line of brackets, slashes and asterisks with no explanation of what each part is doing. The original task might have been “find an order number”. Now the team also has to understand and safely change the pattern that finds it. That is the second problem.

Which is why the line has lasted. It is unfair to a useful idea, but accurate about a familiar habit: solving something quickly and leaving the explanation for whoever arrives next.