Dear sir, you have built a compiler (2022)

Original Article ↗ Hacker News Discussion ↗

Engineers often “accidentally” build compilers and mini‑languages when trying to make configuration or workflow systems more powerful, only to end up reinventing complex, brittle platforms that are hard to maintain. Commenters relate this to the inner‑platform effect, single-page web apps, Kubernetes YAML, and homegrown tooling, using it to explore the broader tradeoff between building bespoke systems and relying on third‑party dependencies. Many argue that compilers and DSLs are valuable when designed intentionally and kept small, but that most teams underestimate the long‑term cost—in complexity, bus factor, and security—of both over‑engineered internal frameworks and sprawling external stacks.

What the discussion sees the article as describing

  • Many relate it to the inner-platform effect: rebuilding a general-purpose language or platform inside an app (templating, config, workflow) until it’s essentially a compiler.
  • Some note similar dynamics in web tech: SPAs, canvases, and WebAssembly can become “platforms inside platforms”.

How people accidentally build compilers

  • Common paths:
    • Template engines that gain conditionals, loops, and complex expression syntax.
    • Configuration formats that grow predicates, workflows, and data transformations.
    • “Simple” domain languages (forms, onboarding, workflows) that accumulate logic.
  • Several report real projects where thousands of lines of bespoke logic were thrown away and replaced by simpler templates or plain code.

Is building a compiler / DSL a bad thing?

  • One camp: it’s fine or even good, as long as it’s intentional, scoped, and you understand compiler basics (lexing, parsing, ASTs, semantic checks).
  • Another camp: if you don’t realize early you’re writing a compiler, you almost always end up with an unmaintainable mess.
  • Some recommend writing toy compilers to get intuition before doing this “for real”.

Build vs buy and dependency choices

  • Strong disagreement:
    • Some see homegrown systems as the worst disasters; prefer robust, battle-tested libraries.
    • Others say third‑party deps, toolchains, and transitive bloat have been their biggest pain, and prefer small in‑house solutions.
  • Several frame “when to build on top vs from scratch” as a key senior skill, with no easy metric; both over‑engineering and over‑dependency can backfire.

Config, scripting, and “everything is a compiler”

  • Many observe that rich config languages, YAML + templating (Helm, Kustomize), Kubernetes manifests, Yocto builds, and similar systems are effectively compilers or language workbenches.
  • Alternatives discussed: embed established languages (Lua, JS, Python) instead of inventing new DSLs; or use safer config-as-code systems (e.g., Dhall, Starlark).
  • Some argue every non-trivial config parser is a mini-compiler; the question is how explicit and well‑engineered you make it.