--- title: The true power of regular expressions | daily.dev description: Modern regex engines like PCRE are far more powerful than the formal language theory definition of 'regular' suggests. Using recursive subpattern references... canonical: https://daily.dev/posts/the-true-power-of-regular-expressions-bmqlp7bsa twitter:card: summary_large_image twitter:site: @dailydotdev og:type: website og:site_name: daily.dev og:title: The true power of regular expressions | daily.dev og:description: Modern regex engines like PCRE are far more powerful than the formal language theory definition of 'regular' suggests. Using recursive subpattern references... og:url: https://daily.dev/posts/the-true-power-of-regular-expressions-bmqlp7bsa og:image: https://api.daily.dev/og/posts/bMqLP7bSa.png og:image:alt: The true power of regular expressions og:image:width: 1200 og:image:height: 630 og:locale: en --- > ## Documentation Index > Fetch the complete documentation index at: https://daily.dev/llms.txt > Use this file to discover all available pages before exploring further. # The true power of regular expressions **[Hacker News](https://daily.dev/sources/hn)** · 23 min read · 0 upvotes · 0 comments ## Summary Modern regex engines like PCRE are far more powerful than the formal language theory definition of 'regular' suggests. Using recursive subpattern references and DEFINE-based named patterns, PCRE can match any context-free language — including well-formed HTML and most programming languages. It can also match at least some context-sensitive languages using lookahead/lookbehind assertions. Furthermore, adding backreferences makes regex matching NP-complete, demonstrated by encoding a 3-CNF SAT problem as a regex. The practical takeaway: use grammar-based regex with DEFINE blocks and named subpatterns for complex matching tasks, but prefer DOM parsers for general HTML processing. ## Full article daily.dev links to this article rather than hosting it. Read it at the original source: ## Community take How the wider developer community reacted, aggregated from 4 discussions and 94 comments across hackernews (as of 2026-08-03). **TL;DR:** The community largely appreciates the article's nuanced take on PCRE's power beyond formal regular languages, though many commenters pivot to debating readability, alternative parser libraries, and when not to use regex at all. **Sentiment:** 45% positive · 40% mixed · 15% skeptical **The case for** - PCRE's recursive and DEFINE-based features genuinely extend matching power well beyond formal regular languages, as the article clearly explains. - Regex can be extremely fast for simple pattern matching tasks, as one commenter noted with a 6GB file parsed in ~5 seconds. - Regex DSL builders (Swift RegexBuilder, Emacs rx, PyParsing, etc.) can make complex patterns readable and composable. - Regex remains theoretically fundamental as it characterizes conditions checkable in constant memory with O(n) time and O(1) space. **The pushback** - PCRE features like backreferences can degrade matching to exponential time, enabling ReDoS attacks unlike true regular expressions. - Complex regex patterns are write-only and hard to read back, and subtle differences between flavors are a footgun. - Parser combinator libraries (PyParsing, scala-parser-combinators, PEGs) are generally better for non-trivial grammars due to composability, error reporting, and refactorability. - LLMs generating regex without understanding performance implications (e.g., scanning 66MB base64 strings) is a growing concern. - The article conflates 'regex' with 'PCRE', which matters because true regex guarantees O(n)/O(1) complexity while PCRE does not. **By community** - hackernews (mixed): Commenters appreciate the article's technical depth but frequently debate readability, prefer parser combinator alternatives, and flag the important distinction between formal regex and PCRE semantics. **Hottest debate:** Whether calling PCRE features 'regular expressions' is a meaningful conflation that obscures important complexity and performance guarantees. **Open questions** - Are there regex libraries that support true DSL-level composability and named subpatterns in a way that rivals parser combinators? - Will regex become a lost art as LLMs generate them without understanding performance trade-offs? - Have non-English-speaking programmers historically found APL/J-style terse DSLs more or less approachable than English-like languages? **Highlights** > This article misleads you by conflating regular expressions with specific implementations like PCRE, which also does non-regex string matches. Annoyingly, the article does a good job of explaining what a regex is and what the limitations of regex are relative to PCRE, so the author should understand that what they are talking about when they talk about NP-complete string matching is not regex, but PCRE-specific features. The distinction matters because regex absolutely can't match HTML, and because regex, unlike PCRE expressions, have guaranteed O(1) space and O(n) time complexity when matching a string of length n. When you use PCRE features for string matching, that may degrade to exponential time which makes it useless. For example, you can do denial of service PCRE attacks, but not denial of service regex attacks (unless you can query with some megabyte-large regex). > — [jakobnissen on hackernews · 2 comments](https://news.ycombinator.com/item?id=49155311) > While true in principle, writing grammars in regexes is problematic in practice: the syntax for the more advanced features (named submatches, lookahead, backreferences, etc.) is pretty complex, and refactoring the expression means you're working within a string literal, with no help whatsoever from your editor or IDE. My "go to" solution for parsing (and validating/matching) non-trivial grammars is a library that wraps regexes and allows you to structure the grammar with entities above substrings of a string literal (including arbitrary code for transformations). PyParsing for Python, scala-parser-combinators for Scala, Grammar in Raku, PetitParser in Smalltalk, PEGs in Janet, parser combinators in F#, and so on. These are mostly internal/embedded DSLs, which makes them much easier to use than the typical lexer/parser generators, while giving you all the power to structure and evolve the grammar easily. For simple grammars, a well-written library adds little overhead over plain regexes. However, grammars rarely stay simple - very often, during the course of development, you find edge cases or the need for extensions. If you started with a structured parser, you're fine: there are specific ways of evolving the grammar, and you can use normal refactoring tools to perform them. If you started with a regex, you quickly end up with a monster regex literal that becomes more brittle and harder to change with each modification. One important property I look for in parsing libraries is the support for left-recursion. Memoizing/packrat parser generators can handle it gracefully, which is important, because if I'm implementing a published grammar, I want to encode it as closely to the original as possible. For the same reason, I prefer having dedicated tools for associativity and precedence (so that I don't have to invent names for intermediate levels). TL;DR: yes, regexes are much more expressive than the "regular" in the name would imply, but they still have their limits. For parsing things, it's better to start with something that can work in the simple case fast (so no lex/yacc-style codegen from 2 separate external DSLs), but which also provides enough structure that adding good error handling, extending the grammar, attaching arbitrary code transformations, etc. won't be a big problem later. > — [klibertp on hackernews](https://news.ycombinator.com/item?id=49155275) > Totally agree. Selfishly, I was always the "regular expression" guy because they were a bit hobby space of mine (engine implementation and such), so seeing LLMs rip them is a bid of a bummer. Half the reason it's a bummer is because I've seen coworkers who don't know when a regular expression is very suboptimal performance wise, but the LLM has no problem spitting it out. Part of really understanding regular expressions is knowing when to not use them. The one that sticks in my head is when I was debugging some code that I was suspicious was causing our high memory consumption on a simple API service just to find out the regular expression was being used to strip a potential "data" front of a base64 encoded file (apparently someone thought we should do that instead of rejecting the payload). The regular expression scanned an entire base64 string that was up to 50 MB for the raw file, so about 66MB base64 encoded. I'll tell you what, replacing it with a loop over the first handful of characters solved all the problems. It should've never been a regular expression. If you see regular expressions as an archaic language that solve string problems, and now the magic box can make them for you, you're in for hell. > — [jjice on hackernews](https://news.ycombinator.com/item?id=49154905) > Regular expressions will always remain fundamental to computer science: They characterise all of those - and only those - conditions on bytestrings (or bitstrings, or Unicode strings, etc) which are checkable in constant memory.* In other words, they characterise the set of all "regular languages", which is a name for DSPACE(O(1)). Furthermore, regular expressions can be matched in O(n) time and O(1) memory, within a single left-to-right pass, which is the highest level of efficiency mathematically possible. Since they operate on bytestrings, they can be applied to computer memory and computer state itself, which are ultimately just bytestrings, and not just to text. To be fair, you might know all of that, but I wanted to highlight this. LLMs are a lot less efficient than regular expressions wherever both are applicable, simply because everything is less efficient than regular expressions. * By constant memory, I mean that the memory usage has a maximum value independent of the size or the contents of the input bytestring. > — [ogogmad on hackernews](https://news.ycombinator.com/item?id=49155233) > This is by design, the regexp syntax has been invented for write-only programming at the CLI, and graduated to ubiguitous programming language syntax because worse is better. The regular formalism is all about composability, and most languages don't offer a way to compose regexps, which is a real shame IMO. > — [pygy\_ on hackernews](https://news.ycombinator.com/item?id=49156326) **Source threads** - [hackernews](https://news.ycombinator.com/item?id=49152973) · 53 points · 86 comments - [hackernews](https://news.ycombinator.com/item?id=35324232) · 27 points · 6 comments - [hackernews](https://news.ycombinator.com/item?id=31968633) · 4 points · 0 comments - [hackernews](https://news.ycombinator.com/item?id=48333874) · 2 points · 2 comments ## Similar posts on daily.dev - [Regular expressions that work “everywhere”](https://daily.dev/posts/regular-expressions-that-work-everywhere--eazvtdam6) · Lobsters · 0 upvotes · 0 comments --- Tags: [#php](https://daily.dev/tags/php) [View this post on daily.dev](https://daily.dev/posts/the-true-power-of-regular-expressions-bmqlp7bsa) ```json {"@context":"https://schema.org","@graph":[{"@type":"Organization","@id":"https://daily.dev/#organization","name":"daily.dev","url":"https://daily.dev","logo":{"@type":"ImageObject","url":"https://daily.dev/apple-touch-icon.png","width":180,"height":180},"sameAs":["https://twitter.com/dailydotdev","https://github.com/dailydotdev","https://www.linkedin.com/company/daily-dev-ltd"]},{"@type":"WebSite","@id":"https://daily.dev/#website","url":"https://daily.dev","name":"daily.dev","publisher":{"@id":"https://daily.dev/#organization"},"potentialAction":{"@type":"SearchAction","target":{"@type":"EntryPoint","urlTemplate":"https://daily.dev/search?q={search_term_string}"},"query-input":"required name=search_term_string"}}]} {"@context":"https://schema.org","@type":"TechArticle","headline":"The true power of regular expressions","url":"https://daily.dev/posts/the-true-power-of-regular-expressions-bmqlp7bsa","mainEntityOfPage":{"@type":"WebPage","@id":"https://daily.dev/posts/the-true-power-of-regular-expressions-bmqlp7bsa"},"datePublished":"2026-08-03T12:15:30.992Z","dateModified":"2026-08-03T15:17:58.349Z","description":"Modern regex engines like PCRE are far more powerful than the formal language theory definition of 'regular' suggests. Using recursive subpattern references...","image":"https://media.daily.dev/image/upload/s--1KxV4ohY--/f_auto/v1722860400/public/Placeholder%2007","thumbnailUrl":"https://media.daily.dev/image/upload/s--1KxV4ohY--/f_auto/v1722860400/public/Placeholder%2007","isAccessibleForFree":true,"articleSection":"Hacker News","inLanguage":"en","publisher":{"@type":"Organization","name":"daily.dev","url":"https://daily.dev","logo":{"@type":"ImageObject","url":"https://daily.dev/apple-touch-icon.png","width":180,"height":180}},"author":{"@type":"Organization","name":"Hacker News","logo":"https://media.daily.dev/image/upload/t_logo,f_auto/v1/logos/hn","url":"https://daily.dev/sources/hn"},"commentCount":0,"discussionUrl":"https://daily.dev/posts/the-true-power-of-regular-expressions-bmqlp7bsa","interactionStatistic":[{"@type":"InteractionCounter","interactionType":{"@type":"LikeAction"},"userInteractionCount":0},{"@type":"InteractionCounter","interactionType":{"@type":"CommentAction"},"userInteractionCount":0}],"keywords":"php","timeRequired":"PT23M"} {"@context":"https://schema.org","@type":"BreadcrumbList","itemListElement":[{"@type":"ListItem","position":1,"name":"Home","item":"https://daily.dev"},{"@type":"ListItem","position":2,"name":"Hacker News","item":"https://daily.dev/sources/hn"},{"@type":"ListItem","position":3,"name":"The true power of regular expressions"}]} ```