Check out a free preview of the full Deep JavaScript Foundations course:
The "Implicit Coercion: Strings & Numbers" Lesson is part of the full, Deep JavaScript Foundations course featured in this preview video. Here's what you'd learn in this lesson:

Kyle defines implicit coercion as a side-effect of some other operation or as something that is not clear when looking at the code that coercion will occur. Kyle introduces implicit coercion with a few examples using String and Number values.

Get Unlimited Access Now

Transcript from the "Implicit Coercion: Strings & Numbers" Lesson

[00:00:00]
>> Kyle Simpson: Okay, so explicit coercion happens obviously. Implicit coercion then is something that happens as a side effect of some other operation. Kind of the opposite of explicit, right? Now, as I said earlier, the temptation is to think that anything that's happening as a side effect automatically should be labeled as something that's like lesser desired, maybe it's a bug, maybe it's a poorly designed system, you shouldn't pick it.

[00:00:28] That is too myopic of a view, because there's a whole bunch of stuff that we do in programming that's implicit. It is not the case that all implicitness is bad. As a matter of fact, when we talk about choosing declarative coding style versus imperative coding style, you might not have ever stopped to think about this but declarative coding style is actually a coding style that exalts implicitness.

[00:00:53] When you do something declarative, you're saying, I don't care how it works, make it happen underneath the covers. You're telling the engine do that work for me, I'm not gonna be explicit about it. I'm just telling you the end result is that I want this. You go figure it out.

[00:01:10] So actually, implicitness is not a thing to be feared or to be avoided, but something to be embraced. But it has to be used responsibly. How many of you have ever heard this quote before, from Arthur C Clarke, any sufficiently advanced technology is indistinguishable from magic? Arthur C Clarke, famous science fiction author.

[00:01:30] This was the third of Clarke's three laws. Any sufficiently advanced technology is indistinguishable from magic. Often quoted, often misrepresented for what he actually meant. But, in that grand tradition of misrepresenting things, I'm gonna paraphrase or tweak this a little bit to make it apply more to what we're talking about.

[00:01:53] Cuz I think many developers, especially on a topic like coercion, would think to themselves, any sufficiently complex technology, or rather any sufficiently confusing technology, is indistinguishable from magic. Is that not true? Isn't that true that if something is confusing, if you don't understand it, it's no different than a black box of magic, right?

[00:02:16] I don't know how it works but it sure seems to do the job.
>> Kyle Simpson: Let me paraphrase it this way. Any sufficiently unlearned technology is indistinguishable from magic. Can coercion be learned? Absolutely. I'm living proof. You can learn it. Anybody can learn how coercion works, and if you can learn how coercion works then you can learn what works and what doesn't.

[00:02:43] So set aside some of those presuppositions that you may have that implicit mechanisms are evil. Let's try to learn how implicit coercion actually works, and maybe discover some places where it's helpful. Here are some examples of going from string to number and number to string, but now I'm doing it implicitly as opposed to explicitly.

[00:03:04] I start out with the string "123" on line 1, and on line 2, I do something rather strange, I subtract 0 from it. And I end up with the number, 123, in line 3. What's going on there? The minus operator is specifically designed to only do math. We talked about this before.

[00:03:22] If you give it something that's not already a number, what's it gonna do? It's gonna call the two-number abstract operation and produce the number equivalent. So that string, 123, as a side-effect of line 2, is gonna get coerced to a number. And then we subtract 0 from it, which is basically a no op.

[00:03:38] So we have the side effect result of producing the numeric coercion from "123" to number 123. Now, there's a pretty good chance, cuz I already see it in some of your faces and I'll bet those of you listening online would agree, there's a pretty good chance that you're like, ugh, we'll never do it that right, right?

[00:03:57] Sure it works but I feel as yucky, right? That's a technical term by the way, yucky. That's not good. I want you to hold on to that feeling, we're gonna come back to that in just a couple minutes, right? Just hold on to that. So -0, similarly, if we did divide by 1 or multiply by 1, same end result.

[00:04:19] If we do a mathematic operation, then it would be a no-op. The side effect is that a coercion is going to occur. Even subtracting string 0 is interesting. Because as strange as line 5 looks, the same end result happens because both of them get coerced to numbers. As a matter of fact, subtracting empty string would also work because the empty string would become 0.

[00:04:40] [NOISE] Right? So all of those are examples of implicitly doing it with math. Let's go the other direction. Start out with the number 456. We wanna produce the string equivalent. We take the plus operator and we can cut or we add the empty string. How many of you have done code like line 12 before, at least seen it in code bases before, okay?

[00:05:03] It's in virtually every code base ever written. Now what is that code doing? Well, there's two things at play. First, the plus operator is overloaded. I already exposed earlier that I think overloaded mechanisms are generally not a great design idea, overloaded operators is a perfect example. I'm not a fan.

[00:05:25] This is an overloaded operator, some people love that idea. This operator says, if either one of my operands is already a string, prefer string concatenation. Otherwise, do numeric addition. So if one or both of them are already a string, prefer concatenation. If they're not strings, assume we're doing numeric addition.

[00:05:51] Since we are ensuring that one of them is a string, we are going to create the side effect that the other one will get coerced to a string. So baz is gonna get coerced to a string. So if you're doing the math here, quote, unquote, there's actually two implicit systems involved in that statement.

[00:06:07] First, the operator overloading, secondly, the implicit coercion that occurs as we concatenate.
>> Kyle Simpson: Doubly implicit, okay? Now, there's a really good chance that right now line 12 feels totally natural to you. Very enigmatic tool. Many of you have probably already done it. And you would defend the usage of that mechanism.

[00:06:31] As a matter of fact, none other than the creator of the language himself, Brendan Eich, has gone on record as saying, if you wanna coerce something to a string, the right way to do it, the right way. He literally said, the right way to do it is to add the empty string to it, concatenate the empty string to it.

[00:06:49] So he has endorsed line 12 as the appropriate, correct way to do so. That's the same guy who says most of what I did with implicit coercion is bad. But yet he endorses line 12. So which is it? Is implicit coercion good, or is it bad? And if you like line 12, then why don't you like line 2?

[00:07:16]
>> Kyle Simpson: Because line 12 is more implicit than line 2.
>> Kyle Simpson: If line 2 feels yucky then why does line 12 feel so natural?
>> Kyle Simpson: The point that I'm trying to get at here, cuz in both cases, we have a literal that is of the type we're intending, so they're both giving the same amount of semantic clue of what the end result is gonna be.

[00:07:42] On line 2, the end result's gonna be a number because we have a zero there. On line 12, the end result's gonna be a string cuz we have an empty string there. We're giving the same amount of semantic and syntactic clue as to the end result. The only reason why 12 feels more natural just cuz people have done it a bunch.

[00:08:00] There's nothing in essence that is more appropriate about that line versus line two. And the takeaway that I wanna get you to here is that all of the decisions that you make, all of the decisions that you make on this topic, are subjective. Now I'm not here to tell you what your decision should be.

[00:08:18] I just want you to stop pretending that this is a scientific coercion is evil and buggy and bad and should always be because I just read it in a book, okay? There's critical thinking to be done here. You're engineers, and I trust that you can think critically for yourselves.

[00:08:35] And moreover, that your team can think critically for yourselves and decide which one is the appropriate way for us to do this and make those decisions and then stick consistently to them, okay? What we like about line 12 is that line 12 is less verbose. We like line 12, and in fact many people would say line 12 is better than what I showed you earlier with the usage of the string function.

[00:09:00] So wait a minute, why is it that in this case, implicit is okay but in other cases, we say, no, no, no, I want it to be explicit? This one is not explicit. It's only explicit because you're familiar with it, but it's not actually explicit. The reason is that implicit mechanisms often times hide unimportant details.

[00:09:27]
>> Kyle Simpson: The most readable code, here's another one of those getify's laws, the most readable code is the code that doesn't have to be read.
>> Kyle Simpson: I know that sounds ridiculous because people have said things, like, well, the best code is code that doesn't have to be written. That's a complete nonsense statement, right?

[00:09:46] The best code is code that doesn't have to be written, that's a complete paradox. I'm saying something different. The best, most readable code is code that doesn't have to be read, not that code can't be read cuz it doesn't exist. It's code that doesn't have to be read.

[00:10:00] And why? Because it's instantly recognizable. It's familiar. And, it only deals with the topic that we care about at that point. It doesn't have any unnecessary noise. The best, most readable code is the code that hides any stuff that I don't need to read right now. Cuz I only have a finite number of neurons that I can devote to understanding what I'm reading in front of me, and I'm not particularly good at it anyway.

[00:10:23] And if I can hide all that other stuff that would be inclined to distract and confuse me, it's gonna be more readable. Implicit is good in the same way that declarative is good. They're isomorphic of each other basically. It's good in both cases because what they do is focus on the end result and focus less on the how to get there.

[00:10:48] They let the engine figure that part off. Declarative is all about the what, imperative is all about the how. Here, implicit is all about the what, I just want a string, man, just give me a string. Implicit is all about the what and Explicit is all about the how.

[00:11:10] Specifically, I'm gonna tell you, do it with this operation. So maybe there's some gray area here. Maybe there's sometimes where implicit is really important to us. When used appropriately, maybe we can actually make our code more readable. You can only do that if you actually understand the system.

[00:11:29] So some of you may be wondering at this point, well, shouldn't I just boil it down to the lowest common denominator? Cuz even though I'm here taking this class, other people on my team, they're not gonna know it. Shouldn't I just use systems that can't trip anybody up?

[00:11:45] Take into its logical extreme, that basically means that you think I am suggesting, nobody should ever have to learn anything to be able to understand code. That is not what I'm saying. Familiarity is good. Codifying idioms and having consistency, good things. But that does not mean that every member of your team should only read a code base that's been dumbed down to the most inexperienced of the members of the team.

[00:12:11] What it mean is that everybody on your team should going upward in terms of their learning. Or let me go this way for you, it should be going upward in terms of your learning. So the downward, okay? I don't care where you're at in your knowledge of JavaScript.

[00:12:26] That doesn't concern me. You know what concerns me, your direction. Wherever you're at, as long as you're learning something, you can do a lot in the culture of your teams to improve this situation. You can use code review not as a way to insult and gait people but rather as a way to empower people.

[00:12:47] Many people are scared of code review because the culture of their company is broken such that people are afraid that they are gonna lose out on a promotion because they had a bad code review. That is a broken culture, that's not a code problem. That's a culture problem.

[00:13:03] And you're in control of fixing those kinds of things. You can go to your bosses and your decision makers, or your companies and say, code review is a vital part of making sure that we all learn. You should be begging for the opportunity to sit with other people, show them something a little bit more so they learn, and then sit with somebody who can show you something so that you learn.

[00:13:23] Cuz I have news for you, that's how humans have learned for tens of thousands of years. We don't learn by reading books, we don't learn by sitting in classrooms. You know how we learn? By working with other people, it's the relationships that matter. You should look for every opportunity to do that.

[00:13:38] So in your code bases, don't look for, well, how do I make it so simple that nobody could ever be confused? That isn't the goal. The goal is, make it so that it appropriately communicates. And anybody that's not at that level, help them get to that level. Does that make sense?

[00:13:55]
>> Kyle Simpson: So a coercion is something that can be learned, and I'm arguing, should be learned.