Transcript from the "Dates, RegEx, & Types" Lesson
>> 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.
>> Audience: [LAUGH]
[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: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: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: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: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: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.