Creator of TypeScript: 10x Faster Typescript, Why AI Won't Replace SWEs | Anders Hejlsberg

Anders Hejlsberg is the creator of TypeScript and C#, and I asked him about how the TypeScript compiler got 10x faster through a rewrite in Go and his thoughts on how AI has impacted software engineering. • My ergonomic keyboard project I mentioned, you can follow along here: https://read.compose.llc/ • The Kickstarter page for it: https://www.kickstarter.com/projects/ryanlpeterman/compose-simple-ergonomics-beautifully-done Podcast links: • YouTube: https://www.youtube.com/watch?v=cywK3XYYJ2o • Apple: https://podcasts.apple.com/us/podcast/the-peterman-pod/id1777363835 • Transcript: https://www.developing.dev/p/creator-of-typescript-10x-faster Thank you to this episode's sponsors for supporting my work: • WorkOS: makes your app Enterprise Ready with easy to use APIs to add SSO, SCIM, RBAC, and more in just a few lines of code, check them out at https://workos.com/ • Jira by Atlassian: Get more work done with your favorite agents and models all in one place, check them out at https://jira.dev/ Timestamps: (00:00) Intro (00:48) Why write a compiler in JavaScript (07:29) Why rewrite the compiler in Go (14:49) LLMs for large migrations (20:12) Why Javascript is so popular (26:32) Why ever use Javascript on the backend (32:59) What it takes to build a programming language (37:06) Will there be fewer languages in 10 years (42:57) Hands on engineering vs delegation (49:14) Why fast tooling matters more now (51:16) AI software engineering predictions (58:52) The most technically challenging work (01:02:04) Top book recommendation (01:03:50) Advice for his younger self (01:05:00) Outro Where to find Anders: • GitHub: https://github.com/ahejlsberg • X/Twitter: https://x.com/ahejlsberg • Wikipedia: https://en.wikipedia.org/wiki/Anders_Hejlsberg • LinkedIn: https://www.linkedin.com/in/ahejlsberg/ Where to find Ryan: • Newsletter: https://www.developing.dev/ • X/Twitter: https://x.com/ryanlpeterman • LinkedIn: https://www.linkedin.com/in/ryanlpeterman/ • Threads: https://www.threads.com/@ryanlpeterman • Instagram: https://www.instagram.com/ryanlpeterman • TikTok: https://www.tiktok.com/@ryanlpeterman Referenced in this episode: • Flow type checker repository: https://github.com/facebook/flow • TypeScript compiler repository: https://github.com/microsoft/TypeScript • Algorithms + Data Structures = Programs (book): https://en.wikipedia.org/wiki/Algorithms_%2B_Data_Structures_%3D_Programs • TypeScript native rewrite: https://devblogs.microsoft.com/typescript/announcing-typescript-7-0/

Speaker names marked ? are inferred from speaking time and the show’s known hosts — they are not voice-verified.

• 0:00Speaker 00

  Don't let people tell you that it can't be done. When they tell you it can't be done, it's because they can't do it.

• 0:05Ryan Peterman?

  This is Anders Hejlsberg, the creator of TypeScript and C#. And we talked about how TypeScript recently became 10 times faster through a native rewrite.

• 0:15Speaker 00

  Couldn't we like fix JavaScript? Wouldn't that be better? Do you know what I mean?

• 0:20Ryan Peterman?

  If you think about Rust, what didn't it have that if it had it, you would have picked it?

• 0:25Speaker 00

  I mean, I think there are two things.

• 0:28Speaker 00

  If you're gonna hand AI the keys, I mean, then all bets are off, right?

• 0:33Ryan Peterman?

  Why is there such a big difference between this opinion and what I see from maybe people who work at Anthropic?

• 0:40Speaker 00

  People love these like take it all the way to 100%, right? And that's where I get off the bus.

• 0:47Ryan Peterman?

  Here's the full episode.

• 0:51Ryan Peterman?

  The big thing that we're gonna talk about here is obviously TypeScript 7 with the native rewrite. And the first thing that I think of when I see this was I didn't even realize that the compiler was written in JavaScript to begin with. Because I don't usually think of compilers being written in, you know, high-level dynamic languages.

• 1:09Speaker 00

  Yeah, no.

• 1:11Ryan Peterman?

  So why was TypeScript written originally, the compiler written in JavaScript?

• 1:17Speaker 00

  No, it's a good question.

• 1:20Speaker 00

  And honestly, if you had told me like before the TypeScript project started that Anders, you're gonna be writing compilers in JavaScript, I'm like, no, no, I'm not. But I mean, it, you know, the original prototypes for TypeScript, the Strata project, as it was called in the very early days, was actually written in C because it was like an adaptation of the parser, the JavaScript parser that we had in IE and whatever. And then we moved to JavaScript, but we wrote it sort of C# style. But why did, why did we go with JavaScript? Well, I mean, if you can self-host in the ecosystem that you wanna be a part of,

• 2:04Speaker 00

  then that is just dramatically better than putting yourself outside the ecosystem and trying to target that ecosystem. Do you know what I mean? Because by writing it in TypeScript, we were also daily users of TypeScript and daily users of the tooling that we were building. And whenever something didn't work right, we knew it immediately. And whenever something didn't perform right, we knew it, you know? And so, so in the early, in the early years, it was, it was a huge boom, I think. And then, of course, JavaScript runs everywhere, right? And that meant automatically our compiler could run on every platform, anywhere, even in the browser, right? Had we gone with a native code solution at that time, it wouldn't have been possible to run it in the browser.

• 2:49Speaker 00

  Now we have WebAssembly or Wasm, you know, but that didn't exist at the time, right? So, so it was, it was a meaningful choice. And honestly, at that time also, people didn't really realize how fast JavaScript had gotten. I mean, it used to be very slow. And then Google did all of their excellent work with V8 and got it to within 2 or 3X of native code, which is pretty darn impressive.

• 3:20Speaker 00

  And it was like full well possible to write compilers in JavaScript.

• 3:27Speaker 00

  And you could even get them performant because often it's the algorithms that determine how performant you are. It isn't necessarily the runtime environment, right? I mean, it's a combo, but, but yeah.

• 3:38Ryan Peterman?

  Is there anything unique about the TypeScript compiler? Like, you know, I think of a compiler, I think of Clang or, or, you know, one of those ones that is used for maybe C, C++, or those static languages. What's unique about the TypeScript compiler when it was written in JavaScript compared to these native compilers?

• 4:00Speaker 00

  I think there are a couple of things that are pretty unique about TypeScript's compiler. First of all, it doesn't target machine code, it targets JavaScript.

• 4:11Speaker 00

  And, and some people call that a transpiler. And in a sense, you know, the, the compilation phase is mostly about removing the type annotations and turning your TypeScript back into JavaScript, right? Now, in the early days, also, an important part of, of the compilation process was to down-level your JavaScript, meaning all of the runtime environments at the time were not evergreen. And sometimes people were lagging like multiple years behind on which level of the standard was implemented. And for example, when classes got standardized, most JavaScript runtimes didn't implement classes. But it turns out that you can down-level to constructor functions and, and transform the code.

• 4:55Speaker 00

  And so, part of what we did was this transformation, down-level, transpiling of the code. But then, of course, the type checking is, is the big thing that we do. And the type checker in, in TypeScript is also quite unlike any other type checker in other compilers. Typically, type checkers exist in compilers to guide the code generator. Because you wanna know, are we dealing with a float or an int or a string here so we can generate, you know, the correct machine instructions for that data type, et cetera, et cetera? That's not the case in TypeScript. In fact, since we erased the types, the types have no impact whatsoever on the runtime behavior of the code.

• 5:40Speaker 00

  They purely exist for, for tooling sake and for the developer's sake. And to guide things like statement completion and refactoring and code navigation, which is a whole different thing. And also, they don't necessarily have to be there. And so, TypeScript has a gradual type system. You can sort of have half of your code have types and the other half is just any's that we don't check. Now, very few languages have anything like that. So, so it's very, it's a very different compiler in, in that sense, you know, and a very different language in that sense. That actually made it fascinating to work on because we were solving problems that no one had solved before, you know?

• 6:25Ryan Peterman?

  I know a lot of compilers, you know, they take the, the higher level code and they typically apply optimizations as well. Maybe, you know, they unroll loops or they get rid of duplicate instructions, simplify things. Is anything like that happen in the TypeScript to Java compilation process?

• 6:44Speaker 00

  Very little.

• 6:46Speaker 00

  Like I said, when we do the down-leveling, there, there are some transformations that, that go on that are, that are complex. But it is less and less the thing that's important about TypeScript. And in fact, a lot of people use TypeScript only for the type checker. And then they use some bundler like ESBuild or SWC or whatever to package their app, erase the types, do whatever needs to be done in order to make it runnable in, in the browser. And so, we're not really there to optimize your, your code for runtime. We're there to make you more productive as a developer or make AI more productive as a, as a developer.

• 7:29Ryan Peterman?

  So with the, the native rewrite of this originally fully JavaScript compiler, what was the problem you were trying to solve with the rewrite? And why did you end up rewriting it in native code?

• 7:43Speaker 00

  Well, I mean, the, the problem we were trying to solve is real simple, performance and scalability. JavaScript was never really optimized for compute-intensive workloads like compilers, right? JavaScript is more about creating UI that runs in a browser, was originally intended for just like maybe 100 lines of code, but now, of course, it's gotten to be a lot more. But it's not, it's not a place that, that you would optimize for, for the kind of workload that, that we are. So in JavaScript, first of all, you pay a 2 to 3X perf penalty compared to native code. I mean, it depends on, on the workload, you know, but that's, but if, if you're doing compute, that's about where it's at.

• 8:30Speaker 00

  And then secondly, in JavaScript, there are a lot of restrictions around use of concurrency. JavaScript was always engineered, in fact, to be a single-threaded language. That's why we have callbacks and async and, and whatever. It's because you can't spin up threads. And that's a good thing mostly because concurrency in a language with mutable data is very, very hard because you could have races and deadlock and all of this good stuff, right? That's why functional programming languages are easier with concurrency because all the data is immutable and it's much easier to reason about.

• 9:09Speaker 00

  So JavaScript doesn't give you access to concurrency other than web workers. And but web workers can't share data between each other other than by remoting it. So you can, you can have one web worker compute some, something, but if it wants to give it to some other web worker, it has to turn it into JSON. Or it can't just hand it objects. And that means you can't have one worker compute some data structure and then have someone else use it. In other words, you can't have shared memory concurrency. And really, that's what we wanted in order to gain all of the perf that we were leaving on the table by not utilizing multi-core CPUs that everyone has today, right?

• 9:53Speaker 00

  Because Moore's Law has stopped giving us faster CPUs, it's giving us more CPUs. And we gotta like find ways to use them in our, in our compute-intensive workloads or else we're leaving money on the table. And so, we were leaving money on the table in multiple ways, right? And so, native code, and that was why we, we looked for a language that...

• 10:15Speaker 00

  Would get us out of both of those binds. It had to be native and it had to have access to shared memory concurrency.

• 10:21Ryan Peterman?

  I saw for the language choice, you went with Go. And when I think of all the systems languages, the ones that are often hot are maybe Rust or Zig. Why did you choose Go for the native rewrite?

• 10:35Speaker 00

  I think the decision process was actually pretty structured. You know, the first decision we made was we're not going to rewrite. We're going to port. Because only by porting can we preserve the semantics and the algorithms and the exact behavior of our existing compiler, which everyone depends on for backwards compatibility. Now, we could have cleaned the slate and started completely from scratch, but we would have come up with a different language in the sense that it would give you different errors or behave differently in certain situations where it has to make choices between multiple possibilities and what have you, right? So we wanted to port.

• 11:17Speaker 00

  And that meant our code makes certain assumptions, like our code, for example, assumes the existence of garbage collection. It assumes the existence of first-class treatment of functions. You know, you can have functions within functions and you can close over out of state and so forth. And as we evaluated all of these, Go was the one that checked the most boxes. You know, it gives us very robust and mature native code generation on all major platforms. It has garbage collection and it has excellent access to shared memory concurrency.

• 12:01Speaker 00

  And those were like the high order bits that we wanted to check. And every other language had something that kind of worked against those objectives. So for this particular workload, Go was the right choice for us. And it's worked out well.

• 12:16Ryan Peterman?

  If you think about Rust, what didn't it have that if it had it, you would have picked it?

• 12:22Speaker 00

  I mean, I think there are two things. It doesn't have garbage collection. It's done manually, you know? Well, or it's done through the borrow checker, but the borrow checker doesn't allow circular data structures. And our compiler is chock full of circular data structures. We have trees with param pointers. We have types that are recursive. We have symbols that refer. I mean, it's everywhere. And like I said, if we had chosen to rewrite, we could have probably solved all of that. But it wouldn't have been just porting the code. It would also have been like solving a whole bunch of new problems that we had bought ourselves by going that route. We tried. And it just wasn't feasible, you know?

• 13:07Speaker 00

  And so we were just trying to optimize for, you know, doing as little work as possible to get us to the payout, which is, which, and honestly, Rust is no better when it comes to like the quality of the generated code or the concurrency gains that we could have gotten out of it. Go is just, it's great. I mean, so we got all the Bennys for less work by going that route.

• 13:35Ryan Peterman?

  I know some languages, they're, when you say they're garbage collected, they, there's something in the language itself that is doing garbage collection, but there's also independent libraries that can provide garbage collection, right?

• 13:51Speaker 00

  There is, but it comes often with a whole bunch of restrictions and it doesn't come necessarily with the safety guarantees that we were looking for. I mean, like Go is type safe and memory safe, meaning that you don't get to just like have stray pointers or whatever where Rust, you can do refcounting or you can do, you can do all sorts of different strategies, but there's always like that little bit of unsafe where you have to like do this in order to make it all work, you know? Where, where if garbage collection is engineered into the language, it really is a separate concern.

• 14:32Speaker 00

  That is, you don't, you don't have to do anything special in, I mean, of course, you have to like not hold on to data that you no longer need and whatever, you know? But that's true of refcounting as well, right? But, but it is inherent in, in the language.

• 14:49Ryan Peterman?

  When you ported it from JavaScript to Go, I'm curious how much LLMs were used in that process because I know famously there's some major projects that have been doing rewrites of their entire code base. I know there's this JavaScript project called Bun that rewrote everything from Zig into Rust. And so it seems like a pretty useful tactic and I'm curious if you leverage that in this process.

• 15:16Speaker 00

  Not a whole lot, but it also has to do with timing. We started this project two years ago and two years ago, LLMs were nowhere near as good as they are now. I mean, that's how crazy fast it's all moved, right?

• 15:31Speaker 00

  So what we did though, is we certainly had a bunch of tools that aided us in the, in the, in the port. I'd say the prototypes we wrote, the scanner and the parser, we wrote manually.

• 15:47Speaker 00

  And at that point, we could convince ourselves, wow, we can actually get 10x out of this. Now, what do we do with the rest of this code base? And what we did was we wrote a tool that syntactically translates TypeScript into Go.

• 16:03Speaker 00

  This Go that comes out of it, it has no syntax errors in it, but it doesn't compile either because it's full of, you know, like it uses types as if they were TypeScript, which they're not in Go. And so all of that had to be refactored. We had to redo all the data structures or whatever, but we got the same code base out of it and then we could sort of bang on that. And then in a more localized fashion, maybe use AI occasionally to help us do the transformation. So it was sort of manual and automated and a little bit of AI. Now, if we were to start the project today, would we do it differently? Possibly.

• 16:42Speaker 00

  Although I will say, if we just let AI loose on, you know, what is it, like a half million lines of code that we have in the old compiler or somewhere between half a million and a million, right? And asked it to translate it all, well, I don't know that that would absolve us from then having go in and carefully examining every line that came out of it to make sure that there were no hallucinations, right? Unless you have 100% perfect test coverage, you probably still got to go check all of that. Now, I think a better approach, quite honestly, would be enlist AI to write a program that helps you translate from TypeScript to Go.

• 17:21Speaker 00

  Because at that point, you can park the stochasticness in that program and then you can get deterministic behavior whenever you run the program, which means you get the same transformation every time you run it, right? That's always the thing about AI that people forget. It's not deterministic, right? So you can't really trust that it's going to do the same thing twice.

• 17:44Speaker 00

  So, so we might have done it that way, but AI was not ready to do it at the time. Now, that doesn't mean that we don't use AI. I mean, like now down the line, we use AI a lot in our, in our internal processes around like the compiler, as everyone does, right? Like help it to write tests and to move pull requests and what have you. And whenever an issue is logged, we, first thing we do is put copilot on and see if it can fix it for us, right? I mean, and so, yeah.

• 18:12Ryan Peterman?

  In that approach where you, you use the LLM to generate tooling and then, you know, the tooling's deterministic, but you'd still have to validate that thing.

• 18:23Speaker 00

  Yes, but that's, that's a lot smaller surface area that you have to validate, right? And honestly, I've seen that even with friends that are like, we did some trip together and there was like some, some accounting of the, well, he paid for the hotel rooms and we paid for this and whatever, and we needed to like sort it all out, right? And so, so, okay, well, here's what all the costs were and here are the pieces and like have AI fix it for us, right? Or like tell who owes who what. And it very authoritatively came up with the wrong answer, right? Because it just forgot like about some of the settlements, right? And, but if we had asked it to write a spreadsheet.

• 19:02Speaker 00

  Which is really, this is just a program, right? Then we would have gotten the right answer because it's very good at writing programs. So it's kind of funny how you don't ask, sometimes you don't ask AI for the answer. You ask it for a program that computes the answer.

• 19:17Ryan Peterman?

  What are the potential benefits that you left on the table by doing a port instead of a full rewrite?

• 19:23Speaker 00

  To be honest, I don't think there are any. And I don't think we would consider a rewrite. We were quite happy, we're quite happy with the way this codebase works. And we certainly, I don't think we're leaving any money on the table currently. And as I said earlier, rewrites are toxic often for ecosystems because they sacrifice compatibility. Because you never rewrite and you get, you never get back to exactly what you had before, right? Oh, but, oh, but in the name of making it better or prettier or whatever, we change this and that and this and that and the other, right? And then, well, all the users get to suffer through that, right?

• 20:03Speaker 00

  So backwards compatibility is super important if you want to keep your ecosystem happy. And we do want that.

• 20:12Ryan Peterman?

  In studying for this interview, I just keep reading about JavaScript and the strange semantics of the language. And I think throughout my career too, people have typically not been super satisfied or happy with JavaScript for some reason or the other.

• 20:29Speaker 00

  Right.

• 20:30Ryan Peterman?

  And my question is, why is it so popular despite that?

• 20:36Speaker 00

  So first of all, I don't think JavaScript is as bad of a language as some people make it out to be. I will say in like the three, what, three, four weeks that Brendan Icke had to create this language back in the mid 90s, he did a lot of things right. And thank God that he had been educated on functional programming and got first-class functions done right, where you can have functions within functions and the inner functions can access the outer function state. And you can pass functions around as first-class values. That is super powerful. And JavaScript actually got that very right.

• 21:15Speaker 00

  Now, there's some quirks in the language too, like all of the automatic conversions and all of the bizarre differences between double equals and triple equals are just like, drives everyone mad, right? But that's exactly what type checkers are happy to do. They can like, they can ferret out all the little differences because they understand that all the deep semantics of the language that no one seems to be able to keep in their mind, right? So, and I think that's part of why TypeScript has become so popular, right? It's like, it can actually like truly bring out the best parts of JavaScript and leave the bad stuff behind. And of course, you can't like, like the thing about JavaScript is it is the cross-platform language.

• 21:58Speaker 00

  Like even Java that was engineered and intended to be the way to write cross-platform applications, it's not really cross-platform. It doesn't run in the browser, you know, I mean, it doesn't, it doesn't run everywhere, right? JavaScript runs everywhere.

• 22:14Speaker 00

  So there are a lot of, there are a lot of reasons why you should like JavaScript. And with TypeScript, I think we've managed to sort of capture all the badness and park it.

• 22:27Ryan Peterman?

  I saw there were some projects, I don't know if you're familiar with Dart or CoffeeScript? And it seems like these were some effort to replace JavaScript or improve it and

• 22:40Speaker 00

  Right, right.

• 22:41Ryan Peterman?

  But they're not popular today, so I'm curious what happened.

• 22:44Speaker 00

  I mean, I think CoffeeScript was mostly, it's a different syntax for JavaScript. So it doesn't really change the semantics and it doesn't, it didn't provide any additional tooling and whatever. And Dart was also, in a sense, about fixing JavaScript, right? But if you can fix something by fixing it instead of trying to replace it with something else, then you're doing the ecosystem a much bigger favor, I think, right? And that's what we set out to do with TypeScript. We weren't trying to change JavaScript, we were trying to improve JavaScript.

• 23:24Speaker 00

  And I think that's ultimately why we, why we succeeded.

• 23:28Ryan Peterman?

  I mean, in this new age where it's very feasible that maybe AI could rewrite codebases, I imagine people will start to go towards the desired languages rather than the ones that are the incumbent languages. And I'm curious if you think that JavaScript might become less used in the future?

• 23:51Speaker 00

  See, I don't think so. I, what I've observed is that AI is best at the languages if seen the most of in its training set, right? And AI gets trained on all the code that exists in the world.

• 24:09Speaker 00

  Which means there's an awful lot of JavaScript, an awful lot of TypeScript, an awful lot of Python. And therefore, AI is good at JavaScript and TypeScript and Python. And it is less good at my favorite little language that I just invented. In fact, there's none of it in the training set, which means you have to sacrifice god knows how many tokens in the prompt to teach AI the language before you can even ask it a question about the language. Do you know what I mean? So in that sense, I think incumbent languages are actually, if anything, going to flourish because of AI. And we're sort of seeing that right now with TypeScript too, right? There's a noticeable knee in the curve of TypeScript adoption that coincides with the advent of AI.

• 24:54Speaker 00

  I do think the incumbent languages are actually, if anything, getting stronger.

• 24:58Ryan Peterman?

  What percent of all JavaScript is written in TypeScript?

• 25:04Speaker 00

  Well, so, so in the last year, TypeScript became the number one used language on GitHub.

• 25:14Ryan Peterman?

  More than JavaScript?

• 25:15Speaker 00

  More than JavaScript.

• 25:16Ryan Peterman?

  Oh.

• 25:16Speaker 00

  So more than 50% on GitHub at least is written in TypeScript. So we're actually like larger now than the language that we set out to improve.

• 25:28Ryan Peterman?

  Wow.

• 25:29Speaker 00

  Yeah, kind of larger than Python.

• 25:31Ryan Peterman?

  If you were to just draw that out in the future, do you think that eventually TypeScript would become the default and almost 100% of all JavaScript would be typed?

• 25:41Speaker 00

  Well, certainly, I mean, if you're having AI write it, I, I almost challenge you to find a tool that writes JavaScript. They all write TypeScript because it helps AI write better code. Because the type annotations guide the LLM towards writing, or towards making fewer mistakes. And the ability for us to statically validate the code before you run it. I mean, that's the distinction, right? The only way you can validate JavaScript is by running it. Which means you have to set up a runtime environment, which might not be possible for AI to do because AI lives in a sandbox, right? But AI can run through tools, the compiler, and check the code that it just generated

• 26:25Speaker 00

  and be told, oh, you made a mistake. Oh, well, let me fix it then before I even tell anyone that I made the mistake, right?

• 26:32Ryan Peterman?

  After learning about this 10x improvement in performance from rewriting in native, it makes me wonder why anyone would use JavaScript on the backend. Why not just always use native languages on the backend?

• 26:48Speaker 00

  Well, it depends on your problem, I think. Because the thing that that overlooks is what kind of thing am I going to write on the backend? You know, like, there are an awful lot of very, very good web server frameworks, for example, that use TypeScript or JavaScript, right? So if there are like frameworks in your ecosystem that get you to a solution quicker, then if you had to write that because your native language wasn't really intended to target that particular community. So I think it very much depends on your, what your problem is affinitized with. And often perf of your code isn't the bottleneck.

• 27:34Speaker 00

  I mean, like, look at Python, I mean, right? It's used to basically script and all of the LLM training in the world, right? I mean, which clearly a lot of that code is ultra-time critical. But that's written in native code, right? And then you use Python as the orchestration language. And in a sense, in a web server, you know, like TypeScript is just an orchestrator, you know, of talking to a database and doing this and that, and the things that, the things that ultimately control the performance of applications like that aren't necessarily whether that inner for loop is running as native code or not. Which actually, it is because of the JIT anyway, right? I mean, so.

• 28:18Speaker 00

  I mean, measure, measure first and then big decisions, right? Because you always get surprised when you measure.

• 28:26Ryan Peterman?

  When you talk about how much faster it was too, one of my immediate thoughts is why wasn't it done sooner?

• 28:33Speaker 00

  You know, at the time we started TypeScript, I don't know that we had ever envisioned that people would be writing projects that are the size of the projects that people are now writing in TypeScript, right? Like Visual Studio Code is like 2.3 million lines of code. I mean, we have in-house projects that are over 10 million lines of code, which is insanity. We would have just at the time gone, well, that's clearly no one's ever going to do that, right? But that was a decade ago, more than a decade ago, right? We started in 2012 with the TypeScript project and the world looked very different. And so gradually, people have started writing larger and larger and larger projects, right? And at the same time, our compiler has gotten smarter and smarter.

• 29:18Speaker 00

  We've added all sorts of cool features like union types and discriminated unions and control flow analysis and blah, blah, blah. And all these things make our type checking even better, but it also makes it go a little slower every time we add a new feature, right? In fact, our TypeScript 6 runs only about 50% of the speed of TypeScript 1.5, for example. But TypeScript 1.5 also did a whole lot less.

• 29:45Speaker 00

  So projects have gotten bigger and the compiler does more, all of which detract from your effective output. And as I mentioned, Moore's Law also unfortunately stopped delivering faster CPUs and JavaScript keeps you from taking advantage of the additional cores. It's not clear that we could have foreseen all of that, right? But it's just the way it panned out, right?

• 30:11Ryan Peterman?

  OpenAI, Anthropic, Cursor and Vercel all use this product to make their lives better. And the problem it solves is when you're building SaaS or an AI product and you want to sell to other companies, there's all these requirements you need to meet. There's SSO, there's SCIM, there's RBAC, there's audit logs. These are all things that take time to integrate, but aren't the main focus of your app. WorkOS is an API layer that lets you meet all of these requirements in just a few lines of code. So let's say you have a new SaaS product and you want to sell to other companies. WorkOS will solve all of these critical feature gaps for you. You can check them out at workos.com to learn more and get started. And I appreciate them for supporting my work and sponsoring this podcast.

• 30:57Ryan Peterman?

  Jira by Atlassian isn't just for tracking work anymore. Now you can pick your favorite AI agent to assign tasks to and they'll get access to the rich context that's already in Jira. When the agent is done, it surfaces a pull request. That way you can get more done with your favorite agents all in one place. Learn more at jira.dev, that's J I R A dot D E V. Appreciate them for sponsoring the podcast and back to the show. When I first became a software engineer and I went to start working at Facebook at the time, they had this popular framework called Flow, which was doing type inference on top of JavaScript. There was this thing that would take a long time. And then I'd never hear about it these days.

• 31:41Ryan Peterman?

  So it sounds like TypeScript won if there was a competition to typing JavaScript.

• 31:46Speaker 00

  There was a bit of it, yeah, in the early days.

• 31:51Speaker 00

  I think the thing that worked for us was actually the fact that we were self-hosted, which made it a lot easier for the community to contribute to the project.

• 32:01Speaker 00

  Flow was written, as I recall, in Camel. And so in order to contribute to Flow, you had to go learn a whole different way of programming and in a different language, right? And Flow also didn't really focus all that much on IDE-based tooling, which we knew full well going in. We're writing a compiler, but we're not writing a compiler in order to generate machine code. We're writing it to make better tooling. That was why we wrote it, you know? And so right there, hand in hand with our compiler, we had a language service. It was deeply integrated into Visual Studio, Visual Studio Code, all sorts of other editors through an open protocol, you know?

• 32:42Speaker 00

  And that just, that's where, that was the problem that needed solving, right? I mean, it's not, it's nice to have a type checker, but boy, you want that. You also want statement completion, you want red squigglies, you want like, I mean, you want it interactive, right?

• 32:59Ryan Peterman?

  So I know in your career, you've worked on multiple programming languages. What does it take to build a programming language?

• 33:07Speaker 00

  Well, first I'll say that the world needs another programming language like it needs another hole in the head. I mean, it's like you kind of gotta be a certain kind of a person to even embark on it to begin with, right? It's a super fascinating area of computer science and it's one that's been around ever since the beginning of computers. Now, every compiler, every language has a whole bunch of things you need to understand, like parsers and scanners and lexers and code generators and whatever, right? But that's sort of the mechanics of implementing the language.

• 33:46Speaker 00

  And then there's the design of the language, sort of the art of making it feel right, whatever, right? And I think you sort of have to master both. And then you also got to appreciate that like every new language is actually only 10% new. And then it's 90% the same drudgery that every other language has to go do. And so be prepared for a lot of work that maybe isn't as interesting, you know?

• 34:16Speaker 00

  And then finally, maybe I'll say that, you know, like, never forget there that you stand on the shoulders of giants. I mean, in order to make a great programming language, you got to understand a bunch of other programming languages first and understand all the distinctions between the different styles of programming, like procedural and object-oriented or functional or what have you.

• 34:40Speaker 00

  And then last but not least, it's like, it's a long game. I mean, it is probably a longer game than anything else. I mean, like every language project I've worked on, I've worked on each of them for at least 10 years

• 34:56Speaker 00

  and shipped multiple versions. And it's really never until version three that it truly starts to get okay. Do you know what I mean? And it just takes an incredible amount of devotion to that. So you got to really not be the type that tires of a problem quickly and then moves along. That you're not meant to do language design.

• 35:17Speaker 00

  And you see that too, if, when you talk to language designers in the industry, they've been doing it for a long time.

• 35:22Ryan Peterman?

  You mentioned those two parts. There's the, the objective pieces that you need to implement. And then there's the, the art of the design and making the language, I guess, ergonomic for developers. When you think of that second part, that art, and you look at other programming languages, are there any that you admire outside of the ones that you've worked on, of course?

• 35:46Speaker 00

  Learning and fully appreciating the beauty of functional programming has been very educational, right? I mean, because it really is a different way of thinking about programming. A way of thinking of programming is much closer to math than it is to machines.

• 36:07Speaker 00

  And I think there's, there's a lot of incredible goodness that has come from that. And then honestly, even in like building TypeScript project, a large portions of the TypeScript compiler are written in a highly functional style and work on immutable data structures that are then now, because of shared memory concurrency, can be shared between different

• 36:32Speaker 00

  threads or processes that don't mutate the data. And therefore they can share one data structure, right? And that's incredibly powerful. But mastering this, you know, like writing islands of pure functional programming inside an imperative program and putting it together with concurrents. I mean, it's, it's complex, but I think functional programming has brought a lot to the world. I know object-oriented programming as well. I mean, but I wouldn't single out any particular language. Every one language you come in contact with, you learn something, you know?

• 37:06Ryan Peterman?

  You mentioned the world doesn't really need more programming languages. And if you think 10 years from now, do you think there'll be less programming languages than there are today?

• 37:19Speaker 00

  It's hard to say. I mean, but like I said, AI tends to favor the incumbents, right? And I do think, and I think this has been true even before AI, the bar keeps going up for what it takes to successfully implement a programming language and create an ecosystem around it. I mean, it used to be, oh, you just need a compiler.

• 37:45Speaker 00

  Well, you also kind of need tooling now. I mean, you need a language service, you need, you need debuggers, you need profilers, you need frameworks and libraries, you need code generators that can target all sorts of, I mean, it's like, it just keeps getting harder and harder, you know, to get all the way there.

• 38:08Ryan Peterman?

  Well, when you think about all those pieces, they're really, they're all for the people. I mean, the, you know, the IDE and the types. And I mean, the computer looks at that too, but it's so that we can read source. Maybe one day the LLMs will generate machine code directly.

• 38:28Speaker 00

  I wonder.

• 38:32Speaker 00

  I think.

• 38:35Speaker 00

  I think L L Ms are better at what they do when when they don't have to repeat themselves a lot. I I I think like.

• 38:46Speaker 00

  When a program is expressed in text, it is closest to its sort of ultimate

• 38:54Speaker 00

  condensed meaning and representation, right? If you translate it into machine code, there's an awful lot of noise in that machine code like all of the instructions, like half of the instructions are memory addresses that have absolutely no bearing on what's going on here, right? So half of it, half of all the data is noise already, right? And then whichever register you pick, well, that doesn't matter either in the code generator. And honestly, you could change your mind at any point in time. So so teasing the truth out of that noise is a lot harder than if you just have a program where the variable is called I and whatever. And by the way, that you can relate to the written instruction that the user just gave you.

• 39:34Speaker 00

  I mean, keep in mind that that like A I are, they're just emulators of humans in a sense, right? I mean, they they it's like neural networks, right? There's a reason we have programming languages because we're terrible at writing machine code straight off out of our head, right? A I is not that different from us, you know? So the same would probably be true there.

• 39:56Ryan Peterman?

  When you look back on working on C sharp and you know, TypeScript and these language projects, they were long journeys and I think, yeah, one thing people might want to know is what did you learn through those journeys? That if you knew at the beginning of when you embarked on working on them, you you might have been better off?

• 40:19Speaker 00

  Gosh, well, each journey is is different. I mean, like the first project I worked on Turbo Pascal, I I think

• 40:30Speaker 00

  that project started back in the old days when it was eight bit micros and sixty four K of memory. And one person could do everything themselves and have ultimate control of everything. And so I was very much a one man shop, right? But that quickly was not scalable, right? And and and capacities of machines that we went for sixty four to six forty K. And then then kaboom, the the the lid went off, right? And you could have as much memory as you wanted. And so not one person couldn't do it. And I had to learn to become a team player, right? And that that was a big journey for me. I mean, to learn to let go, right? If you're a perfectionist, that that that could be hard. But that's one thing that I would say I learned there.

• 41:14Ryan Peterman?

  Well, another way to word this question is, you know, what's the most common mistake that you see people make when they embark on building a programming language?

• 41:24Speaker 00

  Well, I think people tend to over index on one idea, you know, that that they have that they think, oh, wouldn't it be cool if my language could do blah? And then they under index on all of the mundane stuff that every programming language has to do, you know? And then it ends up doing that one thing they love maybe better, but then it does everything else not as good. And and and the net is a detractor, right? And so it's so hard to convey how many things you have to do that really doesn't have anything to do with the problem you're you're trying to solve per se. You know, when you're implementing programming languages.

• 42:06Ryan Peterman?

  And when you were working on C sharp, do you keep tabs on the other languages? And you know what they're doing better, what you could do better with C sharp?

• 42:15Speaker 00

  Yeah, no, you gotta keep yourself informed about it because, like I said, we all stand on the shoulders of giants, you know? No other, no, no programming language was ever created in in in perfect isolation, right? Everyone learns from from everyone and then someone comes up with a good idea and then you see it adopted elsewhere. And we've adopted many ideas from functional programming, you know, in C sharp, for example. And then other languages have adopted some of the good ideas we had in C sharp, like async, you know, now is in JavaScript and in some of the other programming languages out there. And that was pioneered in in C sharp. And so, you know, it's it's, we all learn from each other. And and that's how the industry moves forward, really.

• 42:57Ryan Peterman?

  You mentioned the, I guess, learning to let go. I think that's something that a lot of people, as their career advances, they they start with you know, individual contributor work and then later they start delegating things. How did you learn that or what was the, is there like a maybe a story or particular project where you you let go? And you you kind of develop that skill?

• 43:21Speaker 00

  Well, it's it's almost like I got a counter story to the to the letting letting go there because in the C sharp project, my main function was not implementing the the C sharp compiler. It was being the language designer and writing the spec and designing all the new language features. And

• 43:41Speaker 00

  before that, when I when I had worked on Turbo Pascal, I was I was doing a bunch of active coding, you know, on on the thing itself, right? But then I sort of let go of that, but I let go of it too much. And I sort of drifted up into the stratosphere and became more of an architecture astronaut. Do you know what I mean? And and and I wasn't getting my hands dirty. I was writing stuff in the framework and in the libraries, but it wasn't, it didn't quite. These are not like the deep, really super hard problems to solve, right? And and I didn't really know it at the time, but I was gradually getting less happy with with the work that I was that I was doing, right? I mean, it's I still enjoy it, but there was something missing, right? And so when when this TypeScript opportunity came along,

• 44:26Speaker 00

  I decided to jump in and actually actively participating, writing compiler. And it brought so much happiness to my life. Like I I I finally realized I'm just I'm just a happy coder, you know? I mean, I like the the spec stuff too, but but coding is like, man, that's what gets me up in the morning, make coffee and write some code. You know, that's that's that's that's when I'm my in in my happy space, you know?

• 44:50Ryan Peterman?

  You know, when people are at these really, really high levels, they kind of have this expectation of a certain level of impact. And so how do you continue to write code at as such a high level engineer?

• 45:02Speaker 00

  Well, the specific code I'm writing isn't necessarily having all all that impact. But it's it's the fact that I also do the architectural guidance, you know, as part of a a group of people, right? In a in a project, you know, there's plenty of work for everyone to go around and then you you just, but you you you stay involved in a corner of the project because then you see what happens in the code. You know, when you're checking in your code, you go, what was what what was that over there? Let me just, what what's happening over here? You know, or you realize, oh, we need to refactor this. This this is not, this is not feeling right anymore. Or if if, but if you let go of that, you don't really, you can't really talk about the thing that people use day to day.

• 45:46Speaker 00

  You can talk about the syntax of the thing that people use day to day, but you can't talk about that thing, you know? So

• 45:54Speaker 00

  so both are important, I think, and I'm happy that I get to do both now.

• 45:58Ryan Peterman?

  I know a lot of companies have this idea of engineering archetypes or the the way that high level engineers get some work done. And you mentioned architect, for instance, a lot of companies have different words for architect. I I'm not sure if you're saying it's just your working style or are you saying that all high level engineers should be hands on at some level?

• 46:21Speaker 00

  No, I I'm not saying that because I don't think it's it's like I made a conscious choice to remain an independent contributor as opposed to become a manager. I mean, I have plenty of opportunities. But but it that is not where I do my best work, right? So I think you have to decide for yourself, what is it that motivates you, makes you happy, keeps you doing this for for a lifetime? Do you know what I mean? And and and you only get one run at it in in life here, you know? And so and if you're gonna do your best work, do the thing that that makes you the most happy, I think. Yes, and then that's what I

• 47:03Speaker 00

  learned, you know, a a along the way there, that coding is part of that, a big part of that.

• 47:10Ryan Peterman?

  So then, when you were working on C sharp but before TypeScript, like, how did you know something was missing?

• 47:16Speaker 00

  I just knew something. I I I don't know how, I mean, it just, I would, I just wasn't feeling as fulfilled with with with with only doing the design part, right? I I I missed the coding and whenever I had a chance to write a little bit of code, I would feel a lot happier and I go, it's kind of interesting. I mean, do you do you know what I mean? But now I gotta go write some more specs, you know?

• 47:41Ryan Peterman?

  So then was TypeScript something you kind of went towards because you wanted to write more code?

• 47:46Speaker 00

  Well, I went towards it for for many reasons. I mean, it wasn't specifically that to begin with. I just found the problem fascinating, right? I mean, because the way TypeScript came about was actually indirectly through C sharp. Because the Outlook dot com team, I think it was, approached the C sharp group and asked whether we would pretty please productize something called Script Sharp. And Script Sharp was this thing that took C sharp and transpiled it into JavaScript. So you could run it in a browser. And I'm like, what? Why would you want to do that? Why don't you just write the Java? Well, because that way we can get great tooling.

• 48:27Speaker 00

  Then we can use Visual Studio and we can have projects and we can have type checking and we can have code refactoring and navigation and we can write interfaces and people can understand how this all works. And I'm like, wow. Is JavaScript really that busted? And you're saying like the way you want to fix that problem is by abandoning JavaScript, treating it as an instruction language, right? And then having a code generator target it. I'm like, couldn't we like fix JavaScript? Wouldn't that be better? Do you know what I mean? And that's how TypeScript kind of got off the ground, right? It was like, gosh, there's something here that's really broken that needs to be fixed, right? And when it comes to JavaScript tooling.

• 49:12Speaker 00

  And that's what we set out to do.

• 49:14Ryan Peterman?

  You know, one thing I thought would be interesting is in one of the talks that you gave, you said that you believe that the speed of your tooling is more important now because of AI. And I want to hear thoughts on why is that the case?

• 49:30Speaker 00

  Well, more and more our workflows now are dominated by agents that are like running away in the background, right? I mean, like writing code for you. And they make mistakes just like we do, but they but they but you know, but you can have as many of them as you want. So there are like many, many more little workers in the ecosystem writing much more code, right? And that whole workflow is like L L Ms already have performance challenging. And then if you add like if you're writing code in a big project and you have to like type check it and it takes two minutes every time the L L M writes something, do you know what I mean? That's horrible, right? So making that go faster is a big benefit.

• 50:14Ryan Peterman?

  Yeah, absolutely. I guess because it's it's hammering away.

• 50:17Speaker 00

  Yeah, because I mean, like, like, well, we all know L L Ms, they like to use grep and whatever, right? But then they're also smart enough now to realize that if you're like trying to change this property called version and like every other object has a version property, you can't just grep for version and then go rename it to something else. Because like you're breaking all these other interfaces that have a version in them, right? So you got to do semantic search. And the only thing that can do semantic search is a compiler. And so you got to use the compiler through typically through L S P, through language services or through our command line tool that would give you the equivalent, right?

• 51:01Speaker 00

  And so more and more AI is doing that. And that means, you know, compilers run at you don't you may not even see that they're running, but they're running. And they're doing work on your behalf, yeah.

• 51:16Ryan Peterman?

  When you talk about AI, it's very realistic and grounded in the software engineering. And so I thought it might be interesting to run some common AI takes that I hear from the internet and you get your sense of how accurate is this? What are your thoughts on when or if it'll be true? Okay, so the first one that I've heard, this was more come at the end of last year, is that, you know, AI is going to write 90 plus percent of the code, you know, within a year. Curious what you think on that.

• 51:51Speaker 00

  Well, for certain classes of apps that that might be like all the vibe code of apps are writing 100% of the code, right? And there's an awful lot of that being written. Are they going to write 90% of the high quality code on the internet? I don't know about that. So the thing is like 90% of what? The volume of written code is just like going like that right now, right? Because AI writes so much code. So so in a sense, that's a self fulfilling prophecy, right? But but but when it comes to like the super high quality code that no one has ever written before, it's not clear to me that AI is going to write 90% of that.

• 52:35Ryan Peterman?

  So when you think about cases that AI is not writing all the code, maybe some examples of the super high quality stuff, what is that?

• 52:44Speaker 00

  Well, I mean, it's it's algorithms that no one has ever seen before, for example, or or particular solutions like, I mean, I know that AI could not write our compiler, the TypeScript compiler, it just can't. I mean, we've tried, it can't do it. And I'm not asking it to either. I mean, I'm not expecting it to either. But but our compiler is also not a typical piece of code. I mean, and that's why it's bad at writing it because it's seen none of it in the training set. Well, I've seen some compilers, but not like this one, not with these concepts, not with done the way that we're doing it, right? And so it's just not a good fit there.

• 53:26Speaker 00

  AI, we can't forget that AI is at heart a big stochastic machine that has memorized the entire internet, right? And and is ability and has an ability to extrapolate somewhat over what it's memorized, right? But if it hasn't seen it before, it's it's it's not necessarily going to be all that good at at doing it. It's getting better. I mean, I'm not saying it's it's not impressive. It's wildly impressive what it can do. But I just think there's a long way still to it's doing all of it. And I don't know that we ever get there. I hope we don't because then what's the point of humans anymore than I mean, it's.

• 54:09Ryan Peterman?

  What I see this take often too is, you know, you won't need to use an IDE within the year or you don't need to read the code anymore.

• 54:19Speaker 00

  Well, good luck to you. I mean, if you're going to hand AI the keys, I mean, then all bets are off, right? I mean, the minute AI you can't convince AI to fix this issue or this new feature that you want built, what are you going to do? I mean, if you don't understand what's below, right? That's that's one problem. The other problem is let's say a user comes to you and goes, your app just stole my bank account. Well, it's going to sue you. It's not they're going to sue you, not the AI. I mean, it's like at the end of the day, someone has to take responsibility for what AI is doing. And if you're giving it the keys, well, it's on you, you know? But but I don't know.

• 55:03Speaker 00

  I personally would not feel comfortable. I wouldn't be able to go to sleep at night. I mean, if I didn't understand what it is that I am vouching for.

• 55:13Ryan Peterman?

  Why is there such a big difference between this opinion and what I see from maybe people who work at Anthropic?

• 55:22Speaker 00

  Well, the difference is all I'm saying here is not that AI can't do amazing things. It does, it can, it does that every day. But but people love these like take it all the way to 100%, right? And that's where I get off the bus a little bit, right? I think, oh, yeah, okay, fine, we can get we can get higher and higher percentage. But there still has to be someone understanding what's going on and how it's relevant to our business problem and how it relates to what our organization is doing. And like, I mean, there's so many other things that have to be connected that it's I think it's wrong to just view it as AI did it all and we were completely unnecessary, you know?

• 56:04Ryan Peterman?

  Yeah, the next one I was going to ask you was, you know, three years from now, will AI replace junior software engineers or what junior software engineers do today?

• 56:13Speaker 00

  Well, if it does, then how do we ever get senior software engineers? Right? I mean, it's like, I don't think so. Well, I'm not unless you also believe that you will be able to do your business three years later than that without any senior software engineers.

• 56:30Ryan Peterman?

  Right.

• 56:30Speaker 00

  Because where are they going to come from? You got to train them. I mean, and but to me, I think maybe one thing that to some extent has happened is that for certain classes of programmers, the pyramid has narrowed at the bottom, right? There are fewer people coming in. And we are wanting them to advance higher up faster so that they can get to this more supervisory role, right? I think the craft of being a software engineer is definitely changing from your typing in lines of code to you're having agents type in lines of code and you are reviewing the work of the agents, right?

• 57:13Speaker 00

  And so so you do more reviewing, less typing. And some people love that, you know? I mean, and really are fantastic at that workflow, right? But it's it's a change in nature of what the job looks like as a programmer. And this tool that you now have in a toolbox is having that impact, right? But it is but a tool. And there are still programmers involved in the in the process, that I firmly believe.

• 57:43Ryan Peterman?

  It sounds like you enjoy typing out the code. Would you be less happy if five years from now?

• 57:48Speaker 00

  I for 40, 50 years, I have enjoyed typing out code. I'm actually there there some and so I will continue to type certain parts of the code, you know? But there are other parts of the code that I don't particularly care to type. I don't care to type in tests and follow all the rigor of the particular testing framework. Heck, no, if I can farm that out to AI, happy me, you know? I do think reviewing has always been harder for me. It's harder for me to like spend time on reviewing other people's code than it is, you know, writing the code. But I also think that over time, we will, we can make that process of reviewing code much more ergonomic than it is today, right?

• 58:32Speaker 00

  I mean, often today, you just get here's like the list of the files that were changed and here are the deltas, you figure it out, right? I mean, AI could help us more there by explaining what the changes are and whatever. And so I think we're going to get better. This is going to get more interesting, but it will change the nature of the craft.

• 58:52Ryan Peterman?

  You said that you've been writing code for 40, maybe 50 years.

• 58:58Ryan Peterman?

  What is the hardest piece of code you've ever written? Or what's the most technically challenging thing you've ever done?

• 59:05Speaker 00

  There are so many things that in their time were challenging, you know.

• 59:13Speaker 00

  I mean, this last project we worked on, we knew that like, like, you know, sort of the easy part was getting the native code. That's just like, just move it to this other language, right? But then this taming this beast called, uh, shared memory concurrency and, and getting the compiler to use like as many CPUs as there are available on your box, right? That is not a simple problem to solve in a, in a, in a compiler. Because we're all taught to write sequential stuff, right? I mean, first you do this, then you do this, but how do you do all of this at the same time? And then share the data structures afterwards without anyone like accidentally modifying the other guy's data structure?

• 59:58Speaker 00

  And, you know, how do you, in the cases where you have to do that, how do you then synchronize it and avoid deadlocks and race conditions? And, and, and whatever, right? This, it was, it was tricky. Uh, there were some good technical problems, uh, that, that we licked that I think we can be proud of, you know, but.

• 1:00:14Ryan Peterman?

  What about when hardware was more constrained earlier in your career? Is there any wacky thing you had to do to kind of, you know, make it work?

• 1:00:23Speaker 00

  Oh, totally. I mean, when I started, it was a, like, being a programmer was a very, very different thing, right? I mean, I started out with, with eight bit micros that had, and Microsoft Basic in ROM, right? And, and that basic interpreter and, and you could buy these books and type in these Star Wars games or, or, or whatever. They were all text, you know, there's just scrolling and, and telling you there's Klingons over in that quadrant, you know, and K4, you know? God, whatever, right?

• 1:00:55Speaker 00

  But I got fascinated with understanding how it was all put together and, and, and quickly learned how to write, uh, assembly code. And Turbo Pascal, the first product I worked on, was all written in Z80 assembly code.

• 1:01:11Speaker 00

  The compiler, the editor, the runtime library, everything was assembly. And writing structured, a compiler in assembly code is like, that, that was, that was like, took a lot of fiddling, you know? And, I mean, and you were counting like, okay, I think I can, I need to, we need to squeeze this into this e-prom. And then there's only 12K, you know, and I'm, I'm 20 bytes over budget here. Oh, but I can make this jump, this long jump. Instead, I could jump to this short jump and then jumps to that jump. And then I could save one, that's one byte saved, okay? You know, moving right along. And you would, you would, you would, you would just like sit there and fiddling, you know? It was, it was a craft. It was like woodworking almost.

• 1:01:54Speaker 00

  I mean, it was just so different from what we do now, right? Everything is now, it's bottomless pits of capacity and, and, and, and bottomless pits of expectation from users, right?

• 1:02:05Ryan Peterman?

  Is there a top technical book recommendation you have for software engineers?

• 1:02:09Speaker 00

  I usually recommend the same, but the, the one book that was like the it book for me when I was younger. And it's called Algorithms Plus Data Structures Equals Programs by Niklaus Sevias, uh, the inventor of Pascal. And then later Modular and Oberon and whatever. And it's a, it's a book that is light on math and symbolism and rich in instructive examples and good explanations about how data structures work. I mean, that's how I learned about hash tables, right? I mean, like, when you're self-taught, you don't know about hash tables. You sort of know about linked lists, right?

• 1:02:49Speaker 00

  And fine, so in the original version of Turbo Pascal, all the symbol tables were just, well, they were just linked lists, you know? Or whatever. And then of course, as you had many local variables, well, you're a law, you're, you're, you're, you're going exponential in search time to, you know? And then I read about these hash tables and like, wow, what do you mean? I can like just do this and then like, it's, it's basically like linear lookup time? And implemented and the compilation twice as fast, right? Like, holy cow. You know, that was useful reading, do, do, do you know what I mean? So I was always like the engineer, it, it like that, that, I mean, and, and

• 1:03:30Speaker 00

  understanding how to do error recovery, he explains that and like how you construct a simple compiler and then like, you know, and it's, it's there's a, it was for me a great book. But, and now it's actually like, I mean, it's just a big PDF you can download it out there.

• 1:03:46Speaker 00

  It's out of print since 40, 30 years, uh, yeah.

• 1:03:50Ryan Peterman?

  Last question for you is with all the experience that you have now, if you go back to yourself when you just entered the industry and give yourself some advice, what would you say?

• 1:04:01Speaker 00

  Well, I, a couple of things maybe, like, we talked about being a team player, you know? I, I, I would have probably tried to educate myself a bit more about that to, to begin with.

• 1:04:12Speaker 00

  I think also one thing in, in retrospect is like, don't let people tell you that it can't be done. When they tell you it can't be done, it's because they can't do it. That doesn't mean that you couldn't possibly do it. Do, do, do you know what I mean? So, so don't let that discourage you.

• 1:04:31Ryan Peterman?

  Is there a project where you, someone said you couldn't do it and then you did it and that's how you?

• 1:04:38Speaker 00

  Well, I think the first thing I worked on like Turbo Pascal, people were telling me whenever we told them, here's what we have, they said, that can't be done. That's like, nah, you guys are full of shit. That's like not possible, you know? Well, it was. And I didn't know that it wasn't possible, right?

• 1:04:56Ryan Peterman?

  Awesome. Well, thank you for your time. I really appreciate it, Anders.

• 1:04:58Speaker 00

  You're welcome. This is a lot of fun.

• 1:05:00Ryan Peterman?

  Hey, thank you for watching this podcast. If you liked it and you want to see the show grow, please support with a comment or a like. Also, if you have any recommendations for people you want me to bring on, please drop a comment. Guests like Barbara Lizkoff, Mike Stonebreaker, Mark Brooker. These were all people that I brought on because someone left a comment. On another note, aside from the podcast, I'm working on building the ergonomic keyboard that I wish existed. Here's a glance at the prototype. It's a split keyboard, so there's two sides. Uh, this is in the case. But yeah, we launched on Kickstarter and we hit our goal within eight hours of launching. I really appreciate it if you were one of the people who grabbed one of the early units. Um, we're now working on the long journey of building the tooling now.

• 1:05:44Ryan Peterman?

  And so if you still want to pick one up, I've left the late pledges open on Kickstarter. So you can grab one there. I'll put a link in the description. Thank you again for watching the podcast and I'll see you in the next episode.