Check out a free preview of the full The Good Parts of JavaScript and the Web course

The "The Next Language" Lesson is part of the full, The Good Parts of JavaScript and the Web course featured in this preview video. Here's what you'd learn in this lesson:

Doug hypothesizes about the next programming language that will replace JavaScript. While he doesn’t talk about specifics, he shares some of lessons he’s learned studying various programming languages.


Transcript from the "The Next Language" Lesson

>> [MUSIC]

>> Douglas Crockford: So, I've been thinking a lot about the next language. What's the language that replaces JavaScript and I really hope there is a next language. Because if JavaScript is the last programming language, that would be really sad. Wouldn't it? I mean, for our kids, right,we need to leave them a better language.

We can't allow JavaScript to be the last language. So something is going to have to have to succeed it and I've been searching for the next language, and what are the signs? How will we know when it's here? And it's sort of like waiting the Messiah, how do you know?

And I don't know, but I'm looking for and then I'm starting to try to understand what it's going to be. I'm confident, it's not here yet. Actually, I don't know that. It might be it's here, but I just haven't recognized it yet, but there are people who tell me, it C#.

No, no, no. Or it's Java, it's been here the whole time, no, no. The next language is another language and it's the thing, which is the right thing to replace JavaScript and we haven't seen it yet. But I think a lot about what it's going to be and what it's going to do.

I am confident that when it arrives, we will reject it out of hand, as we always do, because programmers are as emotional and irrational as normal people. We think that we're not and maybe our spouses tell us we're not, but it's true. We are and most of what we think about what we do is based on emotion, and not on reason, even though we imagine it's the other way around.

So this sounds like a wild charge to make of my own profession, but I have some good reasons for saying this and I think the historical record backs me up on this. For example, it took a generation to agree that high-level languages were a good idea. Back in the early days when everything was in assembly language and the first high-level languages were being developed, Fortran, COBOL and so on.

Who would have most benefited from use of those languages? The programmers. Who was it who was opposed to those languages? It was the programmers. They were complaining that the languages were taking control away from them. That they didn't give them the performance that they needed. They had all these reasons for why they wanted to stay down in the muck, that they didn't want to be elevated in these more expressive, productive languages.

It took a generation to agree that goto was a bad idea. Publishes his letter in 67 and that starts an argument, that literally goes on for 20 years and the arguments were all silly arguments. Now, we need the performance of the goto. It's how I express myself. I can't be me, if I can't use goto.

We have a goto tradition, my grandfather used goto. You can't take my cold dead hand, all of those arguments were all made about goto. It took a generation to agree that objects were a good idea. So objects are first discovered in Simula in Norway in 1967-
>> Speaker 2: Under the ice.

>> Douglas Crockford: I'm sorry.
>> Speaker 2: Under the ice. You said, they were discovered.
>> Douglas Crockford: Well, in Norway.
>> Speaker 2: Under the ice.
>> Douglas Crockford: No, in Oslo. And as always happens with the really important innovations, the world took no notice at all, except for one guy, a graduate student at the University of Utah, Alan Kay.

Who then takes this idea to Xerox PARC in California, thinking that this idea of objects is so incredibly powerful that he can use it as a programming language for children. That children can use to program their personal portable devices. There was a lot of his vision, which was right.

A lot of his vision we haven't caught up to yet, we still don't have the language for children. I don't think we have a language for adults yet, but we're still working on it, but they then spent a decade developing that language and did a brilliant, brilliant job on it.

And so in the late 80s, the industry had a choice. We're gonna go into object oriented programming. It took a long time to get there, but we're gonna do it. Are we gonna go with Smalltalk-80, one of the best designed programming languages in history, or are we gonna go with C++?

And the decision was made by people who fundamentally did not understand object-oriented programming and they chose C++. Because in order to use that language, you did not need to understand anything about object oriented programming. That language got some things fundamentally wrong about object systems. Unfortunately, the language has been extremely influential and has set the mold for virtually everything that's happened ever since.

I don't know if are ever going to catch up to Smalltalk, then it took two generations to agree that lambdas were a good idea. So, Alan Kay who is a Smalltalk guy, he started by writing a little program in NOVA basic on a Data General Mini Computer, which demonstrated his weird little language, and he started touring with this idea.

Taking it to labs and universities, and he visited MIT. Very smart guys at MIT and he's telling them about his new language, but it's still early in object going to programming and he doesn't have the vocabulary that we have now to describe what's going on. So he couldn't say you invoke a method on an object, cuz nobody knew to say that yet.

So he described it, as you send a message to an object. Well, the guys at MIT listening to him say, well, you're not actually sending a message, you're making a sub routine indication within direction. But what if you did send a message? And that started research in the actor model and the actor model, you actually have these entities that are running in separate systems that can send messages to each other.

That's basically what actors are and the guy who came up with this, Carl Hewitt, is one of these guys who's so amazingly smart. It's like he was born on the other side of the paradigm shift. When he talks about stuff, people cannot understand what he's saying. He's very clear, he's very eloquent, he speaks really well, but he's talking from a frame of reference, which is so foreign to the rest of humanity that nobody understands him.

Including the other people at MIT, they were all very smart and they all had a lot of respect for Carl, but they couldn't figure out what he was raving about with all these actors. So a couple of them, Sussman and Steele, decide we need to build something in order to understand what it is that Carl's talking about.

So they start by taking LISP and rewriting it into a language which models the actor model, and they didn't fully implement the actor model. So they never did figure it out, but the language that they created was called Scheme and they had accidentally discovered functions with lexical closure and all the stuff that we've been working on today.

So, the fact that you could have higher order functions, functions that return functions and all that stuff happened happened by accident, trying to figure out what Carl Hewitt was talking about. And that is maybe the most important discovery in the history of programming. And as always happens, the world took no notice of it at all and it just sat around at MIT for years and years going nowhere and is only now, finally after 40 years, finally coming to the mainstream.

And it's coming to the mainstream, because it was actually a really good idea and its time has come. We really need it now. So the reason these things take so long, everything takes at least a generation, is because we don't change minds. We have to wait for a generation to retire or die before we can get critical mass on the next new idea and that's the way progress goes.

We imagine this is an extremely innovative industry, and in some ways it is, but in some ways, we're just like everybody else. So, I lived through the goto thing. I remember when that was happening and all the arguments, and they were really emotional angry arguments, and all the arguments were from emotion.

There was very little argument from fact and it just went on, and on, and on, and on, and then it got quiet. It was like, are they gone? Can we get rid of the goto now? And we did, we got rid of it and it's gone. And we're not missing it and all of the promises that the world was going to end, if we took rid of goto or the lives of programmers are gonna be made more miserable.

None of that turned out to be true, we're not missing it. We're doing great without it. In fact, some of our languages have maybe a little bit too much goto left in them, but we're getting by. So, it turns out we never needed goto. Don't need it. We're doing better without it.

And in fact, what actually happened was by getting rid of goto, it made it easier to write programs of greater complexity. Because if your only control construct is goto and conditional goto, there's a limit to how complex a program can get before it comes unmanageable. And by getting rid of goto, we could do better with larger programs and we could do better at achieving our ambitions in terms of writing software.

So, the people who are arguing against goto were the people who would have benefited from goto. They're benefited from getting rid of goto and it is always like that, and I expect it will always be like that. So in looking for the next language, I'm looking for it to be different in some important ways and I'm expecting it to be crucified for those differences.

Learn Straight from the Experts Who Shape the Modern Web

  • In-depth Courses
  • Industry Leading Experts
  • Learning Paths
  • Live Interactive Workshops
Get Unlimited Access Now