Hey everybody. php is a dynamically typed language. It's very loose when it comes to types. That is to say, you could write an entire php application without ever declaring the type of a property, or parameter, or variable, and the language couldn't care less. Let me show you what I mean. Here I have a scratch file in PHPStorm, and I'm going to create a simple function called add that receives two parameters, A and B, and it sums those two parameters up and returns the result. Now, as you can see, we're not type hinting A or B here, and php allows us to do that. It does not force us to declare types for any parameter. A dynamically typed language. Now, of course, I would logically pass two numbers here, 1 and 2, and if I echo the result of that out and then run this script, sure enough, 3 is output to the console.

language. Now, of course, I would logically pass two numbers here, 1 and 2, and if I echo the result of that out and then run this script, sure enough, 3 is output to the console. It works. However, I could also pass two strings in here, foo and bar, for example. Now, php isn't going to complain at all. There is no compilation step, there's no static analysis step. It doesn't know that we can't pass anything other than integers to this function, so it will allow it. But when we try to run the script again, well, as you'd expect, we receive an error because you can't add two strings together. PHP doesn't work like that. Now, obviously, for quite a while in PHP, we've been able to add types to parameters and class properties and the like so that we can make our intent more clear. So now, when you're looking at the function signature for add, I see that I have to pass two integers, and

properties and the like so that we can make our intent more clear. So now, when you're looking at the function signature for add, I see that I have to pass two integers, and any decent IDE will complain and tell me that I should have passed integers here. The reason it's not doing it at the moment is because I have inspections turned off in PHPStorm for videos. However, just because the IDE says that there's a problem, well, PHP isn't going to complain. PHP will allow you to write that code, and it will execute that code until an error is thrown. So if I now rerun this, I'm going to receive a new error, which is, yeah, argument one must be of type int, and also argument two must be of type int. But notice it never actually got to argument two. It failed before that, and that's what I mean by dynamic versus static types. There is no static analysis in PHP. The only time

notice it never actually got to argument two. It failed before that, and that's what I mean by dynamic versus static types. There is no static analysis in php. The only time you know that an error is going to occur is when the error actually happens in the code during the runtime step. Now, you might think at this point, why would you have a dynamically typed language? There are lots of upsides to dynamic types. For one, the learning curve in a dynamically typed language is so much lower. You don't have to think about types, so that's one less thing to learn, one less thing to worry about, and it's one of the reasons why PHP is so easy to pick up. Also, a lot of the magic that Laravel has would not be possible in a strict typed language. Something like Rust, well, you can never have the Laravel framework written in Rust. It couldn't have the magic because it wouldn't

not be possible in a strict typed language. Something like Rust, well, you can never have the Laravel framework written in Rust. It couldn't have the magic because it wouldn't allow it in the first place. So there are some very cool things we can do with dynamically typed languages, but yeah, as you can see, there are also downsides. We would have found out about this as a bug much earlier if there was a static analysis step. Now, thankfully, we don't have to go without that in php because tools have been created to allow us to statically analyze our PHP code before we push to production, and that can help us catch a lot of problems down the line. Now, there are a number of static analysis tools available. The one that I prefer is phpStan, and I think in the Laravel community, it's the default adopted static analysis framework. So I'd stick with this, but you could also check out Psalm, for example,

I prefer phpStan, and I think in the Laravel community, it's the default adopted static analysis framework. So I'd stick with this, but you could also check out Psalm, for example, if you want to see some of the alternatives. So with our static analysis tool of choice selected, why don't we go ahead in the next episode and see how we can install phpStan and begin using it in a real Laravel application.