LLMs pose an interesting problem for DSL designers

Original Article ↗ Hacker News Discussion ↗

Impact of LLMs on DSLs and Language Choice

  • Many argue LLMs heavily bias developers toward mainstream languages (especially Python) and older, well-documented stacks, because that’s where models perform best.
  • This raises the perceived “cost” of a new DSL or language: users must learn it and also lose some of the LLM assistance they get “for free” in Python/TypeScript/etc.
  • Some expect language innovation and DSL adoption to slow or “ossify” around incumbents; others hope better tooling (RAG, MCP, custom models) will mitigate this.

Arguments For and Against DSLs in the LLM Era

  • Critics: DSLs add another syntax and toolchain to learn, often die with their creators, and can be vanity projects when a library + general-purpose language would suffice.
  • Supporters: Good DSLs make invalid states unrepresentable, compress complexity, and can be more concise for both humans and LLMs (fewer tokens, stronger semantics).
  • Embedded/internal DSLs (within Python, Haskell, Ruby, etc.) are seen as a pragmatic middle ground, already successful in ML (PyTorch), data (jq), build systems, regex, etc.

LLMs, Training Data, and DSL Usability

  • Models struggle with niche or newer APIs and DSLs, even when given docs; they often revert to older versions or more common patterns.
  • Some report decent results when they supply DSL specs, examples, and error-feedback loops; LLMs can fix type errors or translate from shell-like concepts into a DSL.
  • DSLs with semantically meaningful, human-readable tokens (e.g., Tailwind-style) are thought to be easier for LLMs than dense symbolic ones (e.g., regex).

Future Directions for Languages and Tools

  • Several suggest designing languages/DSLs to be closer to pseudocode or natural language, making them friendlier to both humans and LLMs, though not always ideal for every domain.
  • Others imagine:
    • IDEs as “structure editors” showing multiple views over verbose underlying code.
    • LLMs as DSL translators rather than replacements.
    • Read-only or AI-oriented languages that humans rarely write directly.
  • There is concern that PL research and “fancy” new languages/features may see less real-world uptake as developers optimize for what LLMs already handle well.