Turbo Pascal 开创了低成本 IDE 集成开发环境的时代， Delphi 定义了可视化快速应用开发（RAD）范式， C# 成为主流企业级语言， TypeScript 基本统治了前端世界。

更难得的是： 这四样东西，出自同一个人之手。

The Pragmatic Engineer 最近发布了一期播客访谈，深度采访了 Anders Hejlsberg

 一、最早的计算：没有抽象层的年代

Anders 最早在 HP 2100 小型计算机上编程，这台机器只有 32K 内存 ，用 纸带引导加载程序 启动系统。

他对那个时代的描述非常直观：

"Things were so simple. You could see all the way to the bottom. There was just no layering. It was right on top of the hardware."

——"那时候一切都那么简单。你可以一眼看到最底层，没有任何分层，代码就在硬件之上直接执行。"

想想看，没有操作系统、没有文件系统、没有标准库，连编译器的加载都要靠纸带逐步引导。 过去 50 年计算的发展，本质上就是在硬件之上不断叠加抽象层的过程。

 二、Turbo Pascal：创造一种语言不只是写编译器

售价策略：价格低 10 倍，性能好 10 倍

Turbo Pascal 售价 49.95美元， 而当时竞争对手的编译器售价 500美元 。

Anders 的核心理念非常直白： 语言的成功不仅仅取决于编译器本身，而是 完整 的开发者工作流。

所以他不仅做了编译器，还自己写了配套的 编辑器（IDE） 和 调试器 。在他看来，只给用户一个命令行编译器是不够的。

第一个"调试器"：一个极其优雅的 Hack

当时的硬件限制催生了创造力。Anders 解释了他的第一个调试器是如何实现的：

1. 编译器在运行时出错，打印出程序计数器（PC）地址
2. 你以特殊模式重新运行编译器3. 编译器会停在那个地址4. IDE 显示当前正在解析的是哪一行代码

没有行映射表，没有独立的调试器 ——就靠程序计数器地址和编译器本身，完成了"准调试"功能。这在今天听起来不可想象，但确实工作。

Constraints force creativity. ——限制催生创造力。

 三、C#：一场诉讼催生的语言

背景

微软第一次挖 Anders 过来，是为了让他架构 Visual J++ ——微软的 Java 实现。

但 Sun 诉微软诉讼案（1997-2001） 完全改变了方向。Sun 指控微软对 Java 进行了未经授权的修改，微软被判不能在 Java 基础上继续构建。

微软必须面对现实：要么失去 Java 工具能力，要么造一门 全新的语言 。

C# 和 .NET 由此诞生。

设计团队：6 个人

最初的核心设计团队只有 6 人 ，每周开 3 次会，每次 2 小时 。成员都是 曾经构建过语言的人 。

设计大型语言不需要大团队，需要的是 正确的经验 。

Anders 给 C# 定的设计目标是： 结合 VB 的生产力和 C++ 的能力 。在易用性和底层控制之间找到平衡点。

async/await：为什么被这么多语言效仿

C# 率先引入了 async/await。Anders 说，这解决了一个 共通痛点 ：

手动编写状态机是开发者最讨厌的事情之一。

手动状态机要求你：

• 把所有栈状态转移到对象的字段里

• 把逻辑包进一个巨大的 switch/case

• 自己管理异步流转

开发者讨厌写这个，而 编译器恰好擅长生成状态机 。async/await 让你写顺序化的代码，编译器在背后做那些痛苦的转换。

这个模式后来被 Go、JavaScript（ES2017）、Python、Rust 等语言采用——根本原因就是它解决了一个 所有异步语言都面临的共通问题 。

四、TypeScript：拒绝做 Script#，而是修复 JavaScript

转折点：Outlook.com 团队找上门

Outlook.com 团队找到 Anders 的 C# 团队，希望他们把 Script# （一种将 C# 交叉编译为 JavaScript 的语言）产品化。

Anders 和 C# 团队 拒绝了 。

他们给出的理由非常清晰：要吸引 JavaScript 生态中最优秀的开发者， 你应该让他们写 JavaScript 本身 ，而不是另一门语言。

他们提议的方向是： 修复 JavaScript ——保留其灵活性和生态，加上类型安全。

这就是 TypeScript 的起源。

开源策略

• 2012 年首次发布并开源，托管在 CodePlex （微软自己的平台）

• 但 CodePlex 上社区活跃度不高

• 2014 年迁至 GitHub ，社区爆发式增长

• Anders 明确表示：开源后的 开放开发模式 是 TypeScript 成功的关键原因

TypeScript 编译器架构：打破传统

Anders 介绍了 TypeScript 编译器的设计——它 打破了许多传统编译器实践 ：

当你打开一个大型项目中（比如 VS Code 本身）的 500 个文件时：

• 编译器缓存 499 个文件的抽象语法树

• 只重新构建正在编辑的那个文件

• 通过 Language Server Protocol (LSP) 与编辑器通信

正是这种架构设计，让 VS Code 这种 数百万行代码 的项目也能保持编辑器的流畅响应。

 五、AI 时代的观察

AI 擅长 TypeScript 和 Python 的原因

Anders 的观点非常直截了当： 训练数据量决定一切 。

AI agent 在某种语言中的表现，很大程度上取决于该语言在互联网上的代码数量—— 与语言设计本身关系不大 。TypeScript 和 Python 在互联网上有海量代码，所以 AI 对它们的语法和模式非常熟悉。

AI 在编写编译器方面的局限

但 Anders 的团队发现，AI 在理解编译器设计的"大局"方面还有明显局限——比如类型、符号、绑定和解析之间的关系。

原因也很直接： LLM 的训练集中 包含的编译器相关内容相对较少 。编译器代码在整个互联网代码中的占比太小了 。

代码审查可能成为未来的核心技能

Anders 对未来的预测值得关注：

未来我们都会像 项目经理 一样，管理者由 junior programmer 大军 ——也就是 AI agent——组成，它们会生成大量代码。

他甚至调侃自己也不太喜欢审查代码，但他认为代码审查可以变得更有趣。例如，AI 可以为变更生成评审引导，帮助人类审查者快速定位关键点。

软件编写方式的本质正在改变——开发者越来越多地 描述意图 而非逐行实现，AI 负责生成具体实现。

 六、设计一门语言是 10 年的长期投入

Anders 说了一段非常实在的话：

"Version one is great, but has all sorts of issues. You've got to do version two, but it's not until version three that it really starts to be great. Then you've got to convince people to adopt it."

——"第一版很好，但问题成堆。你必须做第二版，但直到第三版它才真正开始出色。然后你还要说服人们采用它。"

语言设计的周期跨度： 至少 10 年 。

 时间轴速览

 Anders 推荐的书

Algorithms + Data Structures = Programs by Niklaus Wirth（1976）

接近 50 年前的书，到今天依然被语言设计大师推荐——这才是经典。

 原文地址：

https://newsletter.pragmaticengineer.com/p/typescript-c-and-turbo-pascal-with