IDE Toolkit

Room 5 · The Builders

From Turbo Pascal to TypeScript — One Engineer's Through-Line

The compiler that proved the argument

Four Borland Turbo Pascal floppy disks numbered 1 through 4 arranged in a grid

Turbo Pascal 7.0 on four disks — Borland International, Scotts Valley, copyright 1983 and 1992.

Photo: Turbo Pascal 7.0 Install Floppy Discs (Deutsch) · Wikimedia Commons

Anders Hejlsberg arrived at Borland International in the early 1980s as the author of a Pascal compiler he had written in Copenhagen — a single-pass compiler coded in assembly language, small enough to stay entirely resident in memory. Philippe Kahn licensed it and built a product around it: Turbo Pascal, which shipped in November 1983 at $49.95 when competing Pascal compilers cost hundreds of dollars and demanded separate link steps measured in minutes. Hejlsberg's engineering decision — keep the compiler in RAM, compile in one pass, write results straight to disk — produced a feedback loop that felt instant. The gap between writing code and running it collapsed.

That collapse was not cosmetic. It changed what a developer could attempt in a session. When a build takes twenty minutes, a programmer plans before typing; when it takes two seconds, the program becomes a conversation. Hejlsberg's compiler, fitted inside an integrated editor and debugger on a single floppy, made the iterative style practical on hardware that had no room for anything else. The constraint produced the design, and the design outlasted the constraint.

Two people work at glowing desktop monitors displaying code in a dim room

One workstation, one screen, and a component library you could open and read.

Borland released successive Turbo Pascal versions through the late 1980s, each adding object-oriented features while preserving the compilation speed. By Turbo Pascal 5.5 in 1989, the language supported objects with inheritance and virtual methods — grafted onto Pascal syntax with care not to break the single-pass discipline. The type system remained explicit and strict: every variable declared, every procedure parameter typed, the compiler catching category errors before execution. That insistence on static types would remain the longest thread in Hejlsberg's career.

Delphi and the component model

When Borland began designing what would become Delphi, released in February 1995, Hejlsberg led the language team. The language was Object Pascal — a fuller object model than the Turbo Pascal extensions — but the more consequential engineering was the component architecture beneath the visual form designer. Delphi's Visual Component Library (VCL) allowed any developer to build a reusable component in the same language used for application logic, drop it onto a palette, and wire its properties in a designer without leaving the IDE. The component was not a scripted object attached to a runtime; it was a compiled first-class entity with a published interface the designer could inspect at design time.

That inspection — a form designer reading a component's properties through the type system and displaying them in a live property sheet — required the type system to carry enough information at compile time and runtime to support reflection. Hejlsberg built that into the Object Pascal runtime. The result was an environment where the type system and the visual designer reinforced each other: strong types made component introspection reliable, and reliable introspection made visual composition safe. Delphi was a commercial success from its first year and established that a statically typed language could anchor a rapid-application development environment without sacrificing correctness.

The argument Delphi made was competitive as well as technical. Visual Basic, Microsoft's dominant form-based tool, used late binding and a dynamic component model that sacrificed type safety for simplicity. Hejlsberg's Delphi demonstrated that safety and speed were not in opposition — that a designer fast enough to feel playful could sit on top of a language strict enough to catch real errors.

Vintage Power Macintosh tower computer with CRT monitor, keyboard, and external drives on display

Period hardware on a museum plinth — the class of machine these compilers were sized for.

Photo: Ruben Boekeloo / Pexels

C# and the language as platform surface

Microsoft hired Hejlsberg away from Borland in 1996. His first major project there was the Windows Foundation Classes, a Java-compatible class library that was later withdrawn when Sun Microsystems challenged it. The episode redirected him. Beginning in 1999, he led the design of C# and the Common Language Runtime — the type system at the centre of what Microsoft released as the .NET Framework in 2000 and 2001.

C# was not a Pascal with curly braces, though the genealogy is visible in the design choices. The language launched with a unified type system in which value types and reference types share a common base, eliminating the primitive/object split that forced explicit boxing in Java. It added properties as a first-class language feature — a direct descendant of Delphi's published property mechanism — and delegates for type-safe callbacks. Where Borland had demonstrated that static types could accelerate development, Hejlsberg now had to demonstrate that a managed runtime could do the same on the Windows platform at enterprise scale.

The BuildersWhen Borland began designing what would become Delphi, released in February 1995, Hejlsberg led the language team.

Later C# versions, developed under his continued direction, added generics in C# 2.0 (2005), LINQ and lambda expressions in C# 3.0 (2007), and async/await in C# 5.0 (2012). Each addition preserved backward compatibility while extending expressiveness — a discipline that reflects the same engineering philosophy as the original Turbo Pascal compiler: the constraint of not breaking existing code shapes the design toward precision rather than novelty. LINQ in particular was a type-safe query language embedded in C# syntax, enforcing at compile time what SQL databases enforced only at runtime.

TypeScript and the type system at scale

By 2010, JavaScript had become the inescapable language of the web, and it was untyped. Hejlsberg began working on TypeScript at Microsoft, and the project went public in October 2012. The core decision was structural: TypeScript is a typed superset of JavaScript, meaning any valid JavaScript is valid TypeScript, and the type annotations are erased before execution. The language adds no runtime overhead and requires no new engine.

The type system TypeScript introduced is structural rather than nominal — types are compatible if their shapes match, not if they share a declared inheritance chain. This suited JavaScript's duck-typed idioms while bringing static analysis to codebases that had grown to millions of lines without it. Union types, intersection types, conditional types, and template literal types accumulated across subsequent releases, each addition making it possible to express more of what JavaScript's flexible runtime behaviour actually does — so that the type system describes real programs rather than forcing programs to fit the type system.

The Language Server Protocol, which Microsoft published in 2016 and which TypeScript's own language server helped motivate, meant that the type intelligence Hejlsberg had built became portable across editors — the same completions, diagnostics, and go-to-definition available in VS Code, Vim, Emacs, and anywhere else that implemented the protocol. The compiler as a service, not a binary that owned its output.

Four decades from a single-pass compiler that fit on a floppy to a type system serving hundreds of millions of web pages: the throughline is the conviction that catching errors at compile time, before a program runs, is not a burden on the developer but a form of speed — the same speed that made Turbo Pascal feel like a conversation in 1983. The tools changed; the argument did not.