Some interesting platforms :

 Antithesis – verify your system’s correctness in the development loop. Build, extend and deploy mission-critical systems : without human review or traditional integration tests, all while avoiding embarrassing outages. Antithesis goes far beyond code review and runs your complete system, exhaustively analyzing its behavior, and exposes bugs as quickly as agents introduce them.

• WorkOS – Anders has spent decades thinking in programming languages — WorkOS speaks the same language when it comes to enterprise infrastructure : SSO, SCIM, RBAC, and more, built right so you never have to.

• turbopuffer – a ridiculously scalable, fast and cheap vector and full-text search engine. Cursor moved to turbopuffer after their existing vector database couldn’t keep up with the number of codebases they were adding. This move cut their semantic search costs by 95%, and they have so many good things to say about turbopuffer.

Anders Hejlsberg is a living legend and one of the most influential programming language designers of all time. He created Turbo Pascal, Delphi, C#, and also TypeScript. As well as that, he spent nearly a decade at the pioneering dev tools company, Borland, and is now in his 30th year of working at Microsoft, where he’s a Technical Fellow.

The Pragmatic Engineer newsletter discuss with him what it takes to build programming languages that developers love to use, and trace his career from writing his first compiler to creating Turbo Pascal and Delphi, and helping to pioneer modern software development through C# and TypeScript.

Here are 13 of the most interesting takeaways from talking with Anders :

1. The first computers had zero abstractions on top of the hardware. Anders started programming on an HP 2100 with 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 says. The past 50 years of computing have been a process of adding layers above the hardware.

2. Turbo Pascal won by being more than “just” a compiler. Anders also built an IDE to edit Turbo Pascal programs in, and a debugger to troubleshoot them with. In later languages which Anders designed, he always focused on the entire developer workflow, not just compilation.

3. “10x better for 1/10th of the price” is a proven winner. This is what Turbo Pascal did : it sold for $49.95 when competing compilers cost $500, and it was faster and more interactive than competitors’ products. Conveniently, the low price tag also killed off piracy

4. The first Turbo Pascal “debugger” was an elegant hack. The compiler printed the program counter address on a runtime error. Then you could re-run the compiler in a mode that stopped at that address, and the IDE would show which line was being syntactically processed at that point. There were no line maps or debuggers built for this debugging experience : Constraints force creativity !

5. C# might might not exist without a famous court case. Microsoft originally hired Anders to architect its Java tools (Visual J++), but the Sun versus Microsoft lawsuit (1997-2001) meant Microsoft could not build on top of Java, as the company that owned Java’s IP (Sun) sued MS for alleged unauthorized changes to the Java language. Microsoft realized it had to build a new language that combined VB’s productivity with C++’s power. This led to C# and .NET.

6. The original C# design team numbered only six. They held three meetings per week which lasted two hours each, during which they debated what to build. Anders believes that designing even large languages does not require a large team ; it’s the right experience that matters most. In that group, this meant folks who had built languages before.

7. C# introduced the async/await pattern that many languages later ran with. Anders said this pattern spread to so many other languages 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.

8. TypeScript exists because Anders refused to build ScriptSharp for the Outlook.com team. Microsoft’s Outlook.com team asked Anders’ C# team to productize “ScriptSharp,” a language to cross-compile C# to JavaScript. Anders and the C# team pushed back, suggesting that a better approach was to fix JavaScript. Anders felt strongly that 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#.

9. Open development on GitHub made TypeScript much better. TypeScript was open source from the beginning in 2012 on CodePlex, Microsoft’s open source platform. There was not much community activity there, and in 2014, the project moved to GitHub with its large, active community. “Open development” on GitHub is what Anders credits for making TypeScript as good as it has become.

10. The TypeScript compiler breaks many traditional practices. The compiler is built to support lazy evaluations, and deferred imports, and is functional by necessity. For example, with 500 files open, the compiler keeps abstract syntax trees (ASTs) cached for 499, and rebuilds just the one being edited. It only resolves the minimum types needed for the cursor’s current position.

11. Training data volume is what makes AI great at TypeScript and Python. Anders says 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.

12. But AI is limited for writing compilers – for now, at least. On Anders’ team, AI is limited in terms of seeing the “big picture” ; for example, how types, symbols, binding, and parsing all relate. It’s because LLM training sets don’t contain much about compilers as yet.

13. Reviewing code could be the future of the craft. Anders predicts we’ll all be project managers in the future, managing armies of junior programmers, aka agents, which generate reams of code. Anders admits he is less interested in reviewing code, personally, but reckons code review could be made much more interesting ; for example, AI generating commentary that guides reviewers through changes.

To conclude, Designing a programming language is a 10-year play. As Anders puts it :

“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.”