Let's get going. My name is Adam Harvey and you can find me on Twitter as Elnome. I work for a company called New Relic. We do interesting performance analytics stuff, which is pretty cool. Check it out. That's all I'm going to say about that. I'm going to talk to you about PHP 7 today. I am peripherally a member of the PHP 7 Internals team, which means that you get to blame me for anything that you dislike about the language, even if I didn't vote for it. I'm going to talk about the biggest transition that we've had in PHP for, I guess, really 11 years. Maybe you could argue PHP 5.3, but the transition from PHP 5 to PHP 7. This talk is mostly about migrating existing code to PHP 7. I'm going to touch on a few new features as we go, but mostly what I want to give you today is kind of an appreciation for what's going to change, what might break your code and a rough toolbox for kind of what you can do to fix those problems as you find them or more accurately find those problems so you can fix them. PHP 7, like everything, has a logo. Very nice. I'm supposed to have a space in it. Sorry, Vincent. It's taken us a while to get here. Let's see where we came from. PHP 5 was first released in July 2004, so it's 11 years ago now. It only really snapped into focus as a modern language with PHP 5.3, which came out six years ago in 2009. During this time, of course, PHP 5 has, in theory, the idea is that you're not supposed to break back compatibility. Anybody who's been around for PHP 5.2 to 5.3 knows that we've been better at that with some releases than others, but the idea is basically that PHP 5 hasn't changed too much as time has gone by, stuff's been added, but not too much stuff has been removed. In 2012, we started releasing new minor versions, I guess, feature versions annually, roughly. It's actually about every 15 months, if you do the maths, we're not very good at annual releases. Each of those has included a bunch of new features, but kind of as we've gone by, it's also become apparent that there was an increasing amount of stuff that we wanted to remove, I guess, from the language as well, miss features that made sense in 1997 when nobody knew any better, but don't make sense today. There are things that we could deprecate, but the problem with sticking to PHP 5, of course, is that it's very, very hard to actually remove stuff because that is a backward compatibility break. There were a few key things like magic quotes where we just went ahead and did it anyway because it was the right thing to do, but for the most part, we tried to avoid that. So I stirred the pot early last year and was like, let's talk about whether we want to do a new release. But what really got things going on PHP 7 was in May, Sebastian Bergman sent this very confused email after about 800 commits appeared out of nowhere on a new branch in PHP Source. The source of that was from Dmitri Stogov, Shincheng Hui and Nikita Popov, who sponsored by Zend did work on something which a lot of you have probably heard of called PHP NG, which was basically a next generation engine. So the PHP runtime runs on a virtual machine called the Zend engine. PHP 5 runs on the Zend engine too. PHP NG was a huge refactoring of pretty much everything to do with the runtime for performance reasons. And the performance, of course, as a lot of you will have seen, and we will see in PHP 7 is significantly better. This is only the first step. PHP NG was about 50% quicker in PHP 5 on an average kind of workload. Say a Drupal site, say a WordPress site, say a symphony site, whatever it may be. Obviously, this was really going to be the impetus for a new major version. So of course, the floodgates opened at that point. All of those little irritations, you know, why can't we get rid of this? Why can't we get rid of that? Why can't we deprecate this? Why can't we implement this? Because the pass is broken. The floodgates open. And by the time that the feature freeze happened in February, we ended up with accepting 45 RFCs, pretty much all of which corresponded to new features. As of Tuesday, when I updated this slide, there were almost 10,000 commits and 180 just code contributors. Now, the total contributor counts higher because people have contributed ideas, people have contributed documentation, people have participated in mailing list discussions, but the point is it's been a very, very, very big project. It's not as big as Drupal 8 probably, but it's still pretty big. And that contributor count, by the way, is easily the highest we've ever had for a new major or minor version. Like that's way off the charts. PHP 5, I looked it up at one point. PHP 5, I think, was about 40 people. PHP 7 is now 180. So a fair bit's changed. So as I said, I guess, well, why would you want to upgrade to PHP 7? Well, for one thing, it's a lot faster. I ran a few benchmarks this morning just to kind of get up to date numbers. This is one I just care about, we're just building the PHP documentation, which this is measured in seconds. So it used to take over a minute on this laptop in PHP 5.3, and this laptop is not too bad. Now it takes 20 seconds in PHP 7. It's an awful lot quicker. So as I said, I did this benchmarking myself. It's terrible benchmarking, but I don't trust benchmarks. I didn't fake myself. For a typical blog, that is very strange. My apologies, there's meant to be some graphs. Let me just show you some speak. Let me, you can just look at my speaker notes for a moment. So PHP doc was considerably quicker. A competing product to Drupal is also much, much quicker. It's about three times quicker. I actually had to rerun this just to make sure I hadn't screwed up my environment, but it really is PHP 7 is three times quicker than PHP 5.5 was. For my Drupal benchmarks, it wasn't quite as impressive.  So that's my bad, sorry, bad benchmark. Like I said, don't trust them. The other one that's impressive is the memory usage. Now a lot of these performance gains have come because we're hitting cases more often. And the reason for that is this is a standard Drupal 8 beta 15 index.php just hitting it, seeing what the peak memory usage is. PHP 5.5 and 5.6 was within like a K of each other. It's 36 megs or something like that. The resonance size is now 29 in PHP 7. So it's smaller as well. You can host more sites on the same hardware. That's pretty awesome. All right. Of course, it's also better. I'm going to talk, as I said, a little bit about features, not much. But when you see some of the cleanups that have happened to the language, I think you'll hopefully agree that it is better than it used to be. There is, of course, a problem though. I mean, that's the carrot, but here's the stick. PHP is popular. You know, PHP 5, there are 140,000 GitHub projects. And I actually didn't update that number. I did that back in May. So it's probably like another 20,000 now. There are tens of millions of sites, if you believe, builtwith.com or whatever it's actually called. There are 44 million PHP websites out there. About a million of those are Drupal. So good job, Drupal. But the point is there's a huge long tail of, like, probably 20 million of those sites are just, like, somebody hacked together a guestbook in PHP 4 or something like that. Every time we break something, this obviously causes problems for people. Now, the other problem is, the trade-off with the annual release strategy is that the flip side of that was that we decided to support PHP versions for two years, fully after they were released, and then another year for security fixes after that. PHP 5, therefore, is not very long for this world. PHP 5.6 came out over a year ago. So what that means is, PHP 5.6 is end of life then. What that really means is everything before PHP 7 is end of life then. It's pretty close. It's not that far off.  We can't fix everything in that space of time to be PHP 7 clean. Of course, it's not really that bad. You do have some options for handling the migration. You can stagger it out a bit more if you have to. What can you do instead? Well, you can rely on distribution packages to buy you a few more years. That being said, I mean, theoretically this is great. Ubuntu will still support PHP 5.5 until April 2019. It supports a new enough version of PHP 5.5 that Drupal 8 will run on it. I assume Drupal 8's minimum requirement was probably scoped to match this rather than the other way around. Red Hat, you know, if you're running Red Hat 7 or CentOS 7, PHP 5.4, we support it until June 2024. That's nine years from now. Where were you nine years ago? The catch, of course, of that is the longer you stick your head in the sand, the more you're relying on the distribution maintainers getting backports of security fixes right. Because obviously in my near 11 months, how many days it was, the PHP project won't be supporting PHP 5.6. Backporting security fixes, if the code is pretty much the same, is not that hard. Backporting security fixes, if you just rewrote the entire runtime, is pretty hard. So I think there's a viable strategy like if you need an extra six months, 12 months, 18 months, but I don't think it's a viable strategy if you really want this in nine years. If you really still want to be running PHP 5 in nine years, you may have bigger problems.  Just change everything over, you know, just do your testing, do your integration, and then say, okay, well, we'll switch to PHP 7 on this day. But probably what you're really going to want to do for a while is do your wield. You're going to want to use both PHP 5 and PHP 7 depending on what you do. Now, if you're admitting a site, that's great, but if you're maintaining, say, a module, you know, a theme, anything that has to run on both, this gets a fair bit harder. Because a brief digression is a language design. Breaking back of compatibility is tricky for that use case because code that supports both can only run in the intersection between those. Now, in PHP 7, we've tried to maximise that space, and I think we learned some lessons from other languages here, and I'm going to pick on Python for a minute. Python 3 came out seven years ago, almost seven years ago. There are still, of its top 360 packages, there are still 15% of them that just straight up don't run on Python 3. Most of the rest run on both, some of them are Python 3 only. Adoption's being rocky, just adoption of Python 3 has been very rocky because of the difficulty of supporting both versions, particularly in the early versions of Python 3. This got a lot better around Python 3.2 or 3.3. In PHP 7, we've tried really hard to minimise those problems. So that's why I think the right thing to do, particularly if you're maintaining module code, or theme code, or extension code, or whatever it is, is to have your code run on both for a reasonable period of time, because, and this completely undercuts the point of my talk, in a lot of cases, you don't really actually have to do very much. It's a relatively straightforward process. So, as I said, that's what you can do, what should you do? As I said, I think you should just run on both. The other thing you need to do if you maintain a module, or you maintain any kind of code that's used by anybody that's not you and the people that you can hit with a squishy ball from your desk, is you need to tell your users what you're gonna support and for how long. You know, you need to say, okay, my awesome module is gonna work on PHP 5 and be supported on PHP 5 until December 31st, 2017, or whatever date you pick and stick to it. Document it, put it in big block letters on the top of like your page on Drupal.org. You need to tell your users what you plan to do. And if you are a user, look for those policies. Figure out what you're gonna do. Figure out how you are going to upgrade. Because you don't really, you don't really wanna support both for like a single project. It's really only if you're sharing code where you wanna support both. If you're relying on somebody who are relying on a project where the author hasn't said what they're gonna do or hasn't got PHP 7 compatibility, if it's an open source project, consider contributing, make a pull request, ask them. You really just need to get the prompt to think about it and be receptive to that. If you wanna run on PHP 7 because you want the awesome performance improvements but you can't, but you're relying on a library that doesn't support PHP 7, yeah, you can fork it and fix it and run it for a period of time, but you don't really wanna diverge from upstream like that.  All right, so PHP 7 is awesome. I've now scared you all. What are we gonna do about it? I've got a site, big Drupal site. I wanna run it in PHP 7. How do we go about actually doing this? Well, your number one best possible thing for this is testing. Right, you know, if you don't have tests, right tests. If you do have tests, right, more tests.  These are the biggest single thing that you have to combat problems with cross version compatibility is running your tests in PHP 5 and PHP 7 and seeing what breaks. If you're using PHP unit, then PHP unit integrates with XD bug and you get lovely code and branch coverage stats. The branch coverage stuff is new and super cool and I highly recommend looking into it. I assume there is also a way to get this out of simple tests, but I apologize for standing up here at a Drupal conference and not actually knowing. The point is testing is what you want to do. You wanna make sure that you are testing your code. There is also tooling out there for this as well. Now, Alexia Smith has written a project called PHP 7 MAR, migration assistant report. And what that does is it just basically, you give it a directory full of code and it will go away and recursively scan all the PHP and it will tell you what might break. I ran it on Drupal core, which you can actually see kind of in the background of that and I came back with a bunch of stuff and most of it's not critical to be clear. Like most of this is just advice, but there is also a level there for, oh my God, this is really going to break. Rasmus Luthor has also written a tool called fan, which is a more general static analyzer, which is kind of very embryonic, but it does also, it can actually detect some of these backward compatibility breaks as well. So there is tooling out there. These are links. I will put a link up to my slides at the end so you can jump in there and go to those. You can also just Google them. So there is some tooling out there. It's pretty, both of these are pretty alpha at the moment. They're both like 0.1, but they're both useful already. Like they'll give you an idea of what's going on. And obviously the other thing you can do is try it. You know, assuming you have a development environment or a staging environment or something like that, and if you don't, you probably need to consider that, then install PHP 7 on it, see what breaks. You know, do some informal testing. That's a perfectly viable strategy as long as it's not your only strategy. It's a very good strategy. Just make sure you also use the tooling and do some testing. All right, so what are these breaks? What's PHP 7 broken? Now I'm focusing mostly on the things that are a little more insidious. A lot of PHP 7's breaks have big screaming errors that are very obvious, like it will fatal error and it will tell you what's wrong and you can go away and fix it. But there are a few changes that are not quite so obvious. So let's get into them.  It's not actually all variables. It's better and worse than you think. The problem's really that the way, the associativity of some of the way that we handle indirect references has changed. What do I mean by an indirect reference? Basically these are the four cases. Now the thing you will note is that they're all involving variable variables in some way. So that one's a straight up variable variable. That's a variable property name, which then goes to an array, variable property name, variable property name. These have all changed behavior in PHP 7. They've all changed behavior in ways that you may not get errors. You might just get incorrect results. It depends on what your properties actually are, what the variable variables actually are. Are they callable in some of these cases? But first, why are we doing this to you? Why are we inflicting this horrible pain on you? The reason is because it allows us, all the parser cleanups and the implementation of an abstract syntax tree means that we can now support all of these awesome things. You can now do JavaScript style like immediate call closures, or immediate calls to closures. You can now dereference things and just call them. You can have arrays and just call them if they're callable. So there's a lot of really cool stuff there. The problem's just that to implement all of this, a few of the earlier hacks had to go away. So all that's awesome. The good news is, when this was implemented, Nikita Popov worked on this. He had a look at Symphony and Zen Framework 2, I believe. I don't think he looked at Drupal, but he looked at Symphony, which obviously now Drupal depends on, and Zen Framework, and there was literally only one case in both of those frameworks where this actually mattered. The problem, of course, is finding the one case in both of those frameworks where this actually mattered. So how has this changed? So basically, I'm just gonna walk through each of these in turn, PHP5 version, PHP7 version. If you can't remember these as I skip through them in 20 seconds per slide, that's okay, these are all in the migration guide as well, which I will link at the end. But I just wanna sort of give you a flavor of kind of how this has changed. So in PHP5, this fairly horrible expression basically broke down to take the value of foo-bar-bas, and then use that as a variable name.  But in PHP7, now it will basically look at the variable variable first and then treat it as an array. So again, that's what I'm getting at. It depends on what these variables actually are. If what's pointed to by dollar-dollar foo isn't an array, then obviously you will get an error, and that's great. But if it is an array, maybe you won't, and that's why you have to be aware of this. You might just get null or you might get something completely different. The next variant, and there's a couple of these which are basically the same. In PHP5, basically, bar-bas was what you'd use as the property name. In PHP7, foo-bar becomes the property that you're accessing, and then you treat that as an array. This variate, there was another variation on that too on the first slide, I'm not gonna go through it, and then this variation is basically literally just the static version. You can probably imagine how that's gonna change. Goes from bar-bas as the property to foo-bar is the class. All right, what do I do about this? How do I detect this horrible case somewhere deep in code that some contractor wrote 10 years ago? Well, once you've found them, preferably using the tooling that I mentioned earlier, you can actually get this behavior. All of the examples that I just showed are actually valid syntax. So you can specify what behavior you want by using curly braces appropriately. You can specify what, or you can break it down, and this is actually what I'd prefer to do, break it into two instructions and then just do it that way. So I said, what do you look for? You can use tooling, PHP7, mar definitely detects this, because I tested this yesterday just to make sure they did. You can also, if you really want to, I wrote a regex, it works. Maybe you don't do this, but if you really want to, you can just pull this out of the slides and trust me, it works. Oh, it doesn't support non-ASCII variable names. So if you have Unicode variable names, sorry. All right, moving on. PHP7 now has engine exceptions. So in PHP5, there was no scenario, basically, where the Zend engine would ever throw an exception. There were a couple of cases in core extensions where you might get an exception. I think there was one in the DOM extension, for example, but there was nothing in core where you'd ever get an exception thrown. If the Zend engine has an error to tell you, it would tell you via an error. The problem with that, of course, is that errors are hard to deal with. Fatal errors you can't intercept in any way, shape, or form. Recoverable errors you have to go through, like, set error handler and handle them that way, and that's pretty ugly.  So in PHP7, wherever possible, the runtime will now throw an exception instead of generating an error. It's a normal exception, you can catch it, you can do whatever you want with it, you can re-throw it, you can, whatever works for you. Or you can just let it bubble up, whatever the right behavior for you is, but the point is there's now more flexibility. So in PHP5, there were 182 errors, 17 recoverable errors, and one pars error. I think this was PHP 5.6. In PHP7, the number of these has dropped dramatically. The number of fatal errors that you can't actually catch is now down to 54. The number of recoverable errors is now down to three. Pars errors are now gone altogether, but the constant lives on because basically if you don't catch the exception that the pars error generates, then it turns into a pars error. So how does this work? Here's an example, and this is a little bit of a sneak peek of something I'll talk a little bit more about later in terms of type declarations. Here's an example of some code that will generate a type error. In this case, we're giving a string to something that expects an integer. Now, what you'll get is you will get, if you don't have a try catch or a set exception handler, you will get a fatal error, but the key is it's an uncaught type error. So it's an exception. Type error is just the name of the exception class. It's uncaught, and it then has like any other exception, or any other, yeah, any other exception. It has a message. So the nice thing is now, at the point where you actually made the call, you can just catch it and do whatever you need to. You know, report an error back to the user. Maybe it's something that's non-critical, so you just wanna keep going. But the point is you can catch it and deal with it like any other exception. Now to do this, the exception hierarchy in PHP has changed. In PHP 5, everything inherited from exception. It was basically this God exception class that everything else inherits from. In PHP 7, it's been moved down a level. This is something that will seem familiar if you come from Python or Java, but is new PHP. So the exception stuff still exists. None of that's changed. There's still a class called exception. There's still subclasses of that called logic exception, runtime exception.  But there's also now this parallel hierarchy of errors. And these are intended for internal errors that PHP generates. So when PHP hits a parse error, it will throw a parse error exception. When it hits a type error, it will throw a type error exception. There are currently five. They're all in the migration guide. I expect that there will be a lot more in the next few versions of PHP. I think 7.1 and 7.2 will probably subclass a lot of these out again. But the important thing here as well is that there's now this top level thing called throwable. Now throwable is an interface. You can't actually go new throwable. Any, in PHP 5, any exception had to be an instance of exception. In PHP 7, any exception is an instance of throwable, maybe not necessarily exception. So what that means is that if you had something in PHP 5 that had this pattern, a Pokemon handler where you've got to catch them all, you knew that any exception that got thrown would be caught. Like that block there would basically always run if an exception got thrown. In PHP 7, that's not the case. It's now possible for PHP to throw an exception that won't be handled by this. Now that might be good. I mean, you're not expecting to get exceptions from the language here probably. So if you don't want to handle those, then you don't have to change anything. You just keep it as exception. But if you do want to catch everything now, you have to catch throwable. Now that does work. You can of course also do a catch throwable and catch exception as well to get both. Not sure that's a good idea. So what do you do? Now, Drupal 8 is going to catch your throwable, is going to catch throwable that you don't handle with its own exception handler. So if you're good with Drupal's default exception handling, then job done. Go to the pub. But what I would suggest is if you have code, if you have a code base that you want to run on both where you're doing your own error handling, I would say you set up use the setExceptionHandler function to set up an exception handler that will basically catch, be a last result handler in PHP 5 and basically make it very similar to your error handler. So basically do the same things in setExceptionHandler that you would do in setErrorHandler which is probably just print some sort of message to the user and log something and get out. Exit. The key here is that, so in PHP 5, I actually, I'm sorry, I jumped ahead there. In PHP 5, I'd use setErrorHandler and a Pokemon handler at the top level like if you've got a front controller. In PHP 7, I would use setExceptionHandler in a similar way to setErrorHandler and then as said, just do what you would normally do. Of course, rules are made to be broken. There are times when you'll have to catch errors. At least now, it's gonna be a lot closer. If you try and say include or highlight string some sort of block of PHP code that's invalid, hey, at least you can now deal with it. That's a bonus. And you can deal with it in the same function rather than having to jump to another scope. There is an additional wrinkle too. If you have an exception handler in PHP 5, you may have type-inted it with the exception class. Now, obviously in PHP 7, if it throws something that isn't an exception, it's just a throwable, then you're going to get a very big fatal error message. It's gonna be pretty ugly. So in PHP 7 only, you would have to change that to throwable, but the right thing to do is probably just not to have a type-int on your exception handler. Just whatever it is, it is. Trust that PHP will never give you something that's not an object. I really hope. All right, what am I looking for?  That's pretty much all there is to it. It's mostly, this is probably actually a really good opportunity to just check that what you're doing with the exceptions and errors makes sense. Like, you know, give it some thought, make sure that whatever you did a few years ago still makes sense today. It's a good chance to do it. All right, speaking of, so earlier I said that we changed how variables work. Now I'm gonna say we're gonna change how foreach works. Well, how is it broken? Let me count the ways. It's okay, there aren't that many. So, what happens when we modify an array that's being iterated in a by-reference foreach? So, just in case anybody doesn't know what this does, we're iterating this array but we're actually grabbing a reference to the real value for each time we iterate over it. So in this case, what we do is when we see the first item, we are adding a new array item and var dumping. Now in PHP 5, what would happen here was you would only get, although the array would change to one, two, you would only actually get the first element. Now, again, if you're doing this, don't. But if you're doing it by accident, you need to know this has changed. In PHP 7 now, it will do a really good job of trying to keep track of how the array has changed out from under you and actually still iterates in the next thing. This is actually probably much better behavior. I mean, still don't do it. This is probably much better behavior, but it is different. The other change relates to these functions. Now, if you've only started writing PHP in the last 15 years or so, you've probably never had to use these, but this is how we used to do iteration back in PHP 3 before 4H was a thing. So in PHP 5, 4H used to actually set the internal array pointer that gets used for what the current element is. So you can actually do horrible things like this. You could var dump the contents of the current element without actually ever using the dollar V. In PHP 7, the internal array point is never touched. So if you have basically 4H's that then also run any of these functions within the 4H on the same array, it's gonna change. That's probably a good thing because you probably need to rethink this anyway. What do you do? Well, don't use the old PHP 3 functions for one thing. I would say beyond that, if you need to manipulate arrays or manipulate elements within a by-reference 4H, consider using array walk and array map. I mean, with anonymous functions and closures in PHP now, it's a lot simpler to do this. You get a completely fresh scope where you don't have to worry about messing anything up outside. One of the bugs that we get the most in PHP is that we get reported the most is where somebody's used a 4H with a by-reference variable, and then they've reused that variable after the 4H. Now, what happens for those of you who haven't encountered this before is the PHP, that's still, because PHP doesn't have block scope, that's still a reference to the last item of the array. So if you reset that variable to something else, you just changed what was in the array. That's usually bad. It looks like spooky action at a distance. So you can use array walk and array map to actually effectively deal with that problem. You don't have to worry about the scope leaking because you have a true function scope there. I mean, the right thing to do here really is if you have one of those two cases, you just need to refact your code to not do that. And you're looking basically, you're probably gonna have to look, there are no errors for any of this, so you're probably gonna have to look at any 4H where you're doing it by reference. That's probably fair advice anyway. This one's kind of obscure, but again, it can be silent. It's not always gonna be silent, but it can be silent. So in PHP 5, anything that looks kind of like a number in a string is treated as a number when you try and use it as a number. So the 0x10 is treated as a hex decibel number. In PHP 7, it will not be treated as a number, but you also won't get an error. The reason for that is because of another of PHP's misfeatures, which is that when you cast a string to a number, if it starts with a valid number, it will treat that as a number and then once it gets to something it doesn't think as a part of a number, it just throws it away. It doesn't actually, it doesn't warn you, it doesn't try to use it, it just gets rid of it. So in this case, the x is the first non-numeric character in PHP 7.  So now it's zero. Not really what you want. So what do you do?  You can use scanf to say, hey, I've really got a hex string or an octal string, please treat it as such. Also, why do you have an octal string? My point is you can do it. What do you look for? I don't know. Interestingly, however, the Alexia's PHP 7 martl actually picks this up. I haven't, I didn't, I haven't pulled it apart. This only got added recently. I haven't pulled it apart yet to figure out how. So tooling, tooling is good. The behavior of list has changed again. This is really obscure, but I'm just mentioning it, because again, because it doesn't generate any warnings. In PHP 5, you can unpack strings like arrays using the list construct. So you can basically go ABC and you get ABC. Interestingly, this only ever worked if the right-hand side was a variable. You couldn't do this, where that dollar S is on the second line, you couldn't do this if that was a string literal. I have no idea why. In PHP 7, you can't do it anymore. It won't warn you. I really wish it did, but it doesn't. You just get nulls, because it's not an array that's going in. Of course, if you want that behavior, you can do it in a completely PHP 4, 5, and 7-compatible way by using string split. Turn it into an array because list expects arrays. What do you look for? I have even less idea on this one. If you don't use list very much, then just look for all the list instances in your code. If you use list a lot, then good luck. We only just added yield. How could yield have changed? Well, the associativity has changed for the same reasons as the earlier indirect variable stuff has changed. So in PHP 5, yield foo or bar basically implicitly put brackets around that, so you got a boolean in that case. In PHP 7, that now binds to the yield, so it goes yield foo or bar. Accessing dollar bar probably isn't super useful, but it does mean that you could actually now do the classic Perl style yield something or die pattern. Please don't do that. What do you do about it? Just use parentheses, just specify how you want that to actually work. Sorting has changed. This sounds dramatic, but it's not. PHP's never guaranteed that you have a stable sort, so for performance reasons, PHP basically gives you no guarantees about how sorting works. Well, it gives you a guarantee that the lowest thing will be at one end and the highest thing will be at the other end, but it doesn't give you too many guarantees about how that's gonna work or what order things are the same will be in. So in PHP 5, so basically all that's happened here is that the order of some objects when they're the same gets swapped. So this is doing a case in sensitive sort, just watch the bottom line. In PHP 7, the lower case O comes first. In PHP 5, the uppercase one comes first. In practice, I very much doubt that this will break anyone's production code, but I suspect it will break people's tests. So this is one that I think you're more likely to see in tests where you're testing for a particular array output. So you're looking for it in specific test cases and I think you're really just looking for broken tests. Really, if you have a test where you're testing that a function returns an array and you wanna test that array, you need to be testing that elements are in the array. You shouldn't be testing the whole array itself, I think, as a general rule, because this sort of thing can happen. Unless you have a very clear order in which case, I guess it's fine. Everybody probably knows this warning. I suspect everybody's seen it at some point, probably lots of times. Usually at about 5.30 on a Friday afternoon when you're really just trying to spin up one more server for someone. In PHP 7, it's gone. That's not necessarily good news, though, because all it means is PHP just picked UTC for you. Now, if all your servers run in UTC and all your applications expect UTC, that's great, but if you don't, that might be a source of silent breakage. Just always set a date time zone. So if that's all the things that don't scream at you, what are a few of the things that you need to know about that will? You can't use any of these as class names anymore. Even if they're like just the last, you know, even if it's a namespace class, you still can't use these as class names. The reason, of course, is because of the new static or scalar typing feature that's come into PHP 7, which I'll talk a little bit more about in a minute. This seems to have disproportionately affected test suite authors and doesn't seem to have affected too many other people, but I do know that Drupal 8, this did affect symphony, so Drupal 8 then had to pull in a symphony 2.3 patch to actually make this work. So just something to be aware of. I would also avoid, even though they're not officially gone, I would also avoid scalar and void, because I think there's a pretty good chance in PHP 7.1 that they're both gonna appear. Their warning. If you ever use the HTTP raw post data variable, it's gone. It's been deprecated for a while in actual fact, so you've probably been ignoring deprecation warnings in this case, but it's really gone now. So you need to use file, get contents, PHP input. This is actually, generally speaking, a good thing. The old MySQL extension is gone. Now, if you are solely using Drupal's database APIs, that's fine, don't care, doesn't affect you, but if you have to interact with code outside of Drupal, just be aware of that. It's really gone. You also can't use this. I don't really know how to go into more detail on that. Apparently, Global used to work with variable variables. Who knew? There is more stuff that's broken. All of it has very obvious errors, as I said.  There is a very, very exhaustive list of backward compatibility breaks in the migration guide. Your eyes will glaze over while you read it. I can assure you my eyes glazed over while I was writing it, but you will, at some point, need to know them. So I suggest setting aside a day where you're very awake and getting a coffee and going through the list because there's a bunch of stuff in there that's important. So it's not really the goal of the talk. This wasn't really part of the abstract, but I've got 18 minutes still. So let's look at a few of the new, just three of the new features really quickly. The big one, the headline one, a lot of respect. Once you get over all the graphs where PHP 7 performs way better, and it's really cool, is type declarations. And you saw these on an earlier slide. Basically, you can now type int, and they're not called type int anymore. They're called type declarations. There was a big find and replace there. You can now use scalar types to basically hint, or tell PHP what type you want a variable to be. Don't clap too much. I voted against one of the features that's coming up next. I voted for this, I should note. The cool thing about this is that you are guaranteed within foo that A and B will be an integer and a string. No matter what the user passed in, you are guaranteed, and no matter what, whether they're in strict or weak mode, which I'll cover in a sec, you are guaranteed that in that function, if that function actually executes, A and B will be an integer and a string. Definitely, no ifs, buts, or maybes. So that's awesome. That saves a ton of boilerplate, figuring out what type you've got, whether it's really a numeric string, like calling isNumeric, things like that. That's all gone now. You know it will be an int and a string. How those become integers and strings, however, is configurable. There is a strict mode and there's a weak mode. Strict mode is optional. You have to turn it on with that declare that you can see there. But what that does is if you give an integer to a function that expects an integer, or sorry, if you give a numeric string to a function that expects an integer, you will still get an error. It will not be coerced. Even if PHP could coerce it without any loss, you will get an error. You will get an uncaught type error. You can catch the type error if you really want to. But it will error. The default, though, is weak mode, which you can declare strict type zero if you really want to, but don't bother. And in this case, PHP will coerce. If it can coerce the value that comes in, it will coerce it using the same rules that have always applied to internal functions. You know, if you have given, say, the power function, a numeric string in PHP, it will convert it to a number if it can. So this behaves the same way. It uses the exact same rules. Now, the interesting thing about the strict types is this, that declaration applies to the file. It's a file scoped thing. And it only applies to function calls that you make within the file, not functions you define within the file. So it doesn't matter. When I declared foo, it doesn't matter whether strict types was one or zero in that file. The point is that in the file where I actually call it, if strict types is there, then strict type checking will take place. What that means is if you're using an API, you get to decide whether you want strict type checking on or not. If you are writing an API for someone else to use, you don't get to decide that. But at the same time, it doesn't really matter because you know that you're still getting an integer and a string. It's just up to the person who's calling your code to decide whether they want that to error or not if strict type checking is enabled. This also applies to return types. So you can also type int, type declare. Even I've got to still go through the process of finding and replacing. You can define what type a function will return. This is subject to the same strict typing as before. So if this function returned, in weak mode, if this function returned a numeric string, that would be fine. It would succeed. It would get converted to an integer and the code that called it would get an integer back. In strict mode, if you returned a numeric string, then it would error. And again, you'd get a type error and you'd get to catch it and you could do something with that if you wanted to. Again, the nice thing is that you know that the thing is getting returned as an int. Where I think this is really gonna be useful is in interfaces and in sort of class hierarchies because now you can basically define, okay, I'm defining an interface for a user. The username will always be a string. The email will always be a string. The login function will always return a boolean. And you know that no matter who implements or whoever writes the class implements this, their return types will definitely be those things, otherwise PHP will jump up and down and scream at you. I think that's pretty cool. I think it's gonna greatly improve like the ability to use duck typing, it's gonna improve the ability to do, just have general type safety and data safety in PHP. So I commend it to you. Another thing that's in which is kind of small but really useful is the null coalesce operator. We've all written blocks of code like this, I suspect. Is this variable defined? If it is, use it. If it's not, use something else. In PHP 7, you now can shorthand all of that. There's a double question mark thing which I believe we shamelessly stole from C sharp which we'll do the same thing. Small but nifty. The other new operator that came in in space, the final frontier was the spaceship operator. The spaceship operator, which I'm told is a tie advanced, basically is a comparison operator. This again exists in some other languages and PHP is shamelessly stolen on it. Basically it will compare two values using PHP's internal comparison rules. So whatever variables or expressions you give it, we compared using PHP's internal compare function function. It's called compare function, I wasn't, I didn't start it. The funny thing is, you've never actually been able to access that before. Like there's never been a way in PHP to do it. If you knew they were both strings, then you could use string compare. If you knew they were both numbers, then you could subtract them. But if you didn't know what they were, you didn't have a type safe way of doing this. Now you can just use this.  It's really useful for that. There is a ton more stuff. The new features page in the migration guide is actually longer than the backwarding compatible page. And trust me, the backwarding compatible page is long. So there's an awful lot of really cool stuff. Again, I strongly recommend seeing down, this one you'll probably stay awake more for. So do this after the backwarding compatible page but definitely sit down and read it. There's things like anonymous classes, better assertions, unicode escapes, massive generator improvements if you like doing co-routine stuff. There's a bunch of cool stuff there. Group use statements, so you don't have to type use and a prefix every single time you import 10 things from the same namespace. It's pretty awesome. I've just lost focus too because apparently I have to re-authenticate to the Wi-Fi network. All right. So when can you have all of this wonderfulness? Let's assume I've sold you, let's assume this 50 minutes hasn't gone in vain and I've sold you on how good all of this is. The good news is it's really soon. We're currently in the process of shipping release candidates. We shipped release candidate three last week, which means release candidate four or the final release, but it'll be release candidate four. We'll be next week. The expectation is we'll have a few more. You know, the more changes that you make in a version of PHP or any project really, generally the more release candidates you have. PHP 5.4 had eight of them and PHP 5.4 was smaller than this, so hopefully it doesn't go too much beyond that but you never know. The target date for this when we set out a timeline months and months ago was November. We're tracking pretty well for that. We're releasing a release candidate every two weeks that may go to weekly at a certain point, depending on if we get to the point where it's really just one or two bugs each release candidate might go to weekly. But basically it's the classic open source process. We keep shipping release candidates until nobody reports a critical bug after the last release candidate and then that becomes the release. It's gonna be pretty soon. Like I think it will be this year. It might even be in the next couple of months if things go really well. You can already get this too from a number of places. Homebrew now has packages for this. There are, Andre Suri has Debian packages. Remy has RPMs. They will work on Ubuntu, Debian, Red Hat, CentOS, the usual things. These are again links. You can go find them later if you need to. So there are pre-built packages available for common distributions and they're built in ways that match the normal system packages for those distributions. You shouldn't have to go in and reconfigure how, say, PHP, FPM starts or something like that. It's pretty much the same thing. You can also build it yourself. If you've built PHP before, PHP 7 is exactly the same. The dependencies haven't really changed. It just builds the exact same way. If you haven't built it before, maybe don't do it in production, but it's actually an interesting learning experience. There are instructions on the website. There are many IRC channels where you can get help. It's probably worth doing at least once just to try it. Finally, turnabouts fair play. We're still on the release candidate stage for a reason. We don't necessarily feel that what's there is completely stable right now. I think it's pretty good. I've been running a bunch of production sites on it, but I'm also insane, an Australian, but I repeat myself. So don't necessarily go ahead and do that. But what we really need people to do is test their sites on PHP 7. And this goes double if you're running Drupal 8, in which case you are very brave and thank you. You should totally test your Drupal 8 sites on PHP 7. Drupal 8 has good PHP 7 support. And if you find a bug, please report it. Please, please, please. Because without people running tests, we have a test suite. We all run sites, but the reality is everybody who works on PHP has been running PHP 7 for long enough now that we've run out of bugs to find. Like, you know, we've found the bugs that affect us. We need to know the bugs that affect you because that will help make PHP 7 that much better. So please report bugs. If you can figure out how to fix it or at least write a test case, send PRs. There's a contributing markdown document at the top level of the PHP source. It details how to create a pull request, how to contribute code. I would also love contributions to the contributing document too. If there's something that's not listed in there that you figure out, please send a pull request for that. We'd love to merge it. So that brings us to the end of PHP 7. We've got about six or seven minutes for questions. There is a microphone about halfway down on that side. Please rate my talk on the Drupalcon website. And also, as I said, please read the migration guide because there's lots and lots of good stuff in there. Thank you very much. Hello. Hello. Does the fact that there is weak and strict type checking and you have to choose between them mean that a difficult decision was dodged? Yes. So when I said there was a thing I voted against, that was actually the thing I voted against. I would have preferred just to make a call and stick to it. But basically, I mean, it was, I mean, scalar type hints have been on the agenda since at least PHP 5.2. The idea's been around for a decade at this point. So I think at the end of the day, if that compromises the thing that got them into PHP, then I am willing to overlook the ugliness and just go, hey, we improved the language. But yes, we totally dodged a question there. All right, let's see someone else moving. Hello. So obviously, thank you for the show and all the work with PHP 7. So one thing that obviously Facebook is now working with the HBM, do you know if they will have any plans of adopting these features to HHVM or are you just proceeding with hack? I don't want to put words in Facebook's mouth because I don't work for Facebook. My understanding is that they are in general going to merge features back into HHVM. They intend to make, when not in hack mode, they intend to maintain source compatibility with PHP, including PHP 7. So I don't know their timeline on that, but my understanding is that, yes, this will all appear in HHVM in due course. Okay, thank you. So regarding variable variables, are you saying that the variable single arrow, curly brace, dollar sign, whatever, that's gonna stop working? It will keep working, but it may stop working for you because the associativity has changed on a lot of those. So let me go back. Bear with me. Let me see if I can find this. Okay, went too far. Back. Okay. So I probably skipped through this a little too fast. So basically, all of these still work. Like none of these will generate parse errors, but the meaning of them has changed. So I mean, if we always use curly braces, will it continue to... Yeah, oh sorry, yeah, I misunderstood the question. Yes, so basically all of the examples I showed there with either parentheses or curly braces, those will all work on PHP five and seven. So you can use those to just manually tell PHP exactly what associativity and precedence you want for those expressions. Okay, thanks. There is a path, you can do both. All right, I don't see anybody else moving towards the mic, so I think we'll wrap it up there. Thank you very much, you've been great. I'll just leave the link to the slides up for a minute. I will tweet this as well in a few minutes.


In this video, we're gonna prove the trigonometric identity sine squared of x over two is equal to tangent x minus sine x over two tangent of x. Well, how are we gonna prove this? Well, I usually like to pick the more complicated side and it's very tempting to think that the right-hand side's more complicated. You have some fractions and differences going on, but I'm actually gonna start with the left-hand side because of the difference of the angles, right? What I mean by that is the left-hand side has an x over two. The right-hand side, all of the angles are x. So the only way we can prove this identity here is we have to convert from x to x over two or the other way around. And so that's where the half-angle identity comes into play here. So remember, when it comes to sine, sine of x over two, this is equal to plus or minus the square root of one minus cosine of x all over two. But this is the half-angle identity for sine, but if you square things, things get a lot easier. You get sine squared of x over two is equal to just one-half one minus cosine of x. And so that's the version that we actually wanna use right here. So let's prove our identity now. Let's start with the left-hand side. Like I said, the left-hand side can be sine squared of x over two. And then by the half-angle identity, this is the same thing as one-half times one minus cosine of x like so. And so we can start with that, all right? Which we can, again, write that as a fraction. Cause again, we're trying to write this as a fraction right here, so let's rewrite this as a fraction. You get one minus cosine of x over two, right? Let's compare to where we're at. We want a two tangent on the bottom. So it seems very tempting just to times the bottom by tangent of x. If we do that, we have to do that to the numerator as well. What happens if we distribute the tangent here? Well, you get one times tangent, which is a tangent. And then you're gonna get tangent times cosine. So let's investigate this. This seems to be a fruitful direction to go. You're gonna get tangent of x minus cosine of x times tangent of x like so over two tangent of x. Well, we want this product cosine times tangent to be a sine, otherwise we'd be done, right? So if we think of tangent in terms of sines and cosines, that would look like tangent, of course, we know is sine over cosine. And so Bob's your uncle right there. We see that there's a tangent. When we did the tangent, you got sine over cosine. There's a cosine now in its denominator, which cancels with this cosine. And so this would simplify to give us tangent of x minus sine of x over two times tangent of x. So we were able to prove this trigonometric identity here because this is the right hand side. We were able to prove this trigonometric identity using the half angle identity. And in particular, when you're using the half angle identity, the original version we have here with the plus or minus the square root is not always the easiest one to use. Oftentimes we prefer the square right here. So you get sine squared of x over two is equal to one half one minus cosine of x. Or an alternative version here as you get sine squared of x is equal to one half one minus cosine of two x. This is a very useful version. Likewise, cosine squared of x is equal to one half one plus cosine of two x. These versions of the half angle identities are gonna be probably much more useful for you when you're proving other identities themselves and other calculations as well. So be aware there are multiple versions of the half angle identity. And that brings us to the end of lecture 19 about the half angle identity. Thanks for watching everyone. If you've learned anything in these videos, feel free to give us a like, subscribe if you wanna see more videos like this in the future. And as always, if you have any questions, feel free to post them in the comments and I'll be glad to answer them for you. Bye everyone.


I'm going to go in a different direction from Ryan and bring things down to the business level, to the level of companies and managers, to talk to you about why Austrian economics and how Austrian economics can make managers better. Most of my academic and professional work is sort of at the boundary between economics and management. I'm trained as an economist, as an Austrian school economist. I teach in a business school and I teach mainly courses in entrepreneurship and management. And for example, I teach the global strategic management capstone course in our executive masters program. And it may not surprise you to know that some of the students in that MBA program, are somewhat skeptical of the claim that economics can help them be better managers. Why? Well, maybe they remember the economics courses they took back when they were students, right? And they didn't get much out of this training that they thought would help them very much in their professional roles. Or, you know, here's economists telling you about firms, right? There you are. The firm on the left-hand side, this diagram tells you exactly what to do to be profitable. You know, and to be fair, economics is not always taught especially well at the high school undergraduate or even graduate level. You know, many people remember a class like this. You know, anyone, anyone, anyone. Bueller, Bueller, Bueller. Now, you know, in full disclosure, economists have not always been very sympathetic to the profession of management. Economists often think management is sort of silly and trivial. It's about, it's about emotions, understanding emotions at the workplace or, you know, the secret to being successful as an entrepreneur, as a professional manager, is to have a lot of charisma or to, to have the right power pose. Remember the power poses, you know, how many books and lectures and TED talks have been devoted to teaching firms and managers how to increase their profits, right, by holding their arms in a certain way. Most economists are not very sympathetic to the management consulting industry, right? There was an interesting book by two writers from the economist on the consulting industry called The Witch Doctors, which I think summarizes the view of many professional economists that the consulting business is sort of a scam. It's kind of a puzzle as to why companies would throw good money, what would, you know, write these big checks to McKinsey and Bain and so forth. Maybe it's some kind of strategic signaling.  Not completely clear, but the point is that, you know, it's not obvious to many participants on either side of this conversation whether economics has anything useful for managers. I mean, look at the popular management books that fill the shelves of the bookstores, not the Mises bookstore, but, you know, if you go to your local Barnes & Noble or you go to Amazon and, you know, look at the management section or the leadership section or the entrepreneurship and innovation section and, well, I mean, I haven't read all of these books, but, you know, I'm certainly familiar with the genre and, you know, most economists would perceive this literature as extremely fluffy, right? There are a lot of people selling, you know, trying, there are a lot of people shilling books and coming up with a kinds of goofy, you know, fattish concepts and lingo or whatever, but there really isn't much substance there. There certainly isn't anything that would be especially useful to the practitioner. Now, there's some exceptions to that. Within mainstream economics over the last decade or two, there have been some more serious attempts to grapple with managerial and organizational issues from the perspective of, you know, basic economic theory, very influential textbook by the later Nobel laureate Paul Milgram and John Roberts applies kind of basic neoclassical economic principles to a variety of managerial issues. I used to use as a textbook this book called Economics of Strategy, which is actually not bad and has a little bit of Austrian content in it, not as much as I would like. The economists, Nicholas Bloom and John Van Rienen, Van Rienen, sorry, have published a series of empirical studies on what they call management practices within manufacturing companies and service companies as well, doing these sort of large-scale surveys to try to find out if, you know, giving incentive pay to workers, having more effective forms of performance evaluation and so forth, you know, in very large samples of firms in different countries can yield efficiency gains or performance improvements. And they found some very compelling evidence that better management practices do improve profitability at the corporate level and also what the sort of national economic level. But what about the Austrians? What about the Austrian school? What can the Austrian school say specifically that is relevant for management and useful for managers? Well, let's go back to the origins to the founding of the Austrian school with this gentleman, Karl Manger, who published his Magnum Opus, The Principles of Economics, the Grundsetze in German in 1871, which by the way is also available in this wonderful Mises Institute edition with a foreword by one of my favorite authors. It's probably too small for you to read it, but it's me. You know, Manger's book introduced an entirely new way to think about economic systems, to think about economic action, to think about and understand how prices are determined, how goods and services are produced and so forth. And Manger's work, which I'm sure you're all familiar with, really heralded a new and different way of thinking about economics. And Manger's followers, disciples and students, formal students or otherwise, including Bombavirk and Wieser and of course Mises, Hayek, Rothbard and so forth, really changed the way we think about economics. Manger, of course, was a professor at the University of Vienna, hence the term Austrian school, which was a label given to Manger and his colleagues and students, not by his friends, but by his enemies. As you may know, in the German-speaking world at that time, you know, to call someone or something Austrian was a little bit of an insult. It meant, you know, provincial, backwoods. It'd be like calling someone a redneck now, I guess. But the label stuck, and of course the Austrian school ended up changing the world and certainly changed our intellectual world for the better. It is sometimes forgotten that Karl Manger, before he wrote his great treatise and before he became a professor at the University of Vienna, was a journalist. He was a financial journalist, writing for a number of prominent Austrian newspapers, including the Wiener Zeitung, where his job was to report on, document, analyze and explain what was going on with prices. Commodity prices, prices of manufactured goods, real estate prices. So Manger's curiosity about how markets work and how prices are formulated did not arise from just sort of abstract speculation, but from his trying to understand the real world, trying to understand why prices were, why price movements were what they were in Vienna. So that led Manger to develop his theory of marginal utility, his understanding of how the value of factors of production, values of factors of production, are imputed from the values of the consumer goods they're used to produce, where the value of consumer goods is determined subjectively by the preferences and expectations, beliefs and actions of market participants. Hence, we sometimes use the term causal realist economics to describe Mangerian, Misesian, Rothbardian economics. We call it causal realist because unlike the mathematical versions of market analysis propounded by other schools of thought, and now in sort of within the mainstream of the economics profession that emphasize sort of characterizing equilibrium states with very sophisticated mathematical expression, the Austrians were always interested in cause and effect, right? How does human action cause changes in prices and quantities and other market phenomena? We call it realist, causal realist, because again coming from Manger's professional background, Manger was not interested in describing abstract hypothetical states like the perfectly competitive general equilibrium, but rather was interested in explaining real economic states, right? Real conditions, what's going on in real markets? Why is this piece of land on the market and trading at this particular price? Why does this commodity become more expensive or less expensive, depending on market conditions? So any approach to economics that focuses on causality and is interested in real economic phenomena ought to be useful to practitioners. It ought to be useful not only to us as scholars and thinkers and scientists and people interested in understanding the world from a political or cultural or social point of view, but also to those of us who make a living, right? Acting in the marketplace. Let me be a little bit more specific.  Reading all the classic works and you know Mises human action from front to back, if I were to call out a page number, you would immediately tell me what's the main contribution on that page. So you already know kind of what the distinct contributions of the Austrian school are. But just to remind you sort of at a high level, what I already mentioned, the causal realist approach to price formation is widely heralded as a distinct contribution of the Austrian school. But there are others as well. As this came up a little bit in Patrick's talk this morning, if you're familiar with the Austrian theory of the business cycle, you know that the Austrians place great emphasis on the capital structure of the economy, right? How goods, so to produce consumer goods and services, they're not, they don't just sort of appear magically in one step, right? There's what Menger referred to as the orders of production. There are higher order goods, raw materials and natural resources and so forth, which are transformed into intermediate level goods, which are transformed further into other intermediate goods and so forth until you finally get to consumer goods and services. The Austrians emphasized that these intermediate products, capital goods or resources or factors of production, if you like, are not identical to each other. They're not perfectly substitutable, right? Hence when, you know, the government expands the monetary money supply, we get increase in, we get credit expansion and what Hayek described as a lengthening of the structure of production. We cannot, you know, that has important distortionary effects on the production system and so when interest rates change, you know, investments in higher order goods and capital goods that were made in anticipation of a particular set of consumer demands in the future and facilitated by low borrowing costs now become unprofitable production plans that were made in the past are no longer feasible. Capital goods must be reallocated to other uses but because capital is specific or at least partially specific heterogeneous, it's not always possible to allocate, reallocate capital costlessly, thus leading to, you know, the classic bust, leading to the distortions that we see in the bust phase of the business cycle. I had a great conversation at the breakfast table this morning about the automobile industry with one of our participants who was in that industry and, you know, before 2000, before 2020, many people had not heard of the term supply chain. Okay, but now everyone understands supply chains. We're talking about the, you know, the fact that you see this if you've shopped for a new car or a used car lately and you know all about the chip shortage and other supply chain distortions that has severely reduced the number of new and used cars, new cars available and hence prices of used cars have gone way up. But, you know, failure to understand that cars or any goods and services, you know, again, aren't just sort of spit out in one stage but have to be produced through this lengthy and complicated production structure or supply chain. Failure to understand that leads to the mistaken belief, which of course most government officials have, that you can just sort of turn off the economy for a few months and then you just sort of turn it back on. Right? Well, we're going to send people home for six months, make them work from home, we'll pay them not to work and stay at home, you know, for pandemic reasons and then we'll tell them all to come back and boom, things will just pick up where they left before. But of course the economy is a complicated, you know, interconnected lattice work of different kinds of production and exchange with lots of different market participants. The complexity of the economy's capital structure means that you can't just turn off one piece and then turn it back on and have everything work the way it did before. This is, you know, this is sort of a common wisdom to anyone who's involved in pretty much, you know, any form of production or exchange, but completely unknown to the majority of professional economists outside the Austrian school, right, and government officials. So this emphasis on the supply chain on the lengthy structure of production is another unique attribute of Austrian economists in the Austrian school. And third, the Austrian school is rather unique in the central role it gives to the entrepreneur in the production process. And a lot of my own writings are on the entrepreneur and how entrepreneurship is essential for, you know, to have a well-functioning market economy, what kinds of institutional conditions are required to allow entrepreneurship to flourish. Again, this is something that I would argue is a distinct contribution of the Austrian school. So, okay, what does that mean specifically for managers and for management? What are some distinct Austrian implications? Implications of Austrian economics for managers and for management? Well, you know, one unique insight of the Austrian school is that competition, right, is not a process of, you know, sort of establishing a superior market position that you can protect forever with a moat, you know, around your castle. So unlike the conventional approaches and strategy based on the thinking of people like Michael Porter, which teach entrepreneurs and managers that they need to establish and exploit their market power, right, Austrian economics teaches that competition is a continuous process of rivalry among entrepreneurs and managers, right, where as long as a firm does not have legal protection against potential competition against entry, there's always the threat of new technologies, new companies, new business methods on the horizon, possibly competing, you know, as actual or nascent competitors. And that with this dynamic process-oriented understanding of market competition, Austrian economics teaches that the secret to success, to competitive advantage, is continuous innovation, right, engaging in entrepreneurial behavior, being being alert to and aware of potential trends and threats on the horizon. And again, rather than seeing competition as a static state, thinking of competition as a process of rivalry helps to direct managers' attention towards the things that they need to do to maintain, to achieve and maintain a strong competitive position. The Austrians, as coming from Carl Manger, emphasize the role of demand, right, it's ultimately consumer demand, subjectively perceived and expressed through action in the marketplace that creates, that is the value that entrepreneurs, managers, companies are trying to capture by offering goods and services that consumers will want to buy. Market power does not allow you to impose output on the market, right, value does not come from the resources that you use or from the position that you have in the market, value comes from consumer willingness to purchase the goods and services that you offer. Understanding consumer demand, having a continuous emphasis on satisfying the consumer, again, is a distinct attribute, it is an insight that comes from the Austrian way of thinking about value and exchange. As I mentioned before, entrepreneurship understood broadly not only as new venture formation or proprietorship, right, but as dealing with uncertainties, taking bold and decisive action to assemble resources and combine them in different ways in the face of a constantly changing world. Having that emphasis on one's business plans provides benefits and that is something that comes, again, from thinking about Austrian economics. Understanding the business cycle from an Austrian perspective can be extremely useful for professional managers. And finally, what I'd like to spend the rest of my time today talking about is some Austrian implications for organizational design, how companies are structured, organized, governed, how employees are incentivized, who has the authority to make what kinds of decisions, how is performance evaluated and monitored. So that's really the part of the broader Austrian contribution to management that I want to emphasize this morning. Why? Because like everyone else, I'm selling a book. A book on management that just was released Tuesday of this week, it's called Why Managers Matter? The Perils of the Bossless Company. So it's framed as a critique of this theory that bosses aren't important, that managers aren't important, and that we should have these sort of radically flat hierarchies without any sort of central coordination within the firm. But it's really more generally a book about how sound thinking on economics, Austrian economics, specifically, can inform managers. I'm not going to go through the book in great detail because, you know, I'm not that tacky unlike some of our other speakers, Ryan McMakin. But I will give you a discuss a few broad themes that are in the book and encourage you to find out more at the bookstore. Again, sort of what we're positioning our argument against is the view that you get in this genre of literature from management thinkers like Gary Hamill, who say, you know, we need to fire all the managers. Shakespeare said kill all the lawyers. Hamill says fire all the managers. The Australian management thinker Tim Costel says we need to make everyone a chief, right? We need to reimagine management and making everyone a chief is a good place to start. Elon Musk famously told his employees that anyone at Tesla could contact anyone else at Tesla, including Elon Musk, right, to discuss an issuer problem. There's no need to go through a middle management layer. You just go straight to the person you need, including the CEO. You've probably heard of companies that have famously flat management structures like Gore that makes fabrics and a number of other materials. Morningstar, the tomato company in California, the online retailer Zappos, the video game platform, developer and platform Zalv, Valve, Chinese company Hire, Danish hearing aid firm Otacon. These are companies that have been written up and widely touted in the business press for their radically decentralized or disaggregated management structures. I love this quote from the CEO of Hire. The system that they use for their highly decentralized system, which is called Rendan High Yi, is described by the CEO. He says, with this model, we move away from being like an empire with a traditional closed pyramid, you know, the traditional managerial hierarchy, to be more like a rainforest with an open networked platform. Every empire will eventually collapse. A rainforest, on the other hand, can be sustained. Now, I don't know exactly what that means, but it has that new agey vibe that characterizes a lot of the boshless company literature. You might have heard of a management model called Helocracy that was famously adopted by Zappos, but then later dropped. So the idea with Helocracy is instead of this sort of traditional model, like you have depicted on the right, where you have the CEO and then the middle managers on down to the staff and so forth, people are organized into fluid and constantly forming and reforming circles to solve specific tasks and an ad hoc circle will come together and then it will be dissolved and reformed without the sort of central direction that comes from the traditional managerial hierarchy. Some thinkers have referred to this with praise as rather than a bureaucracy, we should replace the bureaucracy with an ad hocracy, meaning putting people together in ad hoc groups to solve specific problems as they arise. Spotify, which most of you listen to, where a lot of you get your music, I'm sure, also has a sort of a new agey kind of a model where they divide employees into what they call squads and tribes and trios and alliances and guilds. Some of this is really just sort of branding. It's relabeling of this actually a fairly conventional matrix structure, which firms have used for decades, if not more. But again, within the new age, you get sort of a cute way of describing it. Okay, hold on, you say, isn't one of the primary lessons from great thinkers like Mises and Hayek when writing about socialism, for example, that bottom-up means of organizing are better than top-down? Isn't that, I often get asked, isn't that a central lesson of Austrian economics?  Lots of books, including books by prominent executives, argue that we need these more decentralized sort of market-based systems over the traditional hierarchical ones. Well, our argument in the book is essentially the following. First, flattening the hierarchy is not a new concept. Firms exist with a variety of structures and formats. It's been that way for a long, long time. Go back to the old cooperative movement of the 19th and early 20th century, putting the workers in charge, letting the workers run their own firm. That's not an information age idea. It's a very old idea and there are a lot of good reasons why it's very rare for firms to adopt this model of organization and be able to carry it out successfully. A lot of the evidence that is presented for this sort of new narrative, namely that all firms should adopt a radically flat, you know, disaggregated structure, is really sort of cherry-picked. Most of the ostensibly bossless organizations really aren't. What they do is they substitute for formal sort of, you know, statutory authority, a kind of an informal amorphous authority that is just as strong and sometimes even more difficult to navigate. Oh, sorry. I'll say something about Wikipedia in a second. A lot of times these ostensibly flat organizations are really dominated by a charismatic leader. Like, this is Tony Shea, who was the founder of Zappos. He passed away a few years ago. And essentially he ran the company the way he liked, but he advocated, he described it, articulated it as something radically flat. Many employees who worked at Valve have described it as like a high school.  And none of this is written down in an org chart, right? But it's very real and actually as a less transparent kind of a hierarchy, it can be much more difficult to manage. Another way that bossless organizations aren't completely bossless, and this is an important theme of our book, is that, you know, take Wikipedia, for example. Wikipedia does have a boss in a sense. It's this gentleman, Jimmy Wales, former student of our own, Mark Thornton at Auburn University who, according to Mark, read Hayek's use of knowledge in society in Mark's class and recognized the potential benefits of harnessing tacit knowledge and had this idea to create an online information source that grew into Wikipedia. Well, what Jimmy Wales and his co-founders did is they wrote the code for Wikipedia, right? The code that allows the entries to be displayed in a consistent format. The code that allows them to be revised and for you to track the revision history and for disputes about Wikipedia entries to be resolved and so forth. So Jimmy Wales didn't write all the entries in Wikipedia, but he did design the system within which Wikipedia entries could be created. That is a kind of management. That is a kind of bossing, if you like, not command and control, but creating systems and processes and procedures. And again, strong decentralization can work in some cases, but not in every case. Now, let's listen to Mises on this topic, writing about entrepreneurship and its relationship to ownership and authority. Mises says, the real entrepreneur is a speculator, a man eager to utilize his opinion about the future structure of the market for business operations promising profits. This specific, anticipative understanding of the conditions of the uncertain future defies any rules and systematization. It can be neither taught nor learned. The entrepreneur sees the past and the present as other people do, but he judges the future in a different way. So the entrepreneur, the characteristic entrepreneurial function, according to Mises, is this faculty of judging the future in a unique and idiosyncratic way. How does the entrepreneur put that judgment into effect? Well, according to the American economist Frank Knight, writing a little bit before Mises, Knight says, the only risk which leads to a profit is a unique understanding resulting from an exercise of ultimate responsibility which in its very nature cannot be insured nor capitalized nor salaried. In other words, this exercise of ultimate responsibility is the way that the entrepreneur puts his judgments into practice. How do you exercise ultimate responsibility through ownership by owning resources and assets? And some of my colleagues and I have developed the concept of what we call ownership competence, referring to the skill with which the ownership function is exercised. Why is this important? Because what the owner of enterprise is doing is assembling factors of production and combining them in unique ways to produce valuable goods and services. So again, what Mises, Hayek, Rothbard and others are, what they're arguing in their critique of socialism is not that there should be no ultimate responsibility, not that there should be no managerial authority in how resource assembly and so forth is done, but rather that it should not be in the hands of one single actor for the entire economic system, right? Mises argument is that in the absence of private property, you don't have exchange and therefore prices, you can't, you don't have a system of generating prices among factors of production for which entrepreneurs can engage in exchange and economic calculation. It's not a critique of authority per se, it's a critique of state centralized authority. Okay, one last quote and then I'll stop. You know, Hayek is well known of course as a critic of central planning along with Mises, but Hayek points out in ordinary language we describe the word, we describe by the word planning the complex of interrelated decisions about the allocation of our available resources. All economic activity is in this sense planning. This is not a dispute about whether planning is to be done or not. It is a dispute as to whether planning is to be done centrally by the state, by one authority for the whole economic system or is to be divided among many individuals. And those individuals include owners and managers of businesses and of companies. So the key managerial function in this understanding, right, is figuring out how to assemble productive resources, how to combine them in different ways to produce value to consumers. And in a complex multi-person system of production, the manager, the entrepreneur, the owner has to figure out how to organize people. When actions of different persons and groups within a productive system are highly interdependent, there is often a role for coordination by a managerial team where those interdependencies are weak, a flatter kind of a structure with more autonomy delegated to lower levels of the organizational chart can also be very effective. So our message in the book is that there is no one-size-fits-all solution for how to organize and manage companies. And certainly all companies do not need to be radically decentralized or disaggregated with a flat hierarchy. The traditional managerial hierarchy does have an important role to play even in our modern, knowledge-based, networked economy. Thank you very much.


Hey everybody, this is Brian and welcome to the sixth tutorial on Flutter. We're going to continue down our path with Dart. I'm going to try and go through these fairly quickly, but because Dart is a new language and there's new features, we've got to go through some of this elementary stuff. So let me more advanced folks just bear with me while I slog through this. There are some new features, so definitely pay attention and I'll try to call them out when I get there. So this is going to be our advanced functions tutorial. So the first thing we're going to do is just create a new project here. Make sure it's Dart console application. And let's call this advanced funk. Why not? I have a really hard time coming up in names for this sort of stuff. And it'll process and do its thing. Tick-tock, tick-tock, IntelliJ is always so slow. There we go. All right, so we've covered some of this stuff before. We've got our calculate function, which is off in the lib. And we're going to actually use that this tutorial. So if you're curious about how that works, definitely pay attention. All right, so we're going to go ahead and just get rid of this. We're going to leave this up here this time. And we're going to cover that in just a second. But let's get through the rest of this first. So in our main function, we want to make a variable. And let's just say list, my keyboard's crooked. Bear with me here. This is what happens when you get old and cranky. So we're going to make a list with an integer type. Call it list. And if you remember, these little brackets with the type in it is generic programming because that list can hold more than one type. And then in our list, we're just going to add a few values. So we'll say one. And I'm not going to really add too many variables. I'm actually just going to use this one variable because this is a function tutorial and I don't really want to spend a lot of time wasting your time writing variables. So I know a lot of tutorials out there have these big, weird, complex algorithms that are hard to understand. We're not doing that. All right, so we've got our variable that we're going to work with. So the first thing we're going to cover is a function as an object. Maybe if I spell object. So what does that really mean? Let's just make our function here. Nothing's super special about this, right? And we're just going to say print. All right, there's really nothing going on in there. If you remember, everything in Dart is an object. And I mean everything, right down to functions. So we're going to say list for each. Now you notice how there's a little bit of verbiage here for each.  We're just going to double click it from the moment. And you see how it says void f element, e element, sorry. So really what that's saying is it cannot return anything, void. And the function itself is going to take the element. Now the element goes back to generic programming. Under the hood, this actually says something like this. List e, and e would be the representation of whatever object we're shoving in there. So the template for this thing has to be void, cannot return something, and then it has to take the element. So we're just going to say as object. Finish this off with our semicolon here.   But now I'm trying to find other things to watch, like a Netflix junkie, all right. So when we run this, this is what happens. It says as an object, bam, and then list for each. And then we're calling the actual function as an object itself. This object is instigated when the code is run. So we don't have to do this new, blah, blah, blah. It already exists in memory, and there's one copy of it. So as object, and then that has to follow the template. So if we do something like this, it may get kind of Frankie on us and say, hey, nope. Yep, see, argument instring void cannot be assigned, blah, blah, blah, blah. Basically, what that's saying is it has to follow the template. And the template is you're passing one element, which is in that list. So that is a function as an object. I tend to not use that too much, because then the code gets kind of weird. You're trying to hunt down this thing and figure out what's going on. Go through it, then I guess it's OK. What I tend to do is I'm just going to copy and paste this whole thing rather than type that all out. Bang. As an anonymous function. I'm lazy. I really didn't want to spell anonymous six times. This keyboard is kind of jacking with me. I need a new one. I was playing Call of Duty, and admittedly, I slammed my fist down on the keyboard, and now it's acting kind of crazy. Anyways, so we're going to do four each. Now this time we're going to do something a little different. We're going to do what's called an anonymous function. Now an anonymous function has kind of a crazy syntax, but it'll save you a lot of headache. What you can do is say four each, and then we're going to just say parentheses i, and then bracket. And don't forget to close this out with a semicolon. And we're just going to say print i. This is bananas. What is this? Let's run this, make sure this actually works. So as an anonymous function, bang, what the heck is going on here? So what we're really doing is we're creating a function in memory that only exists in this little loop here. It actually under the hood gets optimized, and it turns into a temporary function in the base code or whatever. But for our purposes, we don't have to jump around all over the place. We just know that, hey, we want to do this, and we want to do it right here. So it does the exact same thing as this. It's just you don't have an independent function that you can call as an object. Notice the syntax is we have our parameters, and then we have our brackets. We have our scope block here, and then we have our actual code of what we're going to run. It's pretty simple, pretty elegant. I actually hated anonymous functions when I first saw them. But I think I first saw them in Java, and they just drove me nuts. But they're pretty useful. As you can see, you don't have to make yet a separate function now. If you're going to call this many, many times, like over the course of your entire program then definitely branch it off into a first class function right here. So now we're going to see what I mean about my keyboard. Eternal, external, why can you not spell keyboard? I'm going to Best Buy and get the new one. Forget this. External function. So what is an external function? We've been talking about this little file over here for a while now, let's crack this back open. You see how it's got a function. It returns an integer as called calculate, and it has no parameters, and then it just returns six times seven. We can actually call that externally. So let's just say print, and how do we know what to do? I mean, how do we call that thing? Can we just say calculate? Notice how when you start typing calculate, it recommends advfunk.calc. Where did it get that name from? Let's just double click it so it puts it in there for us. It actually got up here from this import statement that we left, and if you accidentally delete it, go ahead and retype all that in. But it's very simple, import, and then we're importing a package, semicolon, and then the path to that package. Advfunk is actually the name of our project here, advfunk, and then the actual Dart file, advfunk.dart down here as, and this is where we're creating the variable. So really, it's that. And we can run this, and you can see the result of that is 42. So let's crack this open. Let's just add another one here. Let's say bull loves this keyboard string name. So if the person in this function is Brian, me, then I do not love my keyboard.  All right, so as you can see, loves this keyboard. And then we could say, I'm so buying a new keyboard and there's our false. So how would you actually go about making your own here? You can actually make a new one. We'll just call this Dart file, let's call this myfile.dart, and rather than typing that out again, we're just going to cut this, put it in our little file. Notice how when we did that, suddenly main.dart got cranky because this no longer exists. So now we've got to make another import. We're importing a package and there's different types of imports, but we're just going to cover the package for today. And notice how it actually tries to help you out. So we're going to import advfunk slash myfile.dart, the file we just created. Now we need to make it as a variable and let's call this call of duty. It is currently grayed out because it's unused. We're going to actually change that, bang, now suddenly it's used. Does the same thing. So that is how you would import an external function. Now, the next one is going to get a little bit crazy, but this is the last one in our little tutorial here. We're going to compare apples to oranges. You've heard that expression before if you're in the United States or maybe even if you're out of the United States. So we're going to make optional parameters here. And we're going to say int apples equals zero and int orange is equals zero. And then we're just going to simply say, compare to other number. And actually we don't have to do any of that. We can just return it. I had different in my little notes here of how I did it, but this is actually, there we go. Maybe, there we go. That didn't work either. What did I do wrong here? Richard type int, oh, that's why, because it's doing an int type. So the compare to function is something I ideally didn't want to use, but basically, let's just switch this just so we can see. Compare to is used for ordering in list, which we'll cover in a future tutorial, but let's just do this. What we're really focusing on is this part right here. We have our function and all this does is it has optional parameters. Notice these are optional. They're optional because they're within these brackets and they have a default value. And we're just going to say, are you possessed keyboard? What are you doing here? Geez. All right, so naming a parameter. And we're going to just say, compare. Notice how you can actually put the parameter name in there and then hit enter. And it's giving us a negative one because they're not. So let's just change this to nine, that to three. You see how it's now a one because it does an ordering thing. I was going to use a bull, but let's just say this is six and this is six and it should come back as zero, meaning they are equal. So why would you want to actually name your parameter? Why can't you just do the order here? Very simple. A lot of more advanced code will actually use name parameters. When you get into Flutter, you'll actually use them quite a bit. And it's just an elegant way of saying, hey, this is actually going to be this. And I just want to test this. I want to actually move this around. So you notice how we've actually got it backwards? In the compare statement, it's apples then oranges, but we're actually seeing oranges than apples. This would normally throw an error in other languages, but should run just fine and it does. So that is also why you would use it. If you don't want to use an ordered list or an ordered list of parameters. So more information, go out and read the official documentation in optional parameters. And you can see how when calling a function, you can specify name parameters, et cetera, et cetera. Definitely read up their documentation. It's well worth the read. I know it's a little bit lengthy, but I can't possibly cover everything in these videos. If you found this educational entertaining, the source code will be out on the website. You can just click for the link out to GitHub. And there is a Voidrums Facebook group with I think 1700 other programmers out there. All walks of life. We can definitely help you out with any issues you come up with. Unfortunately, I get just an extreme amount of email. I've actually had to make a separate account and hide it from the world just as I couldn't do anything with it. So don't email me. Go out to the Voidrums Facebook group and go out to GitHub and get the code. I'll talk to you guys later. Thanks.