A decade of developing a programming language
A decade-long effort to build a new programming language prompts reflection on what actually works in language design and implementation. Commenters weigh the trade-offs between static, dynamic, and gradual typing (with many criticizing gradual typing for new languages), the practical difficulty of implementing type checkers and robust tooling, and the value of targeting existing platforms like LLVM, WASM, or the JVM. The conversation also highlights how hard it is to grow a user base, why most new languages remain niche, and why clear goals and real-world use cases matter more than ambitious but unfocused features.
Gradual typing: value vs. drawbacks
- Many agree with the article’s recommendation: for new languages, gradual typing adds complexity without commensurate benefits. Better to pick static or dynamic (usually static) and rely on inference.
- Others argue gradual typing is very useful when retrofitting types onto large dynamic ecosystems (JS→TS, Python, Elixir/Erlang, Raku), or when “escape hatches” are needed (config DSLs, interop).
- Some see gradual systems as a migration tool toward static typing, not an end state.
- Several note there’s a spectrum of gradual systems; performance and safety depend heavily on how boundaries between typed/untyped code are enforced.
Static vs dynamic productivity and safety
- Some claim they’re no more productive in dynamically/gradually typed languages than statically typed ones; initial annotation overhead pays off over time.
- Others cite limited empirical evidence in both directions and stress that productivity depends on problem domain, team size, language ecosystem, and personal preference.
- A recurring critique: “finding a few bugs” via weak or opt-in checking (e.g., default Python/mypy settings) may give a false sense of safety if it doesn’t change testing/workflow.
Python and gradual typing in practice
- Experiences with large typed Python codebases are mixed:
- Pro: type hints improve documentation and catch some hard-to-reproduce bugs.
- Con: third‑party stubs drift out of sync, tools “fail open” by default, and unenforced or ignored annotations can mislead.
- Pyright is praised for stricter defaults than mypy. PHP is mentioned as enforcing gradual types at runtime, contrasting with Python’s purely static hints.
Type checking is conceptually simple but poorly documented
- Several language implementers say type checkers are mostly straightforward logic once semantics are fixed, but good learning materials are scarce.
- Popular academic books are seen as heavy and theory-first, with few concrete programs or practical walkthroughs.
- Multiple links to blog series, small HM implementations, and “Crafting Interpreters–style” resources are shared; there’s clear demand for an approachable, implementation-focused type-checking book.
Other language-design and implementation themes
- Using existing platforms (JVM, BEAM, JS, LLVM, WASM) and toolchains is widely endorsed to avoid writing custom code generators, linkers, or full toolchains.
- Self-hosting is seen as costly; some argue modern WASM/WASI bootstrapping makes it more feasible, others warn not to cargo‑cult prominent projects.
- S-expressions/Lisp are valued for trivial parsing and avoiding syntax bikeshedding; many note parsing is rarely the hard part compared to semantics and type systems.
- Several commenters emphasize: define clear target users and problem domains; most “fringe” languages remain niche, but even failed languages can contribute ideas.