Transcript from the "Understanding Your Types" Lesson
[00:00:51] As I've said several times now, I don't think that that is an effective strategy. Part of the problem with avoidance of anything but especially an entire unit of of the language like that, is that it tends to systematically perpetuate bugs. That is to say it's not that one bug will happen or one bug won't happen but the mindset that says, I don't even need to understand this whole part of the language, perpetuates bugs, that's a systematic approach, and I would never recommend a systematic avoidance of any particular thing, that is avoidance of even understanding it.
[00:01:48] So we have to do something. We've got to change the way we structure our code. We've got to use these mechanisms that are available to us to start signaling those typing things. And of course, you could go all the way to using a whole static type system, like a typescript or a flow.
[00:02:05] And if that's your answer, I'm not gonna beat you up, right? Like that's okay, and that makes sense for a lot of teams. But I do think that there's a way to embrace that because I really think that's almost an avoidance of the issue as well. It's a different kind of avoidance.
[00:02:40] In fact, I think it's less difficult for you to learn this system taught properly than to go learn all the complexities of a static type system. I mean like thinking about all the sophistication and typescript, I would consider that to be a very daunting task. And I think what I'm trying to discuss here is a much simpler and smaller thing to learn.
[00:03:21] But if you think about your code better and you think about your types and you design things so that you understand what they're doing, you'll end up designing better code, and that code will be more robust, it'll have fewer bugs. And that's if you do nothing with the double equals, just think about your types, right?
[00:03:35] You don't even have to use the double equals to get that benefit. So if you hear nothing else about me, at least from me on this unit, at least hear that. You should be striving for that in your code. I think you can optionally choose to use other approaches, and maybe Typl is one of several that could begin to exist in the ecosystem that give other options besides these extremes.
[00:03:57] So hopefully that is gonna open some different avenues of analysis, really that's all I ask, is that you go back and think about those things, test out the assertions that I'm making, and see if they make sense for you and for your code. But I'm quite confident that your code quality will suffer if you persist in the I don't need to know types, right?
[00:04:21] Triple equals is all I ever need. I just don't think that's better code. So, hopefully I've given you some food for thought. That is it for the types and coercion unit of our course.