EPISODE 1722

[INTRODUCTION]

[0:00:00] ANNOUNCER: Douglas Crockford is an American computer programmer who was involved in the development of the JavaScript language. He specified the JSON data format and has developed various JavaScript-related tools such as the static code analyzer, JSLint. Crockford is also a game developer and has worked at Atari. Douglas joins the podcast to talk about his career and work in computer science.

This episode is hosted by Josh Goldberg, an independent full-time open-source developer. Josh works on projects in the TypeScript ecosystem, most notably, TypeScript ESLint, the tooling that enables ESLint and Prettier to run on TypeScript code. Josh is also the author of the O'Reilly Learning TypeScript book, a Microsoft MVP for developer technologies and a live code streamer on Twitch. Find Josh on BlueSky, Mastodon, Twitter, Twitch, YouTube, and .com as Joshua K. Goldberg. 

[INTERVIEW]

[0:01:09] JG: Douglas, welcome to SED. How are you?

[0:01:12] DC: I'm great. How are you?

[0:01:14] JG: I am so excited to talk to you. You've been a known name for good reason in the industry for quite a while. You have at least one book under your belt. You have at least one great data formatting format language. Can you tell us a little bit about how you got started in tech?

[0:01:30] DC: Yeah. I started programming in college, because that was my first opportunity. I was still in the mainframe era. I went to San Francisco State. I was majoring in radio and television, which was the most expensive major per student at the university. As a consequence of that, I couldn't get into the studios the first semester. I had to find something else to do. I took a math class that happened to be about Fortran programming. I was good at it, and so I took all the classes available at the college on programming. There were three of them and I took them all.  Computer science hadn't happened there yet. I got a job at the college, consulting about computing. Just kept doing that and turned into a career.

[0:02:20] JG: What was the first job that you had where you thought, "I am a full-time software programmer"?

[0:02:25] DC: It was my first job out of college. IT was working at Stanford Research Institute when I was programming.

[0:02:32] JG: Do you look back with fondness at the types of tools and programming languages, like Fortran that folks used back then?

[0:02:38] DC: Yes and no. I do have a sense of nostalgia for it, but it was really much harder back then. You only got access to the computer indirectly. You would create a deck of cards and you would submit that to a desk. Eventually, they'd get around to putting them in the card reader and running the program and then you'd get a printout back, and that would show you that you left out a comma, and then you'd find that card and you'd re-punch that card, re-submit. An hour later, you'd get the next prompt.

It took a long time to get something working. It gave you a certain set of skills that you'd really have to think about how you make the program work correctly, because you can't debug it into existence. You really want to get it as solid as you can, as quickly as you can.

[0:03:31] JG: It's the opposite of a lot of modern software trends, where folks will shove stuff into production as a beta, or as a tester release, and then six months later, they'll have some of the bugs fixed.

[0:03:43] DC: Yeah. It was also difficult in that there was very little memory in the machine. My first computer had 32K, which was considered pretty big at the time. Today, we would consider that extremely small. If your program didn't fit in that much memory, it just couldn't run. In addition to trying to make the thing work, you also had to work really hard to make it small, and those two things are often in conflict.

What I see weird about modern programming is people are still doing the things that we used to do to try to fit into a tiny memory. Even though memories today are vast, huge. We cannot comprehend. We cannot count as high as how many bytes there are in the machine. It's unimaginably big, but you still see people trying to shave the size of their variables and reuse variables through all sorts of really unsafe, unwise things. I think, because they were taught by people who were taught by - people who went to school when I did and have developed all these really bad instincts and were still doing it. That baffles me.

[0:04:56] JG: There is a certain joy, a happiness and feeling that you've conquered all the little bugs, you've made something optimal. That joy feeling doesn't necessarily correlate to you having actually produced something. Do you think that there's a je ne sais quoi of happiness in making the program as efficient as possible at a low level?

[0:05:14] DC: I don't know. The job is to make programs that do useful things and are free of error. If you're doing anything else, I think you're doing it wrong.

[0:05:22] JG: Excellent. Now, moving on through your career, these days, you're known for creating JSON and a series of very informative books. But you haven't always worked on web dev, or JavaScript tooling. You've been in the video game industry. Could you tell us a little bit about that?

[0:05:37] DC: Yeah. In 1979, no, 1980, I bought an Atari 800 personal computer. Atari was famous at that time for making video games, coin up video games. I bought the thing thinking that I would write a compiler, a programming language for it, but the CPU was too weak and memory was too small to pull that off, at least based on the knowledge that I had at the time. I looked at other things I could do. Finally, I decided, well, I'll write a game, because I know the machine can do that, because it was designed for games. The graphics chips in there were very powerful for their time. I wrote a game and I sold it to Atari.

As a consequence of that, I was invited to their research lab where I worked initially in a group that was doing research on video games. Then I moved into a group that was designing the next generation of computers for Atari. Those machines were going to do video games and a lot more. Unfortunately, Atari had shipped a really bad video game called ET, based on the great movie, but it was an awful game, and that basically killed the company. I left there and went to Lucasfilm, where they had a group that was making games. I worked on games there and game related technology for a long time.

[0:07:06] JG: Now, when we talk about little optimizations in computing, I think retro games from the 80s and that era are some of the best examples of cute little hacks, or tricks people had to take to make it fit on the system. Are there any particular you remember?

[0:07:19] DC: Yeah. Because we knew what the stuff should look like. We knew that our machines were several generations away from accomplishing that. The best we could do is cheat like mad to try to give the illusion that we were accomplishing things that we couldn't accomplish. There were all sorts of tricks that we would do to try to pull that off. The way we made games in those times are completely different than the way we make them now. Those games, generally, would be one person who would do the entire thing; the design and the implementation and the special effects and the sound effects and writing the manual, one person would do the whole thing.

Today, we've got teams that look like, some are bigger than movie production teams with lots and lots of departments and a lot of specializations. They're doing amazing looking stuff, but it was really, really different back when the machines weren't there yet.

[0:08:22] JG: I remember reading about the Pokemon games for the Game Boy, where they wanted to fit an entire world in what at the time was a pocket computer for the Game Boy. They would have pre-canned sprites, little layouts made for each map that would be reused between maps. Thus, you would be able to save a few bytes total off of your storage per area that you wanted to have on the map.

[0:08:44] DC: Yeah. In those days, we couldn't afford pixels. The best we could do is characters with dynamic character generators. You'd make your displays out of tiles and you'd try to be really clever in the way that you could reuse the tiles, because you didn't have enough to fill the whole screen.

[0:09:02] JG: There's a beauty to that.

[0:09:03] DC: Yeah. Although, the people who played the games didn't appreciate that at all.

[0:09:09] JG: Pity. Continuing through your career, after games, you founded a company named Electric Communities. According to Wikipedia, you were involved in the development of the programming language E. There's actually a little note there, citation needed. Do you think we could fill in that citation right now?

[0:09:24] DC: There were two versions of E. Well, so when we founded Electric Communities, our expectation was we were going to develop using a new experimental language called Jewel. Unfortunately, the company that was developing Jewel for us weren't able to deliver it. We had to find another way to do it. Java was really hot at the time. It just been released and it was the most successful introduction of a new programming language in history. I doubt that we'll ever see that again.

Doug Barnes who worked for us figured out a way to take some of the essential features of Jewel and put them into Java. That was the first version of E. Then Mark Miller figured out a way to make a more elegant language, which unfortunately, is still based in Java, but was much cleaner. That was at first, called New E, and then its name was changed to E.

[0:10:23] JG: What does the E stand for? Electric?

[0:10:26] DC: It doesn't stand for anything. I came up with the name. I noticed that the C language was really popular, and there didn't seem to be a D language, so I thought there was probably something wrong with that letter. So, we moved on to the next letter, E, which was also the first letter of the name of our company.

[0:10:43] JG: It's funny how naming in programming is an incredibly difficult challenge, but once in a while, it works out beautifully. What is your opinion on Java, the programming language, in comparison to, let's say, what you would prefer to write it, like an E, or a more modern language?

[0:10:59] DC: Java was certainly a huge improvement over C++. I don't understand why C++ still exists. There's no excuse for it anymore. But it's stuck in the classical object model. I think, classical objects were a mistake. The principal code reuse pattern is inheritance, which is problematic. It creates dependencies on code. If you change one class, there's a really good chance you're going to break another class, or a lot of other classes. It's a brittle model. JavaScript, I think, has a much better model, because it favors composition over inheritance, and I think composability is a much more powerful way to provide for code reuse.

The first time I saw JavaScript, I didn't appreciate that. I could only see it as an inadequate Java. That was a very popular perspective on the language at the time, but I think it was incorrect.

[0:12:02] JG: What made you change your mind, or see the light for JavaScript?

[0:12:05] DC: I was forced to use it. The first time I saw JavaScript, I thought it was the stupidest thing I'd ever seen, and dismissed it as most other people did. But then, an opportunity came to us. Turner Broadcasting wanted us to help them develop a children's tradable collectible game, and we had some technology in-house, which would allow us to do that. We'd been working in massively multiplayer game technology for a long time. It looked like something we could do.

The first thought was that we will build a Java client, an applet, which would talk to the kids, I guess. We had already done a couple versions of that in Java, and none of them were satisfactory, and I was not confident doing it a third time was going to be any better. I got this crazy idea. Maybe we could just do it in a non-modified browser with JavaScript. I picked up a copy of Dave Flanagan's book and skimmed it as quickly as I could and started writing, and made a demo where I had cartoon characters on the screen and you could drag them and drop them. We sent that to Atlanta and they looked at that and they said, "That's fine. That's the thing we're looking for." At the time, nobody knew that browsers could do that. Browsers were thought to be really, really inadequate platforms that were very restricted in what they could do. But if you understood JavaScript, you could make it do pretty much anything.

We were now in the JavaScript business. I went to my team and said, "Okay. This is how we're going to do it. Who wants to work on the JavaScript part?" Everybody took a step backwards. They were brilliant programmers, but they would rather be fired than have to write JavaScript. I had to write the JavaScript, or either that, or give the money back, and I didn't want to give the money back. I struggled with it. It was very hard, because I didn't really understand the language. But it was capable enough that we got the project on time under budget.

Then after I had some time and I could then finally read the standard, which is the real definitive guide, it's the thing that tells you how the language actually works. That edition, the third edition was horribly written. It was really, really hard to understand. But I made it through. One day, I was out bicycling and I had this realization that JavaScript had lambdas in it, which nobody ever told us that it had that, and it doesn't really say so in the standard, but you put it together and that completely changed my understanding of the language. That this is really a functional language with dynamic objects. We've never seen a language like this. It's brilliant that it's incredibly expressive and wonderful, and that changed my life. That epiphany put me down this road, which has served me really well.

[0:15:13] JG: Before we go down that road, I want to touch back a little bit on Java in contrast to JavaScript. A lot of developers for many, many decades have written a lot of classes extending other classes in Java, and that's given the language a bit of bad name for not actually adhering to solid principles. But in theory, you could write Java with no classes extending other classes, with just adhering two interfaces. What do you see as the fundamental shift from the Java paradigm to JavaScript that made you so much happier about the latter?

[0:15:44] DC: That JavaScript is functional, and Java even with interfaces is not. One of the innovations in old E, the original E that we did was it had closure in it, which is the essential thing you want in a functional language. We proved it was possible to add closure to Java. We tried to donate our innovations to Javasoft, so that they could put it into the language and they refused. Eventually, it got closures in, but it was really, really late and unnecessary. But that functional aspect of JavaScript, I think, is what makes it a superior language.

[0:16:25] JG: I apologize. Not everyone listening might have the same opinion on what is functional. What do you mean by functional in this context?

[0:16:32] DC: That's a good question. In fact, even within the functional programming community, there's arguments about what functional means. What I mean is looking at languages like Scheme. Scheme is a language where functions are first class, where you can take a function and you can store it in a variable, or pass it in a parameter, or return it from a function. Anything you can do with an integer, you can do with a function.

Also, functions close over the variables of the function that created it. If you have an inner function, the inner function gets access to the variables of the outer function, even after the outer function has returned, which is an amazing thing. A lot of expressive power comes from that. There's a guy named Peter Landen, who had been talking about this idea for years. He's one of these guys who was so smart that nobody could understand him.

It wasn't until Scheme was accidentally discovered that they found out what Landen meant, and that turns out that he was right. But that idea didn't get to the mainstream until JavaScript. Brendan Eich, the creator of JavaScript thought that stuff was interesting, and so he snuck it in the language without telling anybody. JavaScript was this amazing functional language, but nobody knew.

[0:17:59] JG: the functional aspects in JavaScript are a big part of what made it fantastic, which is a little interesting and humorous, because these days, basically, every mainstream language, even Java now has arrow functions, or lambdas, or some equivalent. How do you feel about the ideas of Scheme and E and JavaScript getting mainstream?

[0:18:17] DC: I think it's great. JavaScript is leading the field, that the reason all the other languages belatedly got lambdas in them was because JavaScript did it first. It was because of JavaScript's dominance that they had to do that in order to keep up. JavaScript was originally positioned as Java's stupid little brother. It turns out, that's not what JavaScript was at all. It was actually a much better language. The other languages are now copying JavaScript.

[0:18:53] JG: I should talk to you about JSON at some point, but I can't resist. I have to ask. What you see as the next big exciting parts of JavaScript that are coming from, or being given to other languages?

[0:19:04] DC: I don't know. I would rather that they stop. JavaScript is great just the way it is. My biggest problem with JavaScript isn't what it lacks. It's that it has too much crap. As a man with a standard, they cannot remove any of the crap. All they can do is add more crap. A lot of what gets added is ugly, or nasty, or unnecessary, and I don't think it's improving the language at all.

[0:19:33] JG: Would you be willing to give any specifics on features you don't think are worth their weight?

[0:19:37] DC: Yeah. In the ugly category, there is the ?. operator, which is just ugly. You see that in the program and it looks like, literally, it's the what the fuck operator, right?

[0:19:51] JG: The little Elvis.

[0:19:52] DC: Yeah. You got foo, then what the fuck, and then bar. What it does is great. It works the way the dot operator always should have. The original design of the JavaScript operator was broken. The new question mark dot operator works correctly. But the broken one is still in the language and is still got the nicer syntax. You should never use the dot anymore. You should always use ?., but it's just so hideous. Now, you're looking at your program and go, "Oh, what is this? It's just awful."

Did they improve the language? You could argue about it, but ultimately, no. I don't think they did enough. They can't fix what's broken, so all they can do is add more stuff. Some of the stuff, they shouldn't have done. You don't need classes in JavaScript, because if you use the functional patterns, they're so much more powerful, and so much more expressive. But it means you have to learn how to use that, and a lot of people really hate having to learn anything. They added classes to the language. Completely unnecessary. It locks people into the old paradigm, and so they cannot advance to the functional level. They'll always be writing bad stuff, because they'll never get to the good stuff.

[0:21:10] JG: It's interesting to see the divide, or the little fractures, or differences in the JavaScript community. There are a lot of projects that have either completely abandoned recommending classes, or having that as part of their API. For example, React moved from React create class to class components to function components, and now there are very few things in React that are ever touching classes. But then you have other parts, let's say, Angular, or decorator-based patterns on the server that are still largely class-based, a lot closer to what you might see in Java code. It's the strength of JavaScript. I would think that it's able to support all these different patterns. Do you think that there's a risk in trying to lock it down and make it less do whatever, do it all?

[0:21:48] DC: JavaScript has been called a multi-paradigm language. It can do classical, it can do prototypal, it can do functional. You can pick which one, or which hybrid, or whatever you want and do that. Some of them are definitely better than others. A lot of people like to argue that the one they like is better, even though they're wrong. We waste a lot of time arguing about who's wrong, particularly, the people who are wrong. The community reflects the language, in that the language is a mess, and so the community is a mess.

[0:22:25] DC: There's a great quote from Anders Hejlsberg, "Show me a perfect programming language and I'll show you a programming language with no users." I would think it inevitable that as a language becomes ubiquitous as JavaScript, it collects all the different opinions and paradigms that folks want to throw at it. Do you think there would have been a possibility to keep it a little more locked down at all?

[0:22:46] DC: Well, if they'd locked it down at ES3, it would have been horrible, because ES3 was an awful language. ES4 failed to launch. ES5 added some critical stuff and was the one version of the standard that removed some of the bad stuff. Unfortunately, it didn't remove enough of the bad stuff. That was the only opportunity we'll ever have to remove defects. From this point on, we can only add more problems. ES6 added some good stuff and some bad stuff, and it's been like that with every addition since then.

[0:23:25] JG: Transitioning over to JSON, halfway there, a lot of developers find it irritating that there is both null and also, undefined in the JavaScript language. Do you ever yearn for a world where we only had one null value type?

[0:23:40] DC: Yeah, absolutely. Null is the right name and undefined is the right value.

[0:23:45] JG: Yes.

[0:23:46] DC: There's no excuse for having both. It's not even clear that we needed - Well, okay. JavaScript uses undefined as the missing value. That's useful. If you have an array and it's not initialized and you pull something out, you get undefined. That's great. I don't have a problem with that at all. I think it's pretty good, actually. Sometimes you need a sentinel, something to say, no more values after this. Undefined is the right value for that. Null is just a waste of space. That was an accident. Null was added to the language at the beginning, because Brendan is a computer scientist and computer scientists loved null, so that got put in the language.

Undefined was an accident, but it happened. The correct thing to do in the language if we could fix the standard, would be rename undefined to be null and go on from there, but we cannot do that, so now we're stuck.

[0:24:49] JG: We're stuck with it.

[0:24:50] DC: Some languages can make breaking changes. Python did that from two to three. A lot of stuff broke, but okay, everybody went along. But because of JavaScript's unique relationship with the web, we can't change it. The number one rule of TC39 was, we will not break the web, and we will not break any existing program, even if it really deserves it. No breakage. That's why they can't fix any bugs.

[0:25:18] JG: It's a pity. The null undefined point is one that I personally am very deeply invested in. If we could, I would love to fix it. But we're just stuck with it.

[0:25:29] DC: Yeah. The ?. operator is very closely related to that, right? If you have undefined and you try to take a property of it, you should get undefined. You shouldn't get an exception. Because that allows you to use it at a long dot expression as a path. You don't want to have grenades in the middle of the path. You just want to know, if I give you this, do that, dot, dot, that. Is there a value at the end or not? That's all you care about. You don't want to know if something's missing in the middle. That's extraneous.

Even worse, having to get an exception, if there's something in the middle, which means that you have to put a test around every sub-expression before you get to the end, in order to keep it from exploding.

[0:26:14] JG: There's an argument to be made that if something is wrong, if let's say, an object doesn't have some nested property that one expects it to, the sooner you can throw an error or exception, the more informative it is for the developer. Would we not want that to be thrown on the property access that we thought existed, but doesn't? Rather than later on, when we try to use an undefined, or null value?

[0:26:36] DC: No. In JavaScript, we have the convention. If you have A.B and there is no B property, you get undefined. Now, you could argue, that should throw, but it doesn't. I think we're better off for it. But suppose you're trying to do A.B.C, and if A.B doesn't have a C, you get undefined. But if A doesn't have a B, it throws an exception. I think that's a problem, because it means, you have to then, before you do A.B.C, you have to ask, is A.B a problem? It makes your code bigger and uglier. I'm not in favor of things that make your code bigger and uglier.

[0:27:22] JG: Sure. I could talk to you for hours about the nuances of null safety and program flow, but we must continue through the journey of your career. How did you come to be the creator of JSON? How did that happen?

[0:27:35] DC: In 2001, I started another software company. Our goal was to make a system which allowed you to create multi-user, single-page applications that ran in a browser. The single page in a browser thing is pretty common now, but it was unheard of in 2001. The world hasn't caught up to the multi-user thing yet, so we were still ahead on that one. We needed a way of sending messages between the browser and the server. At the time, all the smart kids said, you have to use XML. We are very familiar with XML and thought it was abominable. It's just such a bad fit for that application.

I had an epiphany that we could use JavaScript object literals instead. We'll just pick a subset of JavaScript that is adequate for sending our messages and that's it. On the JavaScript side, JavaScript was happy to parse its own language, so it required no effort on the JavaScript side. The language is trivial to parse on the Java side. We found it was useful not just for communicating browser to server, but also, server to server and server to database. We anticipated other languages would want to talk to it and stuff, so it looked like a pretty useful thing. We showed it to our perspective customers, and one of the reactions we got was, "Oh, sorry. We can't use anything like that, because we just adopted XML. Oh, sorry."

Some of our other customers said, "That's not a standard, and we can only do standards." I said, it is a standard. It's a subset of ECMA. I forget what those number of JavaScript are. 262. They said, "That's not a standard." I declared it a standard. I bought json.org, and I put up a one-page website that said, this is what it is, and described the language in three ways. They are all very simple. A couple years later, it became a world standard.

[0:29:48] JG: Did the customers come back?

[0:29:51] DC: Well, the company didn't survive. We ran out of money in 2002. It was just after the dotcom bubble had popped. At that point, the VCs were very reluctant to fund anything. We'd have lots of meetings, but we couldn't get anything funded, so we shut down. I went and worked on the digital television broadcasting transition for a few years. Then in 2005, the Ajax revolution happened, where people figured out what we had figured out five years before. Suddenly, everybody was wanting to write single-page applications in JavaScript, and quickly learned that they didn't want to be using XML. JSON was the best alternative and it became a standard.

[0:30:43] JG: There is an absolute beauty in how minimal JSON is. Yeah, even unrelated to how well it drops with JavaScript. It's such a succinct format compared to XML. Really nicely done.

[0:30:53] DC: The XML community said, it cannot possibly work. They had lots of arguments for why it could not possibly work. I think it was due to XML is so complex. They convinced themselves that that complexity was a necessity, that it couldn't work, unless they had all of that fussy stuff in it, and had all of that over specification. JSON is very under-specification. It's just a grammar. JSON doesn't say what anything is. It doesn't say what a number is. It doesn't say how you represent a number in binary. It doesn't care. It just says, it's a sequence of digits that might have a decimal point in it. That's a number.

It turns out, that's enough. That many languages have different ideas about what number types they provide, and JavaScript only has binary floating point. Other languages have a lot more, including decimal floating point. Some languages only have integers. But they can all agree that we'll accept something that is a string of digits and we'll figure out how to make sense out of that, and that works. The JSON standard doesn't say how you do that. It's just obvious.

Now, every language has some sequence of characters. If you're in Fortran, it's a holler with constant. In most of our languages, we have double-quoted strings, but other languages have different kinds of strings. But we can all accept, if we see something that starts with a quote mark, the things between the quote marks are going to be characters, and it will figure out how to make sense out of that. The JSON standard doesn't have to address what is a character. It just works.

[0:32:36] JG: This is not the first time in this interview that you've alluded to removing all but the bearers of essentials. As you add more bloat, the tooling gets worse. Is that an intentional trend, do you think, in your career?

[0:32:48] DC: Simplicity is really hard to get. Simplicity isn't the thing you start out with. I think that's how most systems happen. You start out with a thing and then you keep adding and adding and adding and adding, and then it's really complicated. Simplicity is not stopping at the first step. Simplicity is achieved by going forward a few steps and then trying to reduce whatever monstrosity you've created and try to get it down to the smallest thing. It looks lazy, but it is not. Simplicity is a lot of work, but it has a lot of benefits.

[0:33:24] JG: Applying that to JSON, once in a while, there's a movement that stops in the JavaScript community of trying to add comments, or the next version of JSON, JSON 5. Folks want to be able to do unquoted string keys, or some such. Do you have any particular feelings on these attempted advancements of the language?

[0:33:42] DC: I think, they can do anything they want. I just recommend that whatever they do, they not call it JSON, for two reasons. One is, JSON should not be broken. We have lots of layers in the stack, and a lot of them are changing all the time, but not the JSON layer. The JSON layer is always going to work exactly the way it does today. It's nice to know that there's some piece of the stack that is not going to be the cause of bugs for you in the future. That JSON is always JSON. 

Don't do anything to try to destabilize it. Don't make something that is just like JSON, except for one or two tweaks, because that introduces a compatibility hazard that people might think that they're interchangeable and they're not, because they're different, and that's going to cause breakage. Don't do that. Make a new standard. Make it a lot better, but give it a different name. That's my advice. Besides, that JSON is a terrible name. The worst thing about JSON by far is the name. But JS stands for JavaScript. I don't know if you knew that.

[0:34:49] JG: Yes.

[0:34:51] DC: There's still a lot of bad feelings about JavaScript. We didn't call it that, because JavaScript was so hot and we wanted to get on the JavaScript bandwagon. JavaScript was the most hated language in the world when we put JSON out. It was hated by mostly, by the Java community, because they were embarrassed by it. It was also hated by the JavaScript community, because it was really hard to use and they didn't understand that it had functions in it yet. Having JavaScript in the name of the thing confused people about, "Oh, is this just a JavaScript thing? Now, I'm writing in Python. I guess, I can't use it." Having it tied so closely to one particular language was not good.

Then the O stands for object. That was confusing. It's object in the sense of what JavaScript calls an object, but the Java guy said, "Oh, that's not an object. We have a completely different understanding of what an object is, and that's not an object." That's not good. The N is for notation. That's okay. You can use that. But if you have an idea for a new standard, give it a better name. Show how smart you are. Come up with a better name, because JSON is not a good name. If all you can do is put a letter, or a digit at the end of it, that is not showing any creativity or brilliance at all. That's just embarrassing.

[0:36:13] JG: Do you have a suggestion for what that name might be?

[0:36:16] DC: Depends on the standard. When JSON started to ascend, the XML community really had its feelings hurt. One of them said to me, "Someday, there's going to be a standard that displaces JSON and then it'll be your turn to cry." But I'm not concerned about that. I never expected JSON to be the last data interchange format. There will be others. Just don't break this one on the way to the next one.

[0:36:46] JG: Let's talk about that next one a little bit, or more broadly, programming language trends. You keep up with a lot of interesting stuff in tech. Are there any particular trends in programming languages, or tooling in general that you're excited about for the future?

[0:36:59] DC: Yeah, the actor model. Carl Hewitt discovered the actor model at MIT in 1972. It is way overdue. The actor model is ideal for the way we do programming now. With Fortran, the computing model was you have one program running in one machine. You load the card deck and you press start, and it runs until it gets to the end, and then it halts. That's basically the way all of our languages still work. We don't halt now and we can have many programs running in the same machine, but it's difficult for them to cooperate with each other.

Mostly, we now have systems that are distributed over many machines. The network is the world now. That, what happens when machine is not very interesting. Right now, we are communicating with programs that are communicating with each other over the network, Everything works that way now, but our programming languages fundamentally do not understand that. They are still in the Fortran model. We've add extensions and hacks and tricks to try to get around that, and one of the consequences of that is that our systems aren't as reliable as they should be and they're not anywhere near as secure as they should be

I think we need a new programming paradigm that recognizes that the world is distributed now, and that doing distribution correctly requires a security model that is built into the fundamentals of the language, that is not a band-aid that's stuck on after we discover that, "Oh, no. We got hacked again." I think the after model is the way to do that. We've seen some stuff happening with it, but I don't think we've got it quite right yet, but I'm optimistic that that's the way forward.

[0:38:55] JG: How does the actor model help with security in distributed systems?

[0:38:59] DC: An actor is only allowed to communicate to another actor if it knows that actor's secret address. There are rules for how you can acquire an address. Without that acquisition, communication is impossible. The topologies that you build by actors sending each other messages with actor addresses embedded in them, naturally creates secure meshes that messages can flow through. You cannot get into that mesh without an invitation. The rules for how you get an invitation are very, very strict. It's built into the fundamentals of the model and nothing else does that.

We've tried to do security with passwords. That obviously doesn't work. We've tried to do security with access control lists. That obviously didn't work either. I think, after models, building on capabilities is the way to go.

[0:40:05] JG: Are there any programming languages currently available, or in development today you think do this well?

[0:40:10] DC: Not that I'm aware of. I'm not going to say there aren't, because I'm not paying any attention to what other people are doing anymore. I'm at a stage in my career where I'm just focusing on my own stuff. I'm no longer an authority on trends, or what other stuff are doing. The best thing I see going forward was something was discovered in '72. Maybe somebody's taken that ahead and I haven't noticed that. I would be very happy if that turns out to be true, but I would think I might have heard of it if someone had.

[0:40:47] JG: Sure. Before we embrace the Zen of not being an authority figure, or being asked for opinions on everything, I do have one last area of opinion to ask of you, and I apologize. Types and TypeScript. Do you have particular feelings, or thoughts on the matter?

[0:41:02] DC: It solves a problem that I don't have.

[0:41:05] JG: Can you elaborate?

[0:41:07] DC: Well, TypeScript was designed to help the C# community migrate to JavaScript, because .NET failed to conquer the world in the way that Microsoft anticipated. To put that in context, in 2001, I think, Forrester Research published a series of papers, saying that the web was dead, that it was going to be replaced by the X internet. That instead of delivering documents, we're going to be delivering applications, so we'd have this executable thing with the network, which wasn't a bad idea. In fact, it was a very good idea. They predicted that the web was going to disappear, those same way that ways and gopher and Archie and all those earlier protocols disappeared, and it didn't happen.

Before it didn't happen, Microsoft said, "Oh, that's great. Because we didn't want the web in the first place." You might remember, they were blindsided by the web, and almost lost control, but they managed to buy their way into the game, and then destroy Netscape. They own the web, but the web was never Microsoft's. When they saw the Forrester stuff, they disbanded the IE16, because we don't need that anymore. We're going to move on to .NET and build the X internet. They invested heavily into tools like C# and things like that. And Silverlight. I don't know if you remember Silverlight.

[0:42:41] JG: Yeah. Fondly-ish.

[0:42:43] DC: Yeah. All that stuff was going to take over the world, right? It didn't. The reason it didn't was because JavaScript was already in the browser. Because JavaScript was already in the browser, the browser was already an application delivery system. Just nobody had recognized it yet. When we started doing Ajax in 2005, suddenly, that took off and there was an explosion of web development. Instead of dying, the web came back to life and grew and grew and grew. There was no way that .NET could catch up.

Part of Microsoft's thing is managing the herd. They got the nerds in the herd, and Microsoft is trying to keep them in the corral and make them go where it benefits Microsoft. Since the herd was moving into JavaScript, they wanted a way to manage that. They wanted a dialect of JavaScript that looked more like C#. Basically, taking a subset of the C# type system, putting that on top of JavaScript gave comfort to the herd, which is fine. If it makes you more comfortable, then it's fine, but I don't need it, so I don't use it.

[0:43:59] JG: I was at Microsoft when they were really internally still transitioning from what was called script sharp, the transpiler that takes your C# code and turns it into JavaScript, to still adopt in TypeScript internally. Whatever the motivations of the Microsofties that be were a decade ago. What TypeScript has become now is the lingua franca of the web. It's on top of JavaScript. Most open-source projects that do JavaScript scale with some very notable exceptions. At the very least, published TypeScript types, if not already in TypeScript themselves. Surely, there's some argument to be made that the benefits of having a type system in the on TypeScript for developers for dev tooling are pretty severe at this point.

[0:44:41] DC: If you say so. I don't need it. That's my opinion. I'm not against anybody doing what they want to do. It's none of my business. But I don't need it.

[0:44:51] JG: You speak with a maturity that I wish many more in our industry, myself included would come to.

[0:44:57] DC: What can I say?

[0:44:59] JG: You just said that other people benefit from a thing and although you personally don't benefit from it, that doesn't detract from the thing itself. There's so many screaming matches in tech of folks who have their perspective on what's best and the way they do things and thus, everyone else should be the same way, but that is not what you just said. I really respect that. Thank you.

[0:45:19] DC: Thank you.

[0:45:21] JG: I want to close out the interview with something that's not at all software development, but is somewhat related. Could you tell us about lower mathematics, please?

[0:45:30] DC: Lower mathematics is everything that happens before higher mathematics. I figure, higher mathematics starts between trigonometry and calculus. You go all the way down to basic arithmetic, all of that is lower mathematics. Lower mathematics was developed over a span of thousands of years, going back to Egypt and Mesopotamia, in China, in India, Arabia, eventually gets to Europe. Along the way, discoveries are made, but the discoveries come slowly and awkwardly, and sometimes out of order.

A lot of those missteps and misunderstandings, which later get corrected, but they're still in the vocabulary of mathematics. For example, it's still controversial as to whether or not zero is included in the natural numbers. I don't know why that's a controversy. From my perspective as a computer science, obviously, zero is a natural number. But then you have to look out, why do we even call them natural numbers? What's so natural about them? Where the name comes from was a fear of negative numbers. Negative numbers, how can you have minus five apples? That doesn't make any sense. It's incomprehensible. It's unnatural. You can't talk about that kind of a number. You need to rewrite all of your expressions, so that those numbers never occur. You need to balance them out somehow, so that you never have to specify that.

Eventually, we became comfortable with the negative numbers, and so they're fine. But we still have this term of art for natural numbers, which doesn't make sense, but we still have it. We teach that to children. How appalling is that? All of the historical mistakes in mathematics are part of the curriculum. I want to redesign lower mathematics, starting from computer science, and going forward, which corrects the vocabulary and corrects the order of introduction and builds on the computer science foundation.

Chapter zero is about zero and one and the functions of zero and one. Then we use that to build up to a system of arithmetic for representing what become integers, and then we can get into rationals and keep going up and up and up, until we finally get to trigonometry, correcting some of the major problems with trigonometry, starting with the hypotenuse. Spell hypotenuse. Can you do that? I can't.

[0:48:21] JG: H-Y-P-O-T-E-N-U-S-E?

[0:48:27] DC: Yeah, so why should we ask kids to do that? When a teacher is framing a trig problem, usually the first step is okay, the long side is the hypotenuse. We should call it the long side, because we'll save a step, looking at trying to minimize the problem. By doing that, we can change trigonometry into something which is weird and scary and difficult to apply into something which is easy to remember and easy to apply. Just trying to simplify, minify, not dumb it down, but we retain the history which is useful, but we eliminate the artifacts that are just noisy.

[0:49:15] JG: There's a parallel there with how you described working on programming languages, or data to change formats, and now mathematics.

[0:49:22] DC: Yeah. I think by making the subject, not removing anything necessarily, but reorganizing it, reforming it, I think we can make it easier to learn, easier to remember. We have this problem, where there's a large part of the world now that is afraid of science. That's really worrisome. I would like to make science less scary, because science isn't a religion. Science is a process for discovering the truth. That should not be an intimidating thing. That should be something that we could all be a part of.

[0:50:07] JG: There's a unfortunate natural human reaction to feeling there are two areas to being othered from one to the other. We can see it, say, in the XML community, rejecting JSON is impossible. You can see it in people rejecting something they perceive as incomprehensible, or for the other group. It's really sad to see that type of mentality applied towards something like math, or science, something really fundamental and useful to know as a human.

[0:50:35] DC: Yeah. On that, I got death threats from the XML community early on.

[0:50:40] JG: Death threats?

[0:50:42] DC: Death threats, yeah. There is someone who wanted to winch me.

[0:50:46] JG: Okay. Over a format, okay.

[0:50:50] DC: Yeah, over a data format. We like to think that as programmers, because we're so - unlike other people that we don't share their biases, or absurdities. Unfortunately, we do. We're just like everybody else, which sounds like an insult. You're just like an ordinary person. We have to watch them in ourselves. Why am I so resistant to this new thing? Is it because it's new? In some cases, you have an economic consideration. I'm at a point in my career now where I'm earning well, because I'm the smartest guy of the shop on this language. If this other language comes in, I'm going to have to learn it and start over and I'm going to be at the same level as the new hires, and that's going to be embarrassing and maybe costly. We see a lot of resistance, even though we like to think of ourselves as being really innovative, we have the same reluctance to innovate as ordinary people.

[0:51:53] JG: I can't think of a better note to end this interview on. Douglas, thank you so much for talking with us. This has been an absolute pleasure. If people wanted to learn more about you, lower mathematics, any of your myriad of excellent books, in particular, JavaScript: The Good Parts, is there anywhere you'd direct those folks on the internet?

[0:52:09] DC: Oh, yeah. Go to crockford.com. It's all there.

[0:52:12] JG: Excellent. Well, for Software Engineering Daily, this has been Douglas Crockford and Josh Goldberg. Thanks all. Cheers.

[END]