DEV Community: Fu liang

Testing automata-theory exercises in the browser: a regex flavor for CS coursework

Fu liang — Sun, 04 Oct 2026 12:19:22 +0000

If you've ever taught or taken a formal languages course, you know the workflow: the exercise says write a regular expression for all strings over {a,b} containing an even number of a's, you write (b|ab)* on paper... and then you have no way to check it.

Programming regex flavors can't validate it for you — they're full of conveniences the formal dialect doesn't have: character classes, quantifier shorthands, anchors. What you want is a checker that speaks the textbook dialect: union ∪ or |, concatenation, Kleene star *, plus +, parentheses. Nothing more.

RegexTester.dev now ships a Formal Automata Theory flavor exactly for this.

What it accepts

Symbols from your chosen alphabet (typically a, b, or 0, 1)
Union: ∪ or |
Concatenation: juxtaposition or .
Kleene star: *, and one-or-more: +
Grouping with parentheses

Everything else — \d, [a-z], lookahead, backreferences — is rejected with an explanation, because the point is to exercise exactly the constructs the course covers.

Instant feedback

Type the expression and test strings in, and you immediately see which strings match and which don't — so you can iterate on the exercise instead of waiting for a grader.

The flavor runs on the same engine infrastructure as the other eight dialects (PCRE2, RE2, .NET, Python, Java, Go, Rust, JavaScript), so the matching behavior is well-defined and consistent.

Why a browser tool for coursework?

Because the feedback loop is everything when learning. The gap between writing (b|ab)* on paper and knowing whether it's right is where most of the confusion in a formal languages course lives. Close that gap to seconds and students experiment their way to understanding: they can see that (b|ab)* matches babb but not abab, and fix their mental model immediately.

It also works the other direction: instructors can build exercise sets with permalinks — every regex and test string combination in the tester has a shareable URL, so "check your answer against this" becomes a link.

Try it: open regextester.dev, pick the Formal Automata flavor from the selector, and test that even-number-of-a's exercise.

Full write-up: regextester.dev/blog/Formal-automata-theory-flavor. Free, no signup — built for students and educators.

Benchmarking regex patterns properly: P95/P99, equivalence checks, real engines

Fu liang — Sun, 04 Oct 2026 12:08:30 +0000

Every developer has been here: two regex patterns that both work. One is a dense one-liner, the other reads like prose. Which do you ship?

"Use the simpler one" is a fine heuristic until the pattern runs over a 50 MB log file or every request in a hot path. Then you want data. The problem is that regex benchmarks done casually lie to you three ways:

The engine problem — your JS benchmark measures JavaScript's RegExp, but the pattern ships to a PCRE2-based backend. Different engine, different behavior, different speed.
The clock problem — a fast regex finishes in microseconds, far below performance.now() resolution. You're measuring timer noise.
The equivalence problem — the faster pattern is faster because it matches less. You optimized a bug.

RegexTester.dev's built-in Benchmark Suite was designed against those three traps. Here's how it works.

Real engines, identical conditions

Up to 5 alternative patterns run sequentially under identical input, flags and engine — the same engines the tester itself uses: PCRE2 and RE2 as WebAssembly in a dedicated worker, .NET's System.Text.RegularExpressions as a real interpreter, and native JS RegExp (including the normalize-to-JS path used for Python, Java and other flavors).

Sub-clock-precision timing

Each sample times K consecutive executions and records time ÷ K, with K auto-calibrated so every sample spans between 0.35 ms and 12 ms. This batch amplification resolves sub-microsecond patterns with sub-nanosecond effective resolution — far below browser clock precision.

You get median, mean, P95, P99, ops/sec and the relative speedup of the fastest pattern, with a ±RSE column that tells you when a number is too noisy to trust.

Equivalence checking

Speed means nothing if the output changed. The suite records each pattern's match count on the benchmark input and raises an "Output differs" warning when counts diverge — a pattern that's faster because it matches less gets flagged before you ship it.

Reading the charts

Latency histograms and timelines make the distribution shape visible: a tight spike means stable performance; a long tail means some inputs hit pathological backtracking even when the median looks fine.

Export

Results export as Markdown (for PRs and docs) or JSON (for your own tooling), with the environment (UA, cores, timestamp) baked in so numbers stay comparable.

Try it: open regextester.dev/bench, paste two alternatives, press Run. Sixty seconds later you'll know which one to ship — and whether they really do the same thing.

Full write-up: regextester.dev/blog/regex-benchmark-suite. Free, no signup, everything runs locally.

I built a regex debugger that shows every backtrack (flame graph included)

Fu liang — Sun, 04 Oct 2026 12:08:29 +0000

Testers tell you what a regex matches. A debugger tells you why — and where it burns time.

Every regex tester shows the same three things: matches, groups, and an explanation of the pattern. That covers the happy path. It stops helping the moment a regex is almost right — matching one tag too many, missing a case you can't reproduce, or taking 400 ms on an input that looks identical to the one that took 4.

The failure modes of a backtracking engine are invisible from the outside. A pattern doesn't slowly get slower — it tries a prefix, gives characters back, retries the inner quantifier at a different split, fails, and repeats that a few thousand times. The match result looks the same as the fast version's. Only the trace of what the engine actually did tells them apart.

So I built a full debugger into RegexTester.dev. Here's what it does.

One click from the tester

The entry point is the Debug button on the tester toolbar. Hit it, and the debugger opens with the trace already recorded. The demo pattern <([a-z]+)([^<]+)*(?:>(.*)<\/\1>|\s+/>) against <div>Content</div> generates 7,530 execution steps for 18 characters of input. That gap between "looks simple" and "7,530 steps" is exactly what the debugger makes visible.

The execution graph

The graph is a flame-chart of the engine's work. Each bar is one node attempt — a TRY that ended in OK (green), FAIL (red), or was undone by backtracking (thin blue give-back marks). Rows are stack depth; vertical bands separate match attempts.

It behaves like a proper profiler view: scroll-wheel zoom, drag to pan, double-click to zoom to a block, click any block to jump there — the amber marker follows, and every other panel updates in lockstep. A healthy trace reads as a calm staircase. A sick one shows the signature immediately: one region of the graph orders of magnitude wider than everything else, striped with red and blue.

Hot spots: where the steps go

The Hot spots table is the profiler summary: every node of your pattern, ranked, with its operation count, give-backs, failures, and share of total steps.

This is the same workflow you'd use on slow code: profile, find the hot function, fix, re-profile. It just didn't exist for regular expressions in a browser before.

From diagnosis to fix in two clicks

Diagnosis without a fix is only half a tool. The Suggestions panel combines static analysis with trace statistics to propose concrete rewrites — dialect-aware, so a PCRE2 pattern gets atomic groups and possessive quantifiers while a JavaScript pattern gets the constructs ES2025 actually supports.

The classic case: (a+)+b on aaaaaaaaaaX — the textbook catastrophic backtracking example. The debugger names the disease and prescribes the cure:

Two things make this safe to trust:

Equivalence checking — both patterns run against the real engine for your dialect on your input; only identical match lists earn the "same matches on this input" badge. A faster regex that matches less is a bug, not an optimization.
Apply writes the rewrite into the tester and re-traces immediately: same input, Healthy verdict, 404 steps instead of 50,000+.

A tracer kept honest

The trace comes from an instrumented backtracking engine — a continuation-passing matcher written for this purpose, speaking the semantics of nine flavor dialects. Every trace is cross-checked against the real thing: the match outcome is compared with the actual engine for the selected flavor (native RegExp, or PCRE2/.NET compiled to WebAssembly), and a "trace verified" badge only appears when they agree.

Try it: regextester.dev/debug — or read the full write-up at regextester.dev/blog/regex-debugger. Free, no signup, everything runs locally.