Evolution of Inheritance

[00:00:00]
>> [MUSIC]

[00:00:03]
>> Douglas: I think of programming languages as being in two very distinct classes, systems languages and application languages. A systems language is a language that you would use for writing system stuff. Something that needs to be close to the metal like a kernel, a device driver, a memory manager.

[00:00:22]
That kind of low level stuff and nothing else. Everything else should be written in application languages. Now we need a new system language, our dominant system language is still C which comes from the late 60s. That was a long, long time ago, we seem to have lost the ability to innovate in system languages and it's not like we don't need them anymore.

[00:00:45]
I think we need a better version of C, but it's a long time coming. But I'm more concerned with the application languages, because that's where we all live and we need better application languages. I think a mistake that you can see in lots of languages is that they're confused about which side of this line that they're on.

[00:01:04]
For example, for my money the biggest design error in Java was it couldn't decide if it wanted to be a system language or an application language. And one of the signs of that is that it requires the use of threads at the application level. Which I think was a tragic mistake due from that confusion.

[00:01:23]
So you can take the application languages and divide them into two classes. There's the classical school and the prototypal school. And for a long time I've been an advocate of the prototypal school because of the obvious problems that are in the classical school. That you've got the classification taxonomy problem that we talked about earlier.

[00:01:44]
Back when the goto argument was going on, maybe at its loudest, someone published an article saying we should also eliminate the come-from statement. And it was a joke of it and there were people who attempted to design programming languages based on the come-from statement. But it turns out we have come-from statements in our classical languages except we call it extends.

[00:02:08]
And what it does has cause coupling of things and coupling can be a problem. When you couple things together, then one becomes dependent on the other you cannot change them independently anymore. And that causes systems to become brittle and that happens in class systems. And so the big advantage in prototypal systems is we eliminate that coupling.

[00:02:31]
Or we at least reduce it significantly, such that that no longer becomes a problem or a barrier to progress. So, as a big advocate of prototype inheritance. Since then I've changed my mind, that the biggest benefit you get from prototypes is memory conservation. And I think that might have been important, probably was important.

[00:02:56]
Well, maybe it wasn't important in 1995. It's not so important now, that we've had memory has become so abundant. You now have gigabytes of RAM in your pocket and when you just can't imagine that much memory. You really don't understand numbers that big, but we still think about memory as though it's doled out in k.

[00:03:21]
So may have made sense then, not so much now. It also is a source of confusion that we have owned properties and inherited properties which for some purposes act the same, but for some purposes don't. I'm looking to get rid of all sources of confusion as you know because confusion causes bugs and exploits.

[00:03:41]
It also provides retroactive heredity that you can change what an object inherits after it's constructed. I've not found any good uses for this, but I can imagine a lot of really bad uses for it and it's something that is provided by this architecture. One bad thing about it is performance inhibiting.

[00:04:02]
So JavaScript engines go fast by making assumptions about the shape of objects. And they have to be pessimistic when it comes to prototype chains. Because a prototype chain can change its contents at any time and they need to be prepared for that and that slows things down. So, I used to be in favor of prototypal inheritance, I'm now in favor of class free object-oriented programming.

[00:04:30]
I think class free object-oriented programming is JavaScript's gift to humanity. I think that's why this is an important language. It's why I hope it becomes an influential language. So let's review this again. So this is block scope. And we've got functions which have the same scope relationship and we've got our closure again.

[00:04:52]
And we've got this really important form where we have a function that returns a function. And this is I think the best most important discovery in the history of programming and we have it in this silly little language.
>> Douglas: So to review one last time, this is the model that I recommend for doing object-oriented for doing class free object-oriented programming using functions in JavaScript.

[00:05:25]
We've got a constructor which takes a specification object. We make our instance variables which we can initialize from the specification object. We get other methods or other functions that we can use that we can get from other constructors and we can call as many of these as we like.

[00:05:48]
We then create our methods which will close over all of the members, all of the other methods, all of our methods and the specification object. And any of these which need to be public, we will put in the outgoing object which we then freeze. By doing this, we get an object which has a hard interface, an uncorruptable will interface.

[00:06:13]
It will always work exactly the way it should, it cannot be confused. And it also corrects, I think a problem that we've always had in objects in that some things you want to access through a method. And some simply by poking at the properties. Except if you allow people to poke at the properties, then there is no defense against inconsistency.

[00:06:37]
Everything, all changes at least to the object should go through the interfaces.