Overview of TypeScript, C# and Turbo Pascal with Anders Hejlsberg
This episode is a deep dive into how Anders Hejlsberg built some of the most influential programming tools and languages in history: Turbo Pascal, Delphi, C#, and TypeScript. He talks through the origins of each language, the product and platform constraints that shaped them, and the recurring theme across his career: a programming language is never just syntax — it’s the full developer experience, including the IDE, compiler, runtime model, and feedback loop. The conversation also explores how AI is changing programming, why types and tooling matter even more in an AI-heavy world, and what the future of software development may look like.
Key topics discussed
Early programming roots and Turbo Pascal
- Anders got into programming at a Copenhagen high school that offered access to one of Denmark’s first school computers.
- He describes early systems as extremely close to the hardware: paper tape bootloaders, ferrite core memory, tiny storage, and no debuggers.
- He first wrote compilers for small systems and eventually created a Pascal compiler that fit in a 12K ROM.
- Turbo Pascal became successful because it was:
- fast,
- small,
- interactive,
- cheaper than competitors,
- and bundled with the whole workflow, not just a compiler.
Delphi and the move to Windows development
- Delphi evolved Turbo Pascal into a Windows GUI and client-server development platform.
- Its success came from combining:
- rapid application development,
- compiled-language performance,
- object orientation,
- and strong tooling via the VCL component model.
- Anders notes that even decades later, Delphi remained important in real-world systems like Skype.
Microsoft, Java, and the birth of C#
- Anders joined Microsoft in the mid-1990s to work on Java tooling, specifically Visual J++.
- The Sun vs. Microsoft lawsuit undermined J++ as a long-term platform bet.
- Microsoft wanted one language/runtime that could satisfy:
- Visual Basic users,
- C++ users,
- and developers wanting Java-like modern features.
- That led to the simultaneous creation of:
- .NET as a language-neutral runtime,
- and C# as the language designed to sit in the middle of VB’s productivity and C++’s power.
How C# was designed
- The language was designed by a small team of around 6–7 experienced language designers.
- They met several times a week and intentionally stress-tested ideas by trying to break them.
- C# was built around:
- object orientation,
- garbage collection,
- exception handling,
- reflection,
- value types and boxing,
- properties, methods, and events as first-class concepts,
- and standardization.
Roslyn and the compiler/IDE merge
- Early C# had two implementations: a command-line compiler and a separate interactive language service for the IDE.
- That duplication became painful as the language grew.
- Roslyn unified the compiler and IDE experience into one engine that could serve both command-line builds and interactive editor features.
TypeScript: why it had to be open source
- TypeScript was designed as a superset of JavaScript with a type system added for tooling and scale.
- Microsoft knew it could not win JavaScript developers with a proprietary language.
- Open source was essential, but it was initially politically difficult inside Microsoft.
- Moving from CodePlex to GitHub was a major turning point:
- it improved adoption,
- and also changed the workflow from “open source” to true “open development.”
Main takeaways and lessons
1. Developer tools are the product
- Anders repeatedly emphasizes that a language is only part of the story.
- The real product is the full cycle:
- edit,
- compile,
- run,
- debug,
- refactor,
- and get feedback quickly.
- This is why IDEs matter so much to language design.
2. Fast feedback drives adoption
- Turbo Pascal and TypeScript both succeeded in part because they made developers more productive through speed and interactivity.
- In TypeScript, the goal was to keep IDE feedback under roughly 200 milliseconds.
- This required highly incremental, lazy, and reusable compiler architecture.
3. Types are primarily for tooling and scale in TypeScript
- TypeScript’s types are erased at runtime.
- Their value is in:
- better editor support,
- safer refactoring,
- go-to-definition,
- find-all-references,
- and catching mistakes early.
- Gradual typing is what makes TypeScript unusually practical: types can be added where needed, but aren’t mandatory everywhere.
4. Async/await succeeded because compilers can build the hard parts
- Anders explains async/await as a way for the compiler to transform sequential-looking code into a state machine automatically.
- It solved a major pain point in callback- and event-loop-heavy environments.
- Its popularity came from making asynchronous programming feel natural while retaining performance and control.
5. Constraints create innovation
- JavaScript’s lack of type system helped motivate TypeScript.
- JavaScript’s historical lack of modules made large-scale code harder to reason about.
- The need to support large codebases, IDEs, and AI tooling pushes languages toward:
- stronger types,
- better locality,
- and clearer module boundaries.
AI and the future of programming
How AI is used in Anders’ team today
- AI is used for:
- code review,
- writing tests,
- handling simple issue fixes,
- and helping migrate old pull requests during the TypeScript native-code port.
- It is useful for “grudgery” work, but not yet for replacing deep understanding.
What AI changes about language design
- Anders argues that AI is best at producing code in languages it has seen the most.
- TypeScript, JavaScript, and Python are strong fits because they’re heavily represented in training data.
- He believes languages that will work best with AI need:
- types,
- inference,
- strong locality,
- clear modules,
- and good semantic tooling.
Semantic tools matter more than grep
- AI agents often rely on text search tools, but that is not enough for large systems.
- Anders thinks language services and semantic search will become increasingly important for AI-assisted development.
- The next step is for AI to ask semantic questions of live codebases, not just search for strings.
The developer’s role is changing
- He sees software engineers increasingly acting like:
- project managers,
- reviewers,
- and architecture overseers.
- AI can generate more code, but humans remain responsible for correctness, design, and judgment.
- “Vibe coding” can work, but only until something breaks and deep understanding is required.
Recommended book
Anders’ book pick
- Programs + Data Structures = Algorithms by Niklaus Wirth
- Why he recommends it:
- practical,
- example-driven,
- light on symbolism,
- foundational for understanding programming languages and compilers,
- still relevant decades later.
Notable insights
- “Language design is a 10-year cycle.”
- “The compiler is not the product — the whole experience is.”
- “You cannot build good tooling without a type system.”
- “AI is a tool to make programmers more productive, not to remove the need for programmers.”
- “Good languages reduce friction and keep developers in the zone.”
Final takeaway
This conversation shows that Anders Hejlsberg’s biggest contribution is not just inventing languages, but repeatedly designing ecosystems that make developers more effective. Whether it was Turbo Pascal’s speed, Delphi’s GUI productivity, C#’s balance of power and usability, or TypeScript’s type-driven tooling, the pattern is the same: great developer tools remove friction, provide fast feedback, and help programmers stay in flow.