ANDERS: Sure. So, I’m Anders Hejlsberg. I’m a technical fellow in the Cloud and Enterprise part of Microsoft’s business. So, more specifically the developer division where I currently work on the TypeScript project that I’ve been involved with since its inception. And I’m also the Chief Architect of C# which I worked on almost ever since coming to Microsoft. I’ve been at Microsoft for about 20 years. And before that I was at a company called Borland. I wrote a product called Turbo Pascal and a product called Delphi. So, I’ve been doing development tools for a long time. [Chuckles]
CHUCK: Oh, nice.
CHUCK: I remember doing Pascal. I don’t know if it was Turbo Pascal or not, for one of my math classes in school a few years ago.
ANDERS: Yeah, yeah. Yeah, yeah. It starts to go back quite a long way.
ANDERS: At this point, yeah.
CHUCK: Yeah. And we’ve been trying to get you on the show for a while to talk about TypeScript. But I guess you’re a busy guy.
ANDERS: I suppose, yeah, yeah.
CHUCK: You must be important.
ANDERS: But no, nah, not really. But I’m…
ANDERS: I’m happy to do this, yeah. This will be fun.
CHUCK: Terrific. And I’ve talked to Jonathan Turner and a few other folks about TypeScript and I know… I’ve also talked quite a bit with the Angular core team about their involvement with adopting TypeScript and some of the things that they’ve been doing with it. I’m really curious if you could tell us where it came from. I don’t know if I’ve heard the background of the language so much as just why people like it. But yeah, where does it come from?
And so, there was the genesis of TypeScript. I’d say we started close to five years ago now internally. We went public about three and a half years ago now, in October of 2012. And it’s been great. It’s been a lot of fun. I really am still a very, very strong believer in not trying to create a different language but rather let’s just work with what’s there. Because that’s really what the community wants.
CHUCK: Yeah. And I think I remember at some point… I think it was at ng-conf last year. They had this slide that basically said you have ES 5 and then you’ve got this superset of it that’s ES 6. And then it was kind of a superset of that was TypeScript, which was really interesting.
ANDRES: Yes, yes.
CHUCK: So, ES 6 is valid TypeScript.
CHUCK: Yeah, exactly.
ANDERS: And there’s a gap in between those.
CHUCK: Yeah, what the browser will run and what you want to write.
CHUCK: Yeah, Rob Wormald yesterday when we talked to him actually said the ES 5 that comes out of TypeScript is probably better ES 5 than you would write.
CHUCK: And yeah, I thought that was fairly interesting.
ANDERS: Well, there are certain idioms, right? Like the way you do classes and so forth. We’ve gone through a lot of effort to find the best practices and encode them in our emitter. So, yeah.
ANDERS: That’s madness. And the larger your codebase gets, the slower you go. And these are the kinds of problems that compilers and language services are excellent at reasoning about. But they need help. They need you to say, “This name is different from that name.” And the way you say that is by adding types. And if you add types to everything, now it doesn’t mean that you have to explicitly add the types. In most cases we can infer the types. As long as you add a type up here, then we can flow the type through your expressions and through your statements and through your property accesses and then we can understand just from a single annotation what all of the types in a function are often. And then we can give you safe refactorings. And I do this daily. The TypeScript compiler is now close to a hundred thousand lines. The compiler and the language services that go along with plugging it into Visual Studio and all of the other editors, right? And with regularity. We refactor across the entire codebase. I need to rename this property here. Poof. It just did the 57 places it occurred even though it had a very common name. But all these other places were left alone.
CHUCK: So I guess I’m wondering. I can see what you’re saying but I don’t quite make the connection in the sense that if I have say 10 different classes that all have a name property on them and all those name properties are string, are you talking about the optional typing on the name property that are all strings or optional typing on the class and stuff.
ANDERS: No. No, the class. It’s actually there. You don’t even have to give it a type. The fact that you declared a name property inside this class and inside this other class, well we know that those are two different name properties. And if you say rename this one, then we can rename it in all the places where you are dotting off an instance of that class but not the other one.
CHUCK: Right. So, I annotate in my other functions and things that I’m expecting a person type.
ANDERS: Yes. Exactly, exactly.
CHUCK: And so, then it knows, “Okay, so since I know this is a person type and you’re refactoring on the person type the name property then I can [inaudible].” Okay, I just wanted to clarify that.
ANDERS: That’s one of the advantages. Another one of course is just the ability to easily navigate around in big codebases. Here’s a call to a function call foo. Oh, let me see what foo does. I want to just press F12 or whatever and jump there. Well that again, you need to know which foo. [Chuckles] if it has a common name, then there could be many and we can jump you to the right one. Statement completion. Knowing what properties could I write here. If I’m working with jQuery I don’t remember the entire API. Tell me. When I press dot just show me what could go here and I’ll pick the right one. Documentation. If you’re writing a framework say or a big codebase you probably want to document what you meant here so that when another developer comes in later they don’t have to start all over and actually deeply understand ever bit of the code before they can make even the minutest little change. So, there are many things that this helps with.
ANDERS: Yes, yes.
CHUCK: So, can you annotate in your function that it should be a person or some other type that has a name on it?
ANDERS: Yes, yes. In fact, not only that but the whole way the type system is built in TypeScript is that it’s a structural type system. And that means that it’s really a formalization of duck typing [chuckles] if you will. You can declare an interface or just yeah, an interface type and say it has a name and an age property. A name is of type string and age is of type number.
CHUCK: Oh, interesting.
ANDERS: Anything that has a property with name of type string and age of type number or something that derives from string or number is assignment compatible with that.
CHUCK: Oh, that’s interesting.
ANDERS: And you don’t have to do anything else. You don’t even have to give the type and name. You can just write the type annotation inline using curlies and then anything that has that. So, when you write an object literal it is automatically assignment compatible to anything that has the same set of properties.
CHUCK: I see. So, you can basically do a type annotation on the interface instead of the object.
ANDERS: Well, you can just do it straight on a variable. There’s no difference between… you can write the same interface 10 times, give it different names, if it’s structurally the same, they’re all the same.
ANDERS: Yes. So, the name doesn’t actually matter. It’s the structure that matters.
CHUCK: Yeah, it’s nice until your comments get out of sync.
CHUCK: Yeah, why not inform it, right?
ANDERS: Why not also get all of these other benefits that we can deliver through type annotations, right? So to me, that is just a slam dunk. I don’t see why you wouldn’t.
CHUCK: So, we get to the point where we’re like, “Okay, so we’re going to build TypeScript and it’s going to solve these problems. It’s going to make tooling easier.” How do you actually turn it into a language that people can use?
ANDERS: [Laughs] Well, I’ve been doing programming languages now for 35 years. So, I know a few things about what works and what doesn’t. But even so, the thing that intrigued me about this project is that it’s a very different way of thinking about type systems. Type systems traditionally have been for correctness of course. But it’s also very much been about gathering information that then you use when you emit the code. So, you need to know what the type of this variable is so you know what kind of machine instruction to use.
CHUCK: How much memory to allocate.
ANDERS: Exactly. All these things. But then what’s happened in the last decade or two is that compilers have actually changed fundamentally or the way we use compilers has changed. It’s been a very gradual shift. So, no one’s really noticed. But compilers have become these things that are actually behind our editors and guide our every interaction with our code and help us. They serve up helpful hints . The red squigglies. They do all these things for us, right? But below all of that is a compiler. But the compiler is very different. It’s not your traditional command line compiler where the code generates a backend. It’s a piece of machinery that has all of the same components but is built more like an API the can be plugged into an editor that can work highly incrementally.
And in the case of TypeScript that actually doesn’t guide the code generation because we generate source in a sense. Well, it guides it somewhat. But not really, right? And so, in a sense what we have here is a type system for tooling and productivity’s sake. And it turns out that there’s so much of the job that a compiler does is now that, that it’s actually valuable in and of itself now as a new thing. And that’s sort of what’s interesting about this opportunity, because it’s new. That hasn’t really been the case before.
CHUCK: Right, where it breaks it down into an abstract syntax tree and then…
And so, if you have a 200-file project and you’re just typing in one file that’s the only file that we build new ASTs for. Then we furthermore say, “Well, if we have the old AST around and we know where in the file you were editing then we can use piece of the old AST also. So really, all we’re changing is the little corner of the AST that you’re roaming in and then the spine going up, because we use an immutable data structure to stitch together a new tree from the old tree. And then we run the type check on that. But of course we can’t type check all of it. If you’re saying ‘da-da-da-da-da dot’ and now you need to know, what is the type of this thing? Well, then we just analyze just enough.
So, our compiler is what we call the pull mode compiler. Compilers traditionally start top-down and analyze everything and build a big symbol table and whatever. Our compiler’s totally different. You start inside out. You sort of helicopter into the middle of the piece of code and say, “I’d like to know what the type is right here.” And then we incrementally bind just enough to deliver the answer quickly.
CHUCK: That’s amazing.
ANDERS: And that is… no school teaches you how to write a compiler that way today. There are lots of schools that teach you about writing compilers but they don’t teach you about writing those kinds of compilers.
CHUCK: Well, it’s because those kinds of compilers are all about the resulting machine code or…
ANDERS: Well, they’re about a whole… it’s about the new way of using compilers that I talked about earlier. It’s compilers for tooling’s sake. Which is a different thing than compilers for code generator’s sake.
AJ: So, as I understand it, when you run the TypeScript compiler, that’s… at least the way I used it with the tooling setup I had in vim, it ran as a server, not as a one-time thing, because it had to keep all these caches and do all that.
ANDERS: Yes, yes.
AJ: Because if you try to run it just once, it’s really slow. So, you have to have that server so it can have those caches and doesn’t have to recheck everything every time.
ANDERS: Sure. A couple of times. First of all, if you run it once it’s not actually really slow. The original compiler that we had was about five times slower than the compiler that we have now. We actually did a complete rewrite of the codebase about two years ago. And then the codebase one now is very, very fast. Compiler compiles itself in two or three seconds. And that’s a hundred thousand lines of code.
CHUCK: I love that. The compiler compiles itself.
ANDERS: Well, of course. It’s all written in TypeScript, right? Yeah. So, that’s fast for a compiler. But you’re right that what we do is we package a version of the compiler as a Node module called ts.server which you can run as a separate process. And then you can talk JSON to it. And that’s what our VS Code plugin does, our Sublime Text plugin does, and literally the editor… you then write an editor plugin and all it’s saying is, “I’m in file this and that on line 214, column 17. The user just pressed dot. I’d like to know what to show him.” And then the oracle coughs up an answer and delivers it in JSON.
ANDERS: Do you know what I mean? And the oracle [chuckles] in this case the compiler, is actually keeping a mirror state of your entire project. It’s known from crawling up your directory tree, where’s the tsconfig. From that we can figure out and watch all of the files. Then we can load them up, build ASTs, and hold them in a separate process, and then just be told about the little changes you’re making and updating our image there. And then we’re able to cough up answers on millisecond scale, which is fascinating, really.
ANDERS: It’s so much fun to work on.
CHUCK: That’s just amazing.
ANDERS: And we know full well that we need to support that. And so, you can run the TypeScript compiler in watch mode where it basically sits and just watches file system change events. And whenever they occur, it recompiles just that file. It re-emits and whatever. And so, you can just have the same workflow that you’ve always had. Plus we’re also embeddable. So, tools like Webpack and use us at packaging time. Or loaders like SystemJS can use us as an in-browser transpiler at runtime, which is a dev setup that’s popular with Angular. So, you never compile. The compile happens as the file is downloaded to the browser. Of course, you wouldn’t do that in a production environment. But for development it’s actually super handy.
CHUCK: That’s just cool.
AJ: So, if I just want to stick with ES 5 but I want… are there any features of TypeScript I can use without having it be TypeScript? Is there anything I can use from the tooling of TypeScript without actually adding things that change the syntax?
ANDERS: You want the artifact to be ECMAScript is what you’re saying. But you want some of these benefits?
AJ: Yeah. Like I really don’t like… I don’t do Babel. I don’t like transpilers. I don’t like having my tool chain… I mean, it gets complicated.
ANDERS: No, I understand what you’re saying.
AJ: But I really love the idea of adding… do you call it strong typing? Firm typing? It’s not really typed but it’s typed enough to get you tooling benefits.
CHUCK: That’s amazing.
ANDERS: We can… so, we can keep going for a good long time before the types run out, so to speak. But at some point they run out. And if you’re unwilling to put type annotations then there’s not much more we can do. But one thing that we do, do now is we actually slurp up JSDoc type annotations also.
AJ: Ah. Okay, that’s something I’d be interested in.
ANDERS: Okay, great. Well, it’s in the shipping product right now. So, go check it out. I actually demoed it in my talk yesterday.
AJ: So, what is the tsconfig file?
AJ: So, is something like jQuery where it’s not written in TypeScript, is it basically, like you take as if it had JSDoc annotations and the export that out to a metafile or metadata?
ANDERS: So, that was what I was talking about, the declaration files that you can find on DefinitelyTyped.
ANDERS: So, there’s a file called jQuery.d.ts.
AJ: Okay, cool.
AJ: I like that. I’m glad to know that the JSDoc…
ANDERS: And then we actually also…
CHUCK: They love you too, AJ.
AJ: No, I mean because I really love the idea of it. I really want the tooling. I just don’t want…
ANDERS: No, I understand that point of view. I totally do. And we’re very much about allowing you to set the dial wherever you want to set the dial. And now we’re allowing you to go all the way to zero.
CHUCK: It’s TypeScript that has a whole bunch of anonymous types.
ANDERS: It’s TypeScript but, but, but, but… exactly, yeah, yeah. We have no problem handling that.
CHUCK: That is pretty darn amazing.
ANDERS: That’s fun stuff.
CHUCK: So, are there limitations to TypeScript as far as where you can use it or what you can do with it? Are there things that people do with it where they go, “Oh, when I try and transpile it, bad.”
ANDERS: You have to be in a scenario where it makes sense. I think if you’re going to write five lines of code, it probably isn’t worth the effort to get yourself set up with the tool chain and all that stuff. But the larger your project gets, the more valuable it is. And like I said earlier, by the time you get to a couple of thousand lines of code, it’s a slam dunk. It really is. And I think we have enough. Just look at our usage numbers and the testimonials we’re getting. And it’s pretty clear that we are really delivering some productivity value here. We’ve actually over the last year, our download numbers of npm have gone up about 20x. And we just went over a million downloads per month now in February.
ANDERS: Of course these are not individual users.
CHUCK: Oh, of course.
ANDERS: But it just means that we’re becoming a part of a lot of other tools that pre-provision us. Do you know what I mean? And that’s really a sign of your adoption by the community.
CHUCK: So, one other thing that I’ve seen with… I’ve been to a bunch of Angular conferences lately. I was at one in Amsterdam. I was at ng-conf. I think I was at another one last fall that I’m just not thinking of at the moment. But anyway, a lot of the examples are in TypeScript. And the way that those files are organized is very nice, is very clean. And one thing that I haven’t quite been able to determine is if that’s because they’re using TypeScript or if it’s because they designed it to look that way in TypeScript.
But then also, I think the fact that the extensions that we’ve added are very, very natural. Our type annotations look like they belong there, like they were always there. They flow totally naturally in the language. And our interface declarations look kind of like object literals. They say types instead of values and it feels natural. So, there’s a certain aesthetic to it that I think is there, too.
CHUCK: Yeah, it does sound like it’s a little bit of both. You did mention that anything that makes it into the standard at stage three, and talking to people here and talking to other people on TC-39, I hope people understand how that works and maybe we should show a little more depth. But if something gets to stage three and then they decide not to put it in the spec for whatever reason, do you pull it out of TypeScript?
ANDERS: It hasn’t happened yet, so…
ANDERS: At this point I think…
CHUCK: Because it seems like stage four is…
ANDERS: [async/await] is at that stage and I think decorators are at that stage. And they didn’t make it into ES 2016 but they’re looking like they’ll be in 2017. So, that’s fine. We have yet to be in a position where we have to pull something out. And we’ll see what happens there. We can always [park] something under a backwards-compatibility switch on the compiler. The thing about compilers is you can never take anything out. [Laughs]
ANDERS: You can park it.
CHUCK: That’s what I was wondering. So, what do you do?
ANDERS: But you can. You can and we continually see people try to do it in their languages. And then the community goes crazy.
CHUCK: Right. I was using that.
ANDERS: Because you’re just taking the cost and you’re putting it right back on the community. You don’t want… I don’t want my old code to be broken. I want my new code to be better. So, give me a switch that allows me to use the old stuff and then I’ll clean it up whenever I have time, or maybe I never will because that’s on the way out anyhow. But for the new stuff I want you to tell me “What’s the right way to do it?” So, you got to be sensitive to both sides.
CHUCK: Gotcha. Do you have anything else you want to ask about TypeScript?
AJ: No, I’m…
CHUCK: Because I’m really curious. You mentioned, and I’m going to change the topic is why I was giving you a chance AJ, but language design. What does it take to be a language designer? Because that just seems so…
CHUCK: It seems so fascinating to me. C# or TypeScript or some of these other languages. And you see people, they’re designing new functional languages. Or they’re designing new sort of object-oriented languages where they pick and choose features that they really like from other places and then you get something that actually kind of works. And so, I’m curious. As a language designer what skills do you have to have and what do you do to explore the areas you could go into and then make decisions that go into a language?
ANDERS: Yeah. It’s a tough one. A couple of things I would say that have worked for me. One is, try to keep it as simple as you can. Don’t go for all the bells and whistles. Because simplicity also means if it’s simple it’s easier to understand. And it will also tend to run faster [chuckles]. So, small is good.
CHUCK: Yeah, but some of those complicated feature are very powerful, too.
ANDERS: They are. So, you got to understand every good language feature typically has more than one use. Like take lambdas or take interfaces or whatever. It’s not like they’re a one-trick pony that you add into the language. Oh, let’s put XML literals in the middle of the language. That would be cool, wouldn’t it? Or something. And then you discover that… we had with C# big debates about whether we should support XML. Because there was a time when XML was like, my god, it was the best thing ever.
CHUCK: Yeah, and the last five years I’ve heard so many jokes about XML.
ANDERS: And if you didn’t say XML then you just weren’t with it, right? And so, of course there was a lot of pressure to… can’t we somehow put XML into C#? And then, oh my god, that’ll just be fantastic. And I actually sort of fought it, because I felt that these fads have a way of petering out. And if you hitch yourself to that wagon, you go down with it. And so, you got to be careful. Because you…
CHUCK: Well, and a language has a job to do. And those features feel like they’re…
ANDERS: No, but it’s like what we talked about, right? You can always put stuff in but you can never take it out.
CHUCK: Oh, gotcha. Yeah.
ANDERS: At least, well there’s one exception. Unless you have no adoption. [Laughs] But show me…
CHUCK: But then you have another problem.
ANDERS: Show me a beautiful language with no quirks in it and I’ll show you a programming language with no adoption.
CHUCK: [Laughs] That’s so fair.
ANDERS: It’s true.
ANDERS: Stuff accrues over time. And all you do is you just get more and more baggage. So, you got to be real picky about what you put in. and it’s okay to say no. but sometimes you got to say yes. [Chuckles] So, it’s hard. And some of it just comes down to developing a feel for it over time by doing it for a long time. I think like with anything, you got to be passionate about it. I’m very passionate about programming languages. I’ve been doing it for 35 years. And I got to a start in this business not because I wanted to make money. I was doing it because I couldn’t help myself. I couldn’t stop. And oh money, that was nice. I got to eat, too. But I still want to do this.
ANDERS: So, you got to be passionate. Because that’s how you get good at something. It’s by putting in the hours.
CHUCK: Yeah. I’m also curious. If you had unlimited budget and unlimited time, resources, what kind of a language would you design today?
CHUCK: Because there are so many interesting things going on. It’s like, how do you pick?
ANDERS: Yeah. It’s tough. I think the thing that’s interesting about programming languages is that they are all 90% the same. We all stand on the shoulders of giants. There’s so much good work that even if you invent a brand new programming language, 95% of it is going to be something. Everyone… you’re going to need a type system. You’re going to need a syntax. You’re going to need… like one of these concepts that we’re accustomed to like functions and whatever. But then there’s new stuff that’s sort of… but programming… like functional programming for example that we’ve all learned a lot from over the past decade or two. But even functional programming language, if you look how… the thing that’s interesting about programming language is how slowly they evolve. Look at Lisp. Lisp is the grandfather of all the functional programming languages. That language is 50 plus years old. It’s like, we were walking around in diapers when they invented Lisp. It’s not like the evolution of hardware where we’ve got new generations of everything and we’re talking about tens or six orders of magnitude improvement over decades. No. No. This is…
CHUCK: Well, the other thing is you mentioned Lisp. And we see things like Clojure and some of these others that are very similar to Lisp except they’ve added a couple of features that make them a little bit more modern, a little bit easier to use.
ANDERS: Oh, they’ve added type systems, yeah.
CHUCK: Right. So yeah, specifically with Clojure they’re added a type system that allows complex types and simple types. And yeah, you could see that as a major leap forward. But then they really haven’t changed Clojure a ton after that. And the next thing will be another deviation in one direction and then yeah, and that’ll be in another few years when somebody says, “I like Clojure but I need this other thing on it.”
ANDERS: Sure. But I think, like I said, there’s a lot of interesting stuff happening in functional programming that I think we’ve learned a lot from. And certainly, when you look at say the type system that’s in TypeScript it is actually more closely aligned with functional programming than with object-oriented programming. We support classes.
CHUCK: Oh, of course.
ANDERS: But we have a structural type system with generics and F-bounded polymorphism and all these fancy things. We have union types, intersection types, that work over generics. Type inference, very, very, very rich type inference. These are all things that come straight out of functional programming. So, like I said we’re all learning from each other.
CHUCK: Yeah. Now, AJ may be a little surprised to hear me ask this question because I really do like ES 6 and TypeScript. But the argument has been made that ES 6 is a deviation from ES 5 and not a superset of ES 5. That it’s a change and not an addition to.
ANDERS: Oh, it’s a change. A lot changed. A lot was overdue, right?
ANDERS: From ES 3 to ES 5, 10 years with a failed on in the middle. And then it was another six years from ES 5 to ES 6. And there were actually not a lot of new syntax in ES 5 other than strict mode which wasn’t really syntax. And so…
AJ: I don’t think there was any new syntax in ES 5.
ANDERS: Yeah, yeah, yeah.
AJ: I think the only thing that was done is that keywords that were never used were released so that they could be used. And then things were taken out of the language like ‘with’ and ‘eval’. And then other things [that] would generate silent errors or really weird behavior were correct. I think that if you did ‘new boolean false’ the value would be true.
ANDERS: Well of course, it would.
AJ: And there was something else. Like a couple of things like that, they were just way out in left field. They were errors. And ES 5 was really about removing garbage and not very… other than things like the arrays that were all polyfills.
ANDERS: Well, removing the garbage you can remove, yeah, without breaking everybody too badly. Yeah, yeah. Yeah, I think you’ll like the stuff that we’re doing with the non-nullable types. You should check out the presentation I did here and then some of that work.
AJ: I will.
ANDERS: It’s really cool, because it gets to the very core of some of all of these quirks about the differences between truthy and falsy checks and double equals and triple equals, and what does it mean for my types and how do we actually check that you wrote the right thing? We’re doing a lot of fun stuff here right now.
CHUCK: So, is ES 6 too much change?
ANDERS: By and large I think they did a fine job. The vast majority of things that got added I think have a place in the language. I think lambdas are great, destructuring is quite useful. Classes for sure. I do understand that… and modules, absolutely.
CHUCK: Yes, absolutely. And it gets it a lot closer to what I think a lot more people who use modern languages are accustomed to.
CHUCK: What are you doing and where does it hurt?
ANDERS: Exactly. And I think both actually fit in very nicely. So, I’m pretty [inaudible] on it.
CHUCK: Very nice. Well, I don’t know if I have any other questions or anything to add. How about you, AJ?
AJ: No. No, I’m satisfied.
CHUCK: Alright. So, I’ve been wrapping this up first by just throwing a thank you a Richard and Carl for inviting us here to be able to talk to the folks here at Microsoft and get to talk to you. One other thing that we do during our shows, of course we’ve done six or seven interviews now. So, we’re not doing it but we would like to ask you. At the end of our shows we do what we call picks. And basically what that is, is just whatever you’re into if it’s a TV show or a movie, music, or whether it’s coding tools or a programming language or anything like that. Just, what are you into these days? Are there one or two things that you just want to shout out about?
ANDERS: [Laughs] I don’t know. I just… you now the thing I’m into in a sense is getting back to my roots and writing code.
CHUCK: Ah, yeah.
ANDERS: The thing that often happens when you become an architect and you rise, it’s like it becomes very easy not to write code. And I was finding that I was writing less and less code and doing more and more high-level design work. And there was something I was missing. And I couldn’t quite figure it out. And then when I got involved with the TypeScript project I started writing a lot of code and I’m writing a lot of code in the compiler and I’m loving it to death. So for me, it’s like I just think it’s important to be true to your passions, because that’s what makes you happy. And that’s when you do your best work. So for me, that has been a thing I’m into, if you will. [Chuckles] It’s writing code again.
CHUCK: That’s actually really insightful. I think a lot of people, they get into code and they write code for a living and they really enjoy it and they just take for granted that they have the opportunity to do that. And for me with the podcasts and everything else, I spend a lot of time doing other things. And so, I definitely identify with that where I finally got to the point at one point where I was like, I don’t think I’ve written code for three or four weeks. And so, I sat down and I just cleared everything off and wrote some code and just built something and experimented with stuff. And it is, it’s a core thing to who I am.
ANDERS: It’s therapeutic. [Laughs]
CHUCK: Yeah. Yeah, it is. It’s relaxing and yet stimulating at the same time.
ANDERS: Yeah, yeah, yeah.
CHUCK: Well, thank you very much for talking to us.
ANDERS: Oh, my pleasure. This was fun, yeah.
CHUCK: Yeah. Well, we’ll have to see if we can get you on the Angular show because I know that they’d love to talk to you too.
ANDERS: Yeah. Yeah. That’d be fun.
[Hosting and bandwidth provided by the Blue Box Group. Check them out at BlueBox.net.]
[Bandwidth for this segment is provided by CacheFly, the world’s fastest CDN. Deliver your content fast with CacheFly. Visit CacheFly.com to learn more.]