JVMLS 2015 - Compilers are Databases
JavaCited 4× on HN, 2016–2022
talk · advanced · evergreen · 2016–2022 on HN
Martin Odersky's JVM Language Summit 2015 talk argues that compilers can be thought of as databases. It describes design ideas for the Scala compiler and for developer tools.
Cited as the origin of the compilers-as-databases idea in discussions of IDEs and incremental tooling.
Up next
13 mo on HNRich Harris - Rethinking reactivity
You Gotta Love Frontend
15 HN recommender · 2019–2026
12 mo on HNLexical Scanning in Go - Rob Pike
GoogleFOSSSydney
13 HN recommender · 2012–2025
12 mo on HNWilliam Byrd on "The Most Beautiful Program Ever Written" [PWL NYC]
PapersWeLove
11 HN recommender · 2017–2026
10 mo on HNCppCon 2016: Jason Turner “Rich Code for Tiny Computers: A Simple Commodore 64 Game in C++17”
CppCon
13 HN recommender · 2016–2024
8 mo on HNClasp: Common Lisp using LLVM and C++ for Molecular Metaprogramming
Google TechTalks
8 HN recommender · 2015–2024
7 mo on HNCompiling C to printable x86, to make an executable research paper
suckerpinch
8 HN recommender · 2018–2023
7 mo on HNBreak Me00 The MoVfuscator Turning mov into a soul crushing RE nightmare Christopher Domas
Adrian Crenshaw
6 HN recommender · 2017–2026
7 mo on HNA Talk Near the Future of Python (a.k.a., Dave live-codes a WebAssembly Interpreter)
David Beazley
7 HN recommender · 2019–2025
7 mo on HNMiguel de Icaza: Swift Godot: Fixing the Multi-million dollar mistake #GodotCon2023
Godot Engine
6 HN recommender · 2023–2026
6 mo on HNCppCon 2017: Matt Godbolt “What Has My Compiler Done for Me Lately? Unbolting the Compiler's Lid”
CppCon
7 HN recommender · 2018–2022
5 mo on HNCo-dfns Live Stream: Compiler Design and Architecture
Aaron Hsu (arcfide)
3 HN recommender · 2018–2025
5 mo on HNEric Bier Demonstrates Cedar
Computer History Museum
3 HN recommender · 2020–2025
4 comments from Hacker News
Martin Odersky (lead designer of Scala) also pursued this approach some years ago, not sure if any of this actually went into Scala3. He mentioned this in many talks before, such as ▶ this video (JVMLS 2015 - Compilers are Databases)
The author frames this as a contest between two architectures: either spend a lot of effort building custom developer tools, or repurpose the compiler as a server for multiple clients. Both approaches have their tradeoffs: the first, as the author mentions, violates DRY [1]. The second violates the Unix philosophy [2]. However, there is a third way . Both developer tools and compilers can be seen as special cases of a much simpler and more general pattern known as a graph database [3, 4, 5]. [1]: link [2]: link [3]: ▶ this video [4]: link [5]: link
Depth. Every programmer I admire has worked on their chosen field for years. You can keep flitting between languages and frameworks, but mastery ultimately comes from hankering down on one thing and advancing our collective knowledge a bit further. You can achieve mastery in any field - it can be a business domain - as mundane as a Time Tracking or a Todo list app, or it can be a technical domain - like compilers or databases or browsers. You however can't achieve mastery by consuming what others produce. Becoming an expert in CSS and its quirks is a good vocational investment, but you're no closer to a fundamental understanding of the field by just consuming an API. You should spend years working on a problem domain that interests you. Look at prettydiff ( link ). It is a diff tool, a parser, a pretty printer, a minifier, all rolled into one. It is the most comprehensive publicly available tool in terms of language and dialect support in the world right now. Its code is not the most modular and new contributors might have trouble getting in, but its author has been at this problem for years, and if you called a conference for pretty-printing, he would be one among the few thousand people in the world to meaningfully participate. Consider blueimp's jQuery File Upload plugin ( link ). While this isn't as foundational a work as prettydiff, the project spans seven years and a thousand commits. It solves a mundane problem, but the sheer effort that has went into it makes it a
This number is not true I guess. scalac with idomatic Scala code (no Macro's) is at 500-700 loc/sec. (And scalac is considered slow by many people) Source: ▶ this video That would be a slowdown of like 4x to current javac, I guess his computer is just not good enough?