A brutally honest checklist for anyone considering creating a new programming language.
"You appear to be advocating a new programming language. Your language will not work. Here is why."
This repository preserves and shares the classic Programming Language Checklist, originally written by:
- Colin McMillen
- Jason Reed
- Elly Fong-Jones
The goal of this repository is to make these insights easily accessible, version-controlled, and shareable within the developer community.
Every year, thousands of developers attempt to create new programming languages.
Most fail, not because of lack of effort, but because they underestimate:
- Language design complexity
- Tooling ecosystem requirements
- Compiler/runtime engineering challenges
- Adoption barriers
This checklist serves as a reality check.
- functional
- imperative
- object-oriented
- procedural
- stack-based
- multi-paradigm
- lazy
- eager
- statically-typed
- dynamically-typed
- pure
- impure
- visual
- beginner-friendly
- completely incomprehensible
- Syntax is what makes programming difficult
- Garbage collection is free
- Computers have infinite memory
- Nobody really needs concurrency / REPL / debugger / IDE / I/O
- Interoperability is optional
- Scaling is easy
- Adoption is easy
- Has unclear or overly complex syntax
- Lacks essential features or includes too many conflicting ones
- Reinvents existing concepts poorly
- Introduces unnecessary novelty
- No formal specification
- "Implementation is the spec"
- Unsound type system
- Impossible-to-parse grammar
- Requires unrealistic assumptions
- Solves already-solved problems worse
- Ignores how CPUs / RAM / compilers actually work
- Fragile compiler or VM
- Poor error messages
- Requires runtime at compile-time (or vice versa)
- Lacks optimization understanding
- Claims massive productivity gains without proof
- Benchmarks are misleading
- Reinvents existing languages “but better”
- Rejects established computer science principles without justification
- Your language replaces something that already exists
- Your “killer feature” exists elsewhere
- Your language has no tooling
- Your language has no community
Building a programming language is not about syntax. It is about ecosystems, tooling, semantics, and adoption.
Despite the sarcasm, building a language can make sense if:
- You are solving a domain-specific problem (DSL)
- You need compile-time guarantees not available elsewhere
- You are experimenting with research ideas
- You are building infrastructure (VM, compiler tech, etc.)
This repository is intended for educational and reference purposes.
Please refer to the original source for authorship and attribution: https://www.mcmillen.dev/language_checklist.html
Feel free to:
- Improve formatting
- Add modern commentary
- Provide real-world examples
- Compare with modern languages (Rust, Go, Zig, etc.)