Compiler-building opinions advocate prototyping languages with transpilers and relational type checking

The author separates language design from compiler construction and recommends avoiding full compilers in favour of transpilers. By targeting an existing runtime (Python, JavaScript, Go), engineers can validate a language without building a code generator, register allocator, or linker. This approach trades immediate performance for faster iteration and lower initial effort.

Prototyping tools are central to the workflow. OhmJS and its editor provide a REPL-like environment for grammar development, reducing the feedback loop for syntax changes. The author suggests writing the parser twice, once in OhmJS for experimentation, then porting to a production parser (Pratt, recursive descent) only after the grammar stabilises. Type checking is similarly prototyped relationally in Prolog before being re-implemented in a more performant language.

Code emission is split into two phases: dumb generation followed by peephole optimisation. The author cites Fraser/Davidson and Cordy’s OCG as models, arguing that LLVM is overkill for initial implementations. Intermediate representations like JavaScript or Lisp are preferred for their simplicity, with Python’s indentation handled via a pre-processing step that converts brace-delimited code to properly indented output.

The post frames compiler development as a pipeline of specialised stages, each using the most suitable tool, OhmJS for parsing, Prolog for type checking, Cordy’s MISTs for portability. This modularity allows engineers to defer optimisation until profiling identifies bottlenecks. The advice is explicitly aimed at minimum viable implementations, leaving production engineering (blazing-fast code, efficient memory use) as a later concern.