Dates, RegEx, & Types

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

[00:00:03]
>> Douglas Crockford: We have a date function which was inspired by Java's Date class, which was not Y2K ready when it was introduced in 1995. I don't know if they didn't think the language was going to be around that long or if they didn't see it coming or what the deal was.

[00:00:18]
But we survived it. Hooray, and it's been fixed, so we got that. We got regular expressions which were borrowed from Perl 4. This is a regular expression literal that matches regular expression literals. That's what I claim, the thing that I hate about this convention is that if you have a regular expression that's longer than an inch or two, it's really hard to have any confidence that it contains what you think it contains, so that it matches or rejects what you think it will match and reject.

[00:00:52]
And I will confess I've written regular expression literals that are several feet long and I am not proud of that. But the language doesn't make it easy to do because they all have to be scrunched together. You can't even use whitespace in them to kind of separate the elements so you can see what it's doing.

[00:01:09]
And all smushed together, it's virtually impossible for human to decipher what that is. Fortunately, there is something on the web called Regulex. And you give a regular expression literal to Regulex and it will give you a railroad diagram of what that regular expression does. So you can see what it does and you can have a good understanding of how it will behave.

[00:01:30]
I will not write another regular expression without running it through Regulex. Highly, highly recommended. Yeah?
>> Speaker 2: Find yourself writing a regular expression that's too many inches long, can you just get a smaller string?
>> Douglas Crockford: Yeah, thank you for that.
>> Audience: [LAUGH]
>> Douglas Crockford: I had to, sorry.
>> Speaker 2: No you didn't have to.

[00:01:52]
>> Audience: [LAUGH]
>> Douglas Crockford: So you're probably wondering when do the good parts start. I haven't heard any good parts yet. Functions, functions are the good part and we'll talk about those in the next hour. So in JavaScript all values are objects except null and undefined. These are what are sometimes called bottom values.

[00:02:13]
And there's some debate as to whether a language should have any bottom values? There's no debate on the question, should a language have two bottom values? The answer is absolutely not, that doesn't make any sense. But we have two. And they act a lot alike but they don't act exactly alike, so they're not interchangeable.

[00:02:32]
But some people use them interchangeably which is a confusion, confusion causes bugs, I don't like that. So I recommend using only one of them and the one I choose to use is undefined because that's the one that the language itself uses, but both of them are used to represent values that are not objects.

[00:02:51]
These are the only values in the language that are not objects. So if you try to retrieve a value from one of these, you're not gonna get anything. If you try to execute them as functions, they'll throw exceptions. They're just used to indicate the absence or the end of something.

[00:03:09]
So I recommend using undefined. Choose undefined because it is the one that the language itself uses. So if I'm only gonna use one, let's use the language as one. So it's the default value for variables and parameters. So if you create a variable but you don't initialize it, it actually gets initialized for you with the undefined value.

[00:03:34]
And if you have a function and you don't pass enough arguments in, the missing parameters will get bound to undefined. It's a value of missing members of objects and arrays. So he tried to retrieve a property or an element and it isn't there. You don't get a runtime warning, you don't get a compile time warning.

[00:03:54]
Instead, you get the undefined value which is actually a very nice thing. Because it allows you to reflect on objects without any effort, you just asked, you got one of those and if you get a value back and you got something or if you didn't, then you didn't.

[00:04:08]
One thing to watch out for though is that you can store undefined into an object and then you can read that undefined back but you can't easily tell, I'm I getting an undefined that was stored in the object or I'm getting an undefined because it wasn't stored in the object?

[00:04:24]
They both look the same. That's a confusion, I don't like confusion. There's a type of operator in JavaScript which will return a string identifying what the type of something is. For example, if you pass it an object, it returns a string object which is great. You pass it a function, it returns the word function which is great.

[00:04:44]
If you pass it an array, it returns object which is not technically wrong because everything is an object but it's certainly not useful. You'd like it to return array because that's what it is. So, but if you pass it no, it returns object which is just wrong. There's no excuse for that.

[00:05:03]
It doesn't make it hard to detect if something is null because there's only one null value, so you can ask, are you triple equal to null? That's very effective. The problem is, you're trying to figure out, are you an object? Because if you're not an object there are certain things I don't want to try next.

[00:05:19]
And this test fails for that, which is really, really bad. So we have Array.isArray now, it was added to the language in ES5. While it's extremely ugly looking it does finally allow us to detect if some value is an array or not, which is good. And this is how it is implemented on older browsers.

[00:05:46]
JavaScript is a boolish language in that every value is truthy or falsy. The falsy values are false, null, undefined, the empty string, the number 0, and NaN. All other values are truthy. Including the string 0, the string false, all objects, all arrays even if they're empty, all those are truthy.

[00:06:09]
I think this was a huge mistake. The purpose of this was to allow if statements to work in a way that's similar to the way C works. C is not a strongly typed language. And so it uses 0 to represent the number 0, and false, and null and a few other things, end of strings, I'm sure there are lots of others.

[00:06:39]
So the condition of an if statement in C is 0 or not 0, and JavaScript wanted to look like that but it turns out to be a bad idea. We'll see some examples of that tomorrow.
>> Douglas Crockford: JavaScript is a loosely typed language in that any of these types can be stored in any variable or passed as a parameter to any function.

[00:07:03]
The language is not untyped because as we had seen we've got a lot of very specific types but it's loosely typed. And I contend this is a good part and although that statement is very controversial the prevailing style in the world is calling for strong typing and there are really good arguments for strong typing.

[00:07:24]
The argument is that strong typing allows the compiler to find errors very early. And the earlier we can find errors, the more valuable that is and that is true. And so when I first start working with JavaScript, I was very, very nervous because this is a loosely typed language, any kind of type can be passed in as any parameter or be stored in any property.

[00:07:45]
How could you have any confidence that anything's ever gonna work, cuz gotta be prepared for anything at any time was crazy. But what I found in working with the language was that to my surprise, my testing burden did not go up, all right? I thought I was gonna have to be watching for all of these things and putting in explicit type checks of my own, and I very rarely ever had to do that.

[00:08:12]
And in fact, what I found was that the sorts of bugs that a type checker can find, you find instantly anyway if you're doing even the most trivial level of testing, those things show up right away. That type systems provide no help in finding the bugs that keep you up at night.

[00:08:34]
And that you end up doing a lot less work because in a strongly typed language you end up spending a lot of time working against the type system. There are things you need to do in order to get your job done and the type system doesn't want you doing those things.

[00:08:49]
And so you have to figure out ways to get around it and that's a lot of effort. And any time you cast then that means the type system is failing you. And you end up casting way too much. Also it turns out there is a large class of errors which are caused by the type system.

[00:09:08]
Because the type system is causing you to circumvent it, you end up doing a lot of extra work and some of that work turns into bugs. And in JavaScript that tends not to happen. So I find in JavaScript writing correct programs is not harder than in Java, I think it's actually easier.

[00:09:26]
And you do a lot less work because you're not managing all the types all the time, that's my argument. You might not believe me, and it doesn't matter if you're writing in JavaScript get used to it because that's how it works. So in JavaScript, objects are are passed by reference not by value which means that objects are not copied.

[00:09:46]
In fact, there is no way, no easy way in JavaScript to make a copy of an object which seems like a surprising omission but in practice I've not found it to be a problem. The === operator compares object references so it'll give you true only if both operands are the same object.

[00:10:06]
There is no easy test for, are two objects very similar, containing the same properties, having the same values? That again, seems like a strange omission, but I've not found that to be a problem.