TypeScript, C#, and Turbo Pascal: Lessons from Language Design Legend Anders Hejlsberg
#Regulation

TypeScript, C#, and Turbo Pascal: Lessons from Language Design Legend Anders Hejlsberg

DevOps Reporter
5 min read

A deep dive into the career of programming language design legend Anders Hejlsberg, creator of Turbo Pascal, C#, and TypeScript, with insights on language design principles and the future of software engineering.

In a wide-ranging conversation, programming language design legend Anders Hejlsberg shared insights from his remarkable career spanning Turbo Pascal, C#, and TypeScript. As one of the most influential language designers of all time, Hejlsberg's work has shaped how millions of developers write code over the past four decades.

From Paper Tape to Modern Development

Hejlsberg began his programming journey on an HP 2100 with just 32K of memory and a paper tape boot loader. "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," he recalls. This foundational experience shaped his approach to language design, understanding the relationship between code and hardware at the most fundamental level.

The past 50 years of computing, as Hejlsberg observes, have been a process of adding layers above the hardware. Yet his work has always maintained a balance between abstraction and performance.

Turbo Pascal: The Power of Complete Tooling

When Hejlsberg created Turbo Pascal, he understood that success required more than just a compiler. He built an IDE for editing programs and a debugger for troubleshooting them. This comprehensive approach to the developer workflow became a pattern throughout his career.

Turbo Pascal's business strategy was equally innovative. It sold for $49.95 when competing compilers cost $500, offering "10x better for 1/10th of the price." This approach not only won the market but conveniently killed off piracy through its affordability.

The first Turbo Pascal "debugger" was an elegant hack born of constraints. The compiler would print the program counter address on a runtime error, allowing developers to re-run the compiler in a mode that stopped at that address. The IDE would then show which line was being processed at that point. "Constraints force creativity!" Hejlsberg emphasizes.

C# might never have existed without a famous court case. Microsoft originally hired Hejlsberg to architect its Java tools (Visual J++), but the Sun versus Microsoft lawsuit (1997-2001) forced Microsoft to abandon its Java strategy. The company needed a new language that combined Visual Basic's productivity with C++'s power, leading to C# and .NET.

The original C# design team numbered just six people who met three times weekly for two-hour sessions. "Designing even large languages does not require a large team; it's the right experience that matters most," Hejlsberg explains. The team consisted of experienced language designers who had built languages before.

One of C#'s most influential contributions was the async/await pattern that many languages later adopted. Hejlsberg notes this pattern spread because compilers can generate state machines that humans hate writing. "Manual state machines require moving all stack states into objects and wrapping logic in a giant case statement. Devs generally loath doing this by hand, and async/await lets developers write sequential-looking code while the compiler does the painful rewrite behind the scenes."

TypeScript: Fixing JavaScript, Not Replacing It

TypeScript's origin story reveals Hejlsberg's pragmatic approach. Microsoft's Outlook.com team initially asked his C# team to productize "Script#," a language to cross-compile C# to JavaScript. Hejlsberg and his team pushed back, arguing that a better approach was to fix JavaScript itself.

"To be attractive to the best-of-breed developers in the JavaScript ecosystem, you want people to write JavaScript, and not another language like C#," he explains. This philosophy guided TypeScript's design from the beginning.

TypeScript was open source from the start in 2012 on CodePlex, but gained significant momentum after moving to GitHub in 2014. "Open development on GitHub is what I credit for making TypeScript as good as it has become," Hejlsberg acknowledges.

The TypeScript compiler breaks traditional practices with its lazy evaluation approach. With 500 files open, the compiler keeps abstract syntax trees (ASTs) cached for 499 files and rebuilds just the one being edited. It only resolves the minimum types needed for the cursor's current position, enabling responsive editing even in large codebases.

AI and the Future of Programming

When asked about AI's impact on programming languages, Hejlsberg offers a nuanced perspective. "The language best suited for AI is the one that AI has seen the most in its training set. How well AI agents work in a specific language largely depends on how much of that language exists on the internet. It has less to do with the design of a language."

However, AI has limitations in compiler development. "LLM training sets don't contain much about compilers as yet," Hejlsberg explains. His team finds AI limited in seeing the "big picture"—how types, symbols, binding, and parsing all relate in a compiler.

Looking ahead, Hejlsberg predicts significant changes in software craftsmanship: "We'll all be project managers in the future, managing armies of junior programmers, aka agents, which generate reams of code." While he's personally less interested in reviewing code, he suggests that code review could become more interesting with AI generating commentary that guides reviewers through changes.

Designing Languages for Decades

Hejlsberg's career offers valuable lessons for language designers: "Designing a programming language is a 10-year play. 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."

His work across Turbo Pascal, C#, and TypeScript demonstrates a consistent pattern of identifying developer pain points and creating elegant solutions that balance power with productivity. Each language addressed specific needs in its ecosystem while maintaining a focus on the complete developer experience.

For developers today, Hejlsberg's journey offers important reminders: tooling matters as much as the language itself, constraints can drive innovation, and successful language design requires thinking about the entire developer workflow, not just syntax and semantics.

To hear more from Anders Hejlsberg, you can listen to the full episode on YouTube, Spotify, or Apple Podcasts. The transcript with timestamps is available at the top of the episode page.

Resources

Antithesis

Comments

Loading comments...