Implicit Coercion

[00:00:00]
>> Kyle Simpson: There is a temptation to believe, and it's sort of a cult feeling among the community, most developers tend to think that implicit mechanisms are magical. That when something happens underneath the scenes, and it wasn't obvious, then it's some sort of magic. And we tend to equate magic with bad, evil, like this is not good because I can't understand what's happening.

[00:00:26]
And this is a predominant reason why that anti-coercion prospective exists is because people feel like the implicitness of coercion is the downfall where they point to explicitness of type casting in something like Java or C++. And then they say, you would never automatically convert an integer into a float or whatever.

[00:00:49]
But JavaScript does all this sort of automatic stuff and then they say, well, that's a weakness of JavaScript because it's magical and bad. I don't think it's either of those things, I think that we should think about implicitness as abstraction. Not all abstractions are good, but some abstractions are necessary.

[00:01:08]
Implicitness, and we're not dealing with functional programming here. This is not this course, that's a different course. Here's a plug, you can check on my functional programming course. But within functional programming, you use abstraction all over the place. And it turns out that the declarative style of coding is actually more implicit.

[00:01:29]
So implicitness is not bad, it is the proper usage of obstruction. In other words, we want to hide key unnecessary details, why? Because that re-focuses the reader on the important stuff. We're not distracting them with the stuff that they don't need. We wanna focus them. We wanna increase the clarity of the code by re-focusing.

[00:01:52]
So some of the implicit nature of JavaScript's type system is sketchy, but some of it is quite useful. For example, the boxing. That's implicit, but also very useful, because the distraction of having to cast it into an object isn't, what I would argue in most cases, an unnecessary detail that the reader doesn't need.

[00:02:13]
And that's actually at the DNA of JavaScript. Part of the reason JavaScript has such a low barrier to entry is because it doesn't force the reader to deal with a bunch of unnecessary detail. It betrays JavaScript's DNA to suggest that all those implicit things are things that we should avoid.

[00:02:31]
>> Kyle Simpson: So here, if I'm writing string to make it super obvious that I'm gonna make this thing into a string, I don't know, I think that's distracting. I think I would just drop in the number and be perfectly happy, because I know that number is never in any of those corner cases where something could be weird.

[00:02:50]
Maybe I've already checked to make sure that num students is not nan, for example. All the other numbers that it could possibly be other than negative zero and nan, those are my only corner cases that I need to worry about here. So if I have if statements that deal with those corner cases, then this line of code, line 4, is actually better communication, cuz it properly lets JavaScript abstract the detail that's not necessary to deal with at that moment.

[00:03:17]
Here's another example, the less than operator, we talked about how it coerces things into numbers. Sometimes you wanna go ahead and make sure that both of them are a number so that you don't get something weird. For example, if both of them are strings, it doesn't turn them both into numbers.

[00:03:34]
The less than operator does an alphanumeric comparison. So there's a corner case, if you could possibly have a less than applied to two strings, you probably do wanna make sure that they're both numbers first. But if I'm in a place of the code where I know at least one of them is definitely a number?

[00:03:52]
Well then, I know the other one's gonna become a number, so maybe it's not necessary to force you to read the fact that I'm making them both numbers. Maybe it's okay, to let that less than operator do the coercion form. These are not hard and fast rules, these are trying to train you to think like this to analyze.

[00:04:10]
And if you are in a place where you have the choice to use coercion but it's not obvious, it's within your purview to make it obvious. Make it obvious that they're both numbers and therefore, I don't need to worry about explicitly casting them. It's just already obvious that they're both numbers.

[00:04:27]
If you communicate that intent, it's not gonna trip up other readers of the code.
>> Kyle Simpson: Really, the question is, is showing these extra details helpful to the reader or not? Sometimes yes, sometimes no.
>> Kyle Simpson: Basically, I'm asking you to be critical, analytical thinkers, to be an engineer and not a code monkey, okay?