 So it's come to my attention that I haven't actually done any videos on typing systems, which was rather foolish because that's actually something that is really at the core of programming languages and what makes them different from each other. This is a huge important thing to understand and it was rather foolish of me to have not done this. Now, I do have some videos, especially like the introductions where I cover typing and what typing itself, what types themselves are, which is going to brush up on that real quick in case this is the first video somebody is watching and isn't really familiar with this stuff yet. So types, basically how the data should be interpreted. Because in a computer, everything is just a collection of bits and your, that's it. You don't really understand types. So you can kind of think of a type as a encoding of sorts of those bits. That this pattern of bits refers to this thing and this type. The most common and straightforward one for that is numbers, because numbers have a very clean encoding since you can treat the bits as binary and from binary you can easily convert to whatever base that you want to work in, typically that's decimal. But this isn't the only one you can do that with, like characters, which fundamentally form the strings of text. There are different encodings for different character sets and these patterns map to different letters and symbols and other stuff. But like you might expect, there's different approaches to typing and that these different approaches are referred to as typing systems, largely because there is really no silver bullet. You will find some people who advocate for one of these systems very strongly and it mostly has to do with where they're getting the majority of their experience with. Like anything, everything has something it's good at, something it's bad at and if you only work with something in a specific area, it's easy to think that it's like the greatest approach ever. Because you haven't worked with it where it doesn't do well. So now we're going to do the actual typing systems. There really isn't any particular order in how I'm doing this. It would kind of be nice if I could set up like a hierarchy and traverse down that, but realistically, especially for major programming languages, they don't fit any specific one of these, all that strictly, and in fact it's quite normal for a programming language to be predominantly one but still actually use one of the others mentioned. So first we have strong typing. This is where values are a type and just are that type. Pretty much end of story. Like if you have a variable named A and you say that it is an integer and is currently five. You can't then go on and assign it the string of hello world because you said it was an integer. Now you can because it's a variable assign it another integer value, but it must be another integer because you already said it was an integer. And in contrast to that, sort of, we have weak typing. This is where values have a type but are flexible. Essentially the variable that you assign, its type really just represents what its current value is. So in that same analogy, if we have a variable A and you say it's an integer of five, if you then assign it to the string of hello world, that is an OK operation but A becomes a string after that point. So if you try to perform any integer operations on it, that will have problems because it's no longer an integer. Now in more serious direct contrast to strong typing, you have untyped or just no typing system at all. This is what assembly does, the actual processor instructions. With only one exception I'm aware of, the computer doesn't understand types. There is however some higher level languages that do this as well, with forth being probably the most common example of an untyped higher level language. So forth isn't particularly like really, really high level. Why you would want this is a little bit hard to explain. It has its uses but is definitely a niche thing. Generally speaking you wouldn't want to actually go this route. We have nominative typing. This is a special form of strong typing, so this is definitely just part of, or a form of strong typing. There will be one after this which is also considered strong typing and is different from nominative but you should be able to see how both of them are considered strong typing. So in nominative typing values are what they are named. That might seem a little bit odd at first but basically if you have two integer types say the standard integer which would be the range of whatever the processor supports for integers but then you have a named and constrained integer, say percent type that is anything from 0 to 100. If you assign A as an integer to 5 but then you then go try to assign it the percent of 50. Because you said A was an integer and percent is obviously a different name from integer even though the values are fundamentally compatible you cannot do that. Then in contrast to that we have structural typing. This is again a special form of strong typing but where values are more their structure than their name. Essentially you can view the name as aliases for the structure much in the same way that you have multiple aliases, the birth name you're given but also the names that you have online. And like I had said the same as long as the structure is the same they're compatible. The names are just aliases and not these hard steadfast things. It's the structure that is important hence the name. Then we have duck typing this is where it starts to diverge a little bit from strong typing because duck typing isn't quite strong typing but it's not quite not strong typing either. It sounds a little bit weird. I do have an example of this in a bit but basically in duck typing things are what they are like. This gets its name from a little bit of a I'm not really sure quip or something where if it looks like a duck and it quacks like a duck then it's a duck. You might have recognized there that it was the properties of it that were important and that's the whole thing with duck typing is you're not really concerned with what it is specifically but just whether or not it has the property that you're interested in the property that you're going to be using. So we get into static typing. Static typing and strong typing are not the same thing in fact it is possible to have a weakly statically tight system. These static and the dynamic that we'll talk about immediately after this are essentially compatible with any of the aforementioned other than non-typed of course in that these do not have anything about them that conflict with the previous stuff they are just different approaches to the previous stuff as well. Essentially that the overall typing system that a programming language uses is going to be some combination of the aforementioned and static or dynamic typing. So for static typing essentially that values are what they are said to be and that this doesn't change over time. This might seem to conflict a little bit with weakly typed and at least sort of based on the naive definitions that I'm giving here just so that you can have a you know general idea of what these are and not be overwhelmed by immense data or immense amount of discussion about what's happening to the underlying data. They do sort of but with static typing the whole idea is that the type is static hence the name and I know not the greatest definition basically that it doesn't change over time. How that differs from weakly typed is that in a weakly typed system now it's fine I'll do some more specific ones on any of these if you want to learn more and I can talk a little bit more about the specifics about this in that. Like I said I'm trying not to barrage with immense technical details here. So we have dynamic typing and this is in direct contrast to static typing of course and so values are sort of what they need to be ideally a little bit more realistically values are what the runtime figures they should be. This is like if you've ever if you've ever been especially like text output or text input also you see it mostly with text output though. In many languages you can just put a say a number in to one of the parameters of the text output and that not quite accurate because the number isn't strings or text that can be written out what happens is there's a little bit at least of dynamic typing going on and that the system recognizes that this needs to be a string and attempts to convert it. Obviously this this is useful it can wind up being a bit of a pain as you'll see but it's definitely a very useful feature in the right the right kind of task but wait there's more we're just not going to be getting into them. There are some specialized stuff like the unified type systems and dependent typing and other things that are like I said specialized they're not really worth talking about in a general overview I'll try to get to the specifics of each of them in time they're just not for this video so then if you watch most of the other lectures you should recognize that I do talk talk a little bit about my my tendencies my overall thoughts and stuff like that this one's going to be a little bit different I literally think all of these have their place but because so much of the discussion is about why you want to use duck typing or why you want to use dynamic typing I thought it would be interesting to give the counter argument why you would still want to use static typing so why static typing and I mean the cool kids aren't doing it isn't that reason enough more seriously though I have some examples this is in TypeScript and you can see laser pointer somewhere that's not helping let's go back this is in TypeScript which is essentially JavaScript where some type annotations are added at compile time but there's no way of enforcing them at runtime because the runtime is JavaScript which is dynamically typed so I mean really other than the type annotations up here this isn't that different from ordinary JavaScript you should be able to read this just just fine if you know JavaScript but you'll notice that there are regular as string as string as string throughout here and these wound up being needed because for whatever reason despite how the user should obviously be a string because if you if you were to go to the lookup method it expects a string and very clearly expects a string and a string would always be passed into this it would attempt to convert it to an integer I don't know exactly why that was happening but it would attempt to convert user into an integer despite everything expecting it to be a string now in a in a truly static type language what you would see is that because user is declared a string here everywhere user is throughout here would be a string and you wouldn't need these three type annotations you'd only have the one this is though admittedly a sort of odd example most of the time dynamic typing will get it right and will actually make your job overall a little easier but for whatever reason the type inference got messed up in in this specific method so we have another example and this one's on duck typing you see that for this one we have user but it accepts either a user class because these are classes here tip or message and that for user or message it has the property user but for tip it has the property from user and you need to basically inspect the the object that's being passed in to see if it has the property that you can call now this has a little bit of a glaring hole in that if the thing that's passed into this is not any of these classes it'll attempt to call something that isn't there and this will be a problem but in practice that's never actually wound up happening in this code has been running for somebody for well over a year at this point in a static typing system however well that duck typing is sort of static but in like a more stricter static typing system what you would see instead is that there would be say two or three applied discount methods and that just within them they would always call the correct property you wouldn't need to do this check and that's favorable I feel because the the compiler in that instance can figure out exactly which applied discount it needs to insert into the code and so you have no comparison being done at runtime every time this is being called and in fact this is actually quite a bit more than just a comparison in instead of just the the I mean this is basically an if else that's happening here instead of just this being run it also has a bit of introspection because it's needing to determine whether or not this has this property this is quite a bit of overhead now luckily this this method isn't called an insane amount of times but this this is a lot of additional overhead for not really a huge amount of benefit overall though I think duck typing really has a place like I'm not overall bashing on duck typing it actually winds up being really useful for certain things as a last example just because this this one of being a little bit absurd the only in important part here is this you see limit is initially assigned a string because it's shifted off from this is basically the message that's being sent and ideally in a dynamic typing system this the is not a number function should recognize that or the runtime should recognize that it expects a number and should attempt to convert limit into a number more or less because it got it wrong I had to forcibly convert it into a number to then pass to the is not a number which should sound a little bit weird but if you've worked with JavaScript you you know exactly what's going on here under the hood anyways and interestingly the same thing basically happens here I forget exactly what the issue was but if limit wasn't a if limit was passed as a string it wound up causing some some problems with print and the thing would crash it couldn't despite print being the code for that totally expecting a number it just it very much got confused and would pass it a string stuff like that so overall though again each of these have its place essentially what I was trying to show there is that for more complicated code essentially your final product you probably want a strong statically type system in place but if say what you're doing is querying your company's financial records to do some analysis on that all of that's going to get in the way and a dynamically typed system is going to make your life a lot easier a weekly dynamically type system would be probably best in your situation and that's why scripting languages tend to be used for those types of things but overall all this has helped you out have a good one