Bootstrapping a Compiler
Published in 2015, this chronicle by @wglb details the mechanics of building a profitable, self-funded business without venture backing.
Core Principles for Independent Builders:
Charging customers from day one acts as the ultimate filter for building software that solves genuine, high-urgency problems.
Keeping fixed overhead low and leveraging lean infrastructure allows founders to stay alive until market tailwinds kick in.
Small, repetitive improvements in customer retention and conversion rates yield massive returns over multi-year horizons.
Community Debate Themes:
The community focused on B2B customer acquisition channels, cold email vs SEO distribution, and balancing full-time employment with side-project development.
CATEGORY Bootstrapping & MRR →
HISTORICAL ERA Cloud & Mobile Era (2014–2019)
COMMUNITY SCORE 42 points
TOTAL DISCUSSIONS 15 comments
I am no expert in this field, but I was always wondering, are there issues that could theoretically come up, due to bugs in a previous implementation of the bootstrapped language and leave no way to resolve them?
So specifically, while the language is not bootstrapped, the developers work in a probably 100% tested and working language to implement theirs. Suppose they leave some bugs in the first implementation of their language, and they bootstrap it using their buggy first implementation. Could some of these bugs later be impossible to correct? Like they are on such a low level of the language that even the language constructs that would be needed to correct them are buggy, so they can't do it?
Using a scheme subset seems like cheating almost. The no syntax, s expression languages allow one to avoid the entire lexing, parsing, ast generation aspect of the endeavor.
Tratt has a blog post that expands on the bit about languages implemented in themselves and the consequences:
http://tratt.net/laurie/blog/entries/the_bootstrapped_compiler_and_the_damage_done ↗