On Language Design
summary
Claim: design languages to solve the real problem (telecom timing, concurrency, fault tolerance), not to indulge syntax or add features. Implementation notes: build small, well‑chosen primitives with keep basics simple, expose explicit asynchronous semantics so tools can be layered, and prefer tools not solutions over special cases. Evidence: a language designed for telecoms yields a working massively concurrent fault‑tolerant platform; maintenance costs dominate, so semantics is king and documentation must explain why choices exist.
AI-written summary · about
chapters (21)
- 0:00Intro
- 1:40Dont be nice to users
- 3:54What is the problem
- 6:26Keep it simple
- 11:34Semantics
- 12:00Syntax is irrelevant
- 13:28Syntax should reflect semantics
- 14:09Avoid providing alternative syntax
- 16:10Restricting features
- 22:23Be Consistent
- 22:50Be Explicit
- 23:47Be Implicit
- 24:39Focus
- 32:06Maintenance
- 34:54Simplicity
- 38:34Community
- 41:04Syntax
- 46:29Scala operators
- 48:37Simple is complicated
- 51:57Go being specialized
- 56:40Static typing
related talks
42mA Game of Theories: Why languages do what they do
47mA Game of Theories: why languages do what they do
39mInvent the future, don't recreate the past
22mThe Linguistic Relativity of Programming Languages
27mDesigning Even Larger (JavaScript) Applications
01h 00mWhat were they thinking? Language design choices that seem wrong, until they don't.
36mWhat's in a language?
50mSyntax Matters