[MUSIC] Throughout the course, I've seen a lot of comments in the forums about how this course wasn't what people expected, or it's not what they wanted, or it's not teaching the right things. This isn't a course on programming. Right, this is about computer science. And computer science and programming aren't the same thing and so on and so on. Well, I totally agree. This was not a course on programming. I believe I said that in probably one of the first videos in the course, okay? But does this not have any relevance to programming? Well that I think is completely wrong, okay? So, I want to talk in this video about software development. And thinking about how the principles that we've taught you, in this class, apply way beyond these simple kind of toy programs and are really critically important as I develop larger pieces of software. Now as a motivator here I'm going to use Skulpt, okay. And Skulpt is the heart of CodeSkulptor. It's the Python execution engine that runs inside of CodeSkulptor. It's a reasonably sized piece of software, I'd say it's probably, I don't know, about 20,000 lines of code, so it's not enormous, but it's also not small. Okay. And the principles behind how Skulpt is developed are pretty much the same principles that we've taught you here. So, let's take a look. [BLANK_AUDIO] So if you think I test CodeSkulptor by, you know, writing some code and then running it in the browser and seeing what happens, you're very sadly mistaken. This is not the way to approach testing. Testing is a critically important activity that is an integral part of any software development, alright? You have to do it in a systematic way, okay. And so you can see here we actually have code that runs our test. So there's a non trivial amount of code here that actually drives our test infrastructure and runs the test automatically for us. Okay? And tells us what's passed, what's failed, what's happened. All right? And this is really important. This removes any barriers the actually running the tasks, okay, so that you can basically very easily run the tests at any given time and have an understanding of, you know, how your program is running or how Skulpt is doing at the time, okay? So then the question is how many tests do we have? All right, do we have four or five, six tests, all right, and we just run those and we say hey, Skulpt works. Yeah, no, okay, all right, here's our test. First thing I want you to to recognize right, it says first thing is a, sorry, we had to truncate this directory to 1,000 files, right. We left out another 1,200. All right. So there are 2,400 test files here, okay? You have to write lots and lots and lots of tests, all right? And, you know, you can sort of see here that this just goes on and on and on. And actually, in Skulpt, we have a policy that you cannot push new things into the repository, the bug fixes or new features without writing a test. Okay? Well, why? Okay, you need to write a test that shows that the current behavior of Skulpt is broken, and that your changes actually fix that behavior. Or make it better or whatever, all right, and that allows us to understand that your changes are actually doing what you say they're doing. All right, and you have sort of this verifiable proof that hey, the behavior was wrong before, now it's correct. All right, that's one thing. The second thing here is you'll notice, you know, that we're looking at tests here that are four years old or five years old, right? These tests never go away. These tests document how Skulpt is supposed to behave. So when you actually submit your new feature, your new bug fix, okay, not only do you have to pass the test that you submitted, you have to actually pass all of the tests. And this guarantees that not only did you improve the behavior on that particular feature, you did not ruin the behavior on anything else. Alright, once something works, the test stays. And we know that no new changes are going to actually break it because we won't allow them to, alright? We're going to run the test and make sure that, we continue to have correct behavior from before. Alright, so testing is an integral part of any software development project whether it's small scale, medium scale, or large scale. And you cannot do it haphazardly, you have to have a systematic approach here where you're very disciplined in writing tests, and actually running the tests. [BLANK_AUDIO] So I'm sure many of you have been cursing my name throughout the course because you're unhappy with the coding style and standards that we have demanded of you, right? Now, I want to point out, this is not a trivial thing, this is very important. Alright, Skulpt started out as, you know, just a project by you know, one person, and then it grew to a couple people, and you know, lately it started to get larger with lot more contributors, alright. And when you're working by yourself it's very easy to say hey, coding style doesn't matter, I'll just do whatever i want, I pretty much follow my own consistent style. And it goes to, grows to two or three people and each of them have their own style and their stuff, you know, starts to pervade the code, a little bit of this, a little bit of that. Then all the sudden, you have 10 people working together. And nobody is following consistent style. And what do you have? A big fat mess. Alright, so I want to show you an example of how this, you know, sort of mess propagates here. Alright. If we look at this function here. This is how we create floating point numbers. Alright. First point you see that there's no consistency of indentation. Alright? There's no consistency with how we use brackets, alright. And basically this piece of code is significantly harder to read than it needs to be. Okay. And let me show you another example. Alright, now maybe you're going to argue, hey, I could, I can get it from that. But let's look at this, this unary op function here, okay. And let's specifically look at this region of code right here. Okay, it is very difficult to understand what the indentation is suppose to mean here. And worse than that, I have a variable named v. I don't know what that is. Alright, but I've got vop, maybe that's an op on v, alright. Then who knows what else clause is associated with what, and which if you know, goes where, and so on, all right, and so basically this has gotten out of hand here. And recently the, you know, people involved with Skulpt have decided that this is as, effectively untenable, alright? It's very difficult to understand what's happening here. It's very difficult for new contributors to be able to read the code and see what exactly is going on. And so then we've started to go through the code and clean it up systematically. It is much better. To just start with consistent standards from the beginning and follow them slavishly so that you end up with consistent looking code that's easy to understand. Then to have a big, giant mass of, you know, 20,000 lines that are all jumbled together and look different. No matter which file you open up, every file looks slightly different than the other. And, even within the same file, the code looks slightly different than the code right above it, okay. And this becomes a problem really fast. So, you need to think about this and you need to think about following coding styles, coding standards, all right. And, even when you start a small project, hey it might live a lot longer than you think it will. So, it's still worth the effort. [LAUGH] So I can hear a bunch of you, out there, going, hey, he doesn't follow the style guidelines that he's making us follow. All right, well I have a couple of things to say to that, all right? First, Skulpt is written in JavaScript, and not Python, and so you can't really expect everything to carry over. Different languages have different conventions for how people just sort of approach coding and how they approach the style. Right, so that's one thing. But it goes beyond that, all right. Skulpt is you know, developed by a group of people. It's not just one person, all right? And pretty much the code that you're seeing in this video is mostly not written by me, all right. So, other people have different notions about what constitutes good style. And as I said, right, there really hasn't been solid style guidelines in Skulpt. And we're, you know, now basically saying hey, things have gotten big enough and they've gotten out of hand enough that we really need to start imposing style guidelines. And so, style guidelines are being developed and things are going to be changed to conform to those style guidelines. Now they may not be the exact style guidelines that you are being forced to follow in this course, but the principles are the same, alright? The style guide guidelines are meant to allow the code to look the same and be consistent across the code base so that other people can look at it and understand it. And then the specifics of those style guidelines are less important than, you know, the ideas behind them and that they're followed well. [BLANK_AUDIO] Another thing that I've heard from students is I don't need to know any math in order to program. [LAUGH] Hogwash. You need to know math, all right? You can get away with not knowing math in writing basic programs, okay? But, once you try to do interesting things, you're going to have to understand some mathematics, all right? May not be exactly the mathematics we've taught in the class, but, you're going to have to not, you know, shy away whenever math rears its head, okay? What are we looking at here? Well, Python allows you to support, you know, big integers. That means an integer as large as you'd like it to be. Okay, so computers have limitations on how big they can, how big the numbers they operate on can be, alright. But Python does not. Well, somebody's going to have to implement that, alright. Take a look at this code here. Now I would argue that does not conform to any kind of style standards and that's bad, but even if it did, it would still be complicated to understand, right? Because there's some sophisticated mathematics going on here, alright? And you need to be able to understand that mathematics and to try and implement. You know, these useful features of the programs that you're trying to develop all right? You say okay, well, you know, that's one example, I don't want big integers so, you're just, you know, making this up. [LAUGH] That this is going to appear, no. You're going to see this in many pieces of software, especially things that are just not trivial, right? Once you, you know, sort of exceed a certain threshold of complexity, math becomes critical. So let's say okay, forget about big integers, what about the random module, all right? I've got to implement random numbers somehow. Computers don't just give you magically random numbers, all right? And so we've got to think about how are we going to do that. How are we going to make Python, allow and deliver random numbers in a way that's consistent with, you know, or how are we going to make Skulpt do it in a way that is consistent with desktop Python, all right? And here is just one of many functions that help to do this. Again, not really following good coding style or standards, alright, but I think you get the idea here, the math behind this is tricky. And you need to be able to think about it, reason about it and understand it. Okay, in order to do this correctly. Alright, so you can't get away with saying, I'm just going to be a programmer. I don't want to know any math, so I'm not going to learn any math, I don't need any math. You absolutely need math. [BLANK_AUDIO] Now, if you think that the 20,000 line Skulpt program just popped out of nowhere, right, somebody sat down and wrote 20,000 lines and voila, there's a Python in runtime system. Yeah, you're again [LAUGH] sadly mistaken, okay? The sort of incremental development process that we've been advocating throughout this class is critically important. Each mini project will give you sort of phases of development. And we suggest hey, maybe you want to try this first and then move onto this and then that, okay. This is important, all right? Skulpt was developed this way as well, right? There was a base that was built first, okay. I need to be able to get some minimal features built. And then once you have these minimal features built you can then start thinking about how do I add things on and as that happened, all right, the tests. Were written along with the code as I mentioned before, so that we have a working core of Python that's tested. That we know works and then we can add features. And as we add those features we test them, and then we can add new features that build on those old features and we test those and then we add more new features that build on, you know, all of the existing features, okay? And by following this incremental development process, it allows the software to grow. Alright? And you grow correctly, right? As you add things, they continue, the, the software continues to be correct. And you add more correct features. So that it builds up a working body of software, rather than writing a lot of software that doesn't really work and then testing it all and then trying to pound it into shape. And then writing another bunch of software that may or may not work and, you know, trying to glam it on to the existing stuff and pounding that into shape as well. Okay, that is not an effective development process. You want to take the things that we taught you here. And as you work on bigger and bigger programs, you want to keep that discipline, alright, that you've learned here to do, to write small pieces of code, test them, write more small pieces of code, test them, build up a working piece of software. [BLANK_AUDIO] All right, I don't want this video to get too long. So these are some representative examples of how the things that we've taught you in this class apply to, you know, real software development, okay? The things that we've done in the class are not just toys, all right? They're small scale examples of the real principles that you should use as you go forward in your career as a, you know, programmer, software developer, computer scientist, or just hobbyist, whatever it may be, okay? If I wanted to I could pull out more examples about how, you know, we use recursion, how we use common [UNKNOWN], alright, why abstraction and encapsulation are important and you don't just reach inside of objects. Okay, and hope for the best, alright? That you build these, you know, useful abstractions and you stick to the interfaces when you use them, alright? These things are all critically important. These things are all fundamental principles of computing that apply, you know, across, you know, types of software development, are not just educational toys, okay? So I hope that you've sort of enjoyed looking at a little bit of JavaScript here, and peeking under the covers of Skulpt. And understanding that, you know, the concepts that we're teaching you here are driven by our you know, philosophy on how you would develop software in the real world. And what it means to be both a programmer and a computer scientist. Alright, hopefully when you take these things away from this class, you know, you will be able to apply them. And you will feel that, hey, what I've learned here is actually very practical. Very valuable. And has made me better at these things.
