It's summer, so it must be time for Phil Jepixie to come on Toolbox for another series. This year, we're really going to test your patience. Hi, welcome to Visual Studio Toolbox. I'm your host, Robert Green, and joining me today is Phil Jepixie. Hey, Phil. Hey, Robert. This is now becoming one of my favorite summer traditions. Absolutely. You come in and we do a series of episodes. Yeah, look forward to it every year. Last year was design patterns. Yeah, we got nine of them, I think. Nine of them, I think, and great episodes and a lot of great conversations. This year, we're doing unit testing. We are. Not only how, but why. Yep. Right? Focusing, I think, more on the how in the later episodes. But I think in this one, we want to set the stage of why it matters. Yeah. I hope we don't just spend too much time explaining why it matters, and that we get to focus more on the mechanics of doing it. Okay. Particularly, we're going to look at, well, Kendra Havens and I did an episode a few weeks back on unit testing tools inside Visual Studio, but we're going to go more about how you do the unit testing itself. We'll look at x-unit and n-unit. Mock you. Mock you, and I also want to talk about how you get started doing more with unit testing, given that in all likelihood, you've got an existing code base, right? So we want to talk about that kind of stuff, and as always, want your feedback. Last year, we had some great conversations with folks not only who liked what we said, but some folks who disagreed with what we said, which is awesome. We expect that. We encourage that. Look forward to the conversation on unit testing. It's something that's fascinating with the patterns series. This isn't mechanics where everybody does exactly the same way. Right. It's more of an art than a science. So I am not saying that the way that I do it is the ultimate right way. It's the right way for me. Right. And that's how I've been doing. I've been doing unit testing ever since, really ever since any unit came out with .NET, and manual testing before that. So for people who maybe feel like they're not doing enough testing, that's what this series is for. If you're absolutely totally doing it and you just want to watch to figure out how you can maybe improve or how you can suggest that we do it better, that's great. But we're going to focus on, I don't write enough unit tests. I don't think anybody does. Yeah. I mean, I mandate that my teams write unit tests around their things, and I mandate that I write unit tests around my code, and it's still not enough. Right. Things come up. You have deadlines, you have, you know, it's just software development, right? Things come up. Right. And then there's always the, are you spending time writing features, or are you spending time writing tests? Right. There's, it's true, but it's not true, this dichotomy of the time, the feature work versus other. Right. And, you know, are you being paid to write the feature, are you paid to write the test, and you've got something due Friday at noon, it's now Friday at 10, you finally got the feature working, right? What are you going to do in your last two hours? So I would argue that both of the statements are wrong, what you're getting paid to do is deliver value through quality software. Right. Right. And quality software is tested. It is working. Yep. One thing to stress though is that with unit testing, and what we do as developers, we're actually testing the code to make sure it behaves as we expected to. Right. Which might be completely different than what the customer is expecting. Sure. You're not testing the feature, you're not testing that the feature meets the spec or meets what the customer thought, right? You are testing the code that you wrote, and then there's an assumption that you have coded to spec. But you wrote particular code that's going to do a particular thing, and that's what you're testing. Yeah. And I would, I would also argue that unit tests are part of your production code, it just doesn't get released. Right. Sure. So I know you've done some episodes with IntelliTest and some of those things. Sorry, I'm unblinding myself from some cables right now. I feel like I'm a bit of a kuzovine. One of the biggest things that I think people miss on in testing is scenarios, right? And when we were on last, we did an episode, kind of a whirlwind fly through episode on unit testing. We mentioned the Calculator app, right? Right, you know. And so let's switch over to code and look at some things and just to get set up. And I've got a bunch of projects here. These will be linked to in the show notes. They're all in my GitHub repo. But I've got this project here, Channel 9 kickoff. And I just want to show you what I have installed. This is my standard load, if you will, for unit testing. Now this is an ASP.NET core class library. It could also be full.NET framework. These things work in both. So we have MOQ, which is a mocking framework. And we're going to talk in great detail in a later episode on that, but I want to give a little show and tell of that. So again, the idea of mox is that if you're calling a service or you're calling a database or something, you want to test the code without having to test the connection to the database or without having to literally connect to the database in your test. So the nice thing about mox is you can say, assume I called the database or the service and it returned to X. Now, what do you do with that? And there's a couple reasons for that. First and foremost, it brings code isolation. So I am literally only testing my system under test. If I'm expecting a certain behavior from my code, let's say I've got a repository, it brings back a list of customers. And I want to test, how do I handle the controller if I get no customers back? Well, if you're actually connecting to the database, then you have to delete all the customers in the database to run that test. Well, now I want to test what happens if I bring back a million customers. Well, now I have to add a million customers in the database to run that test. And now I can't have both tests passing, without a bunch of work. So we want that isolation. The other thing is flat out performance. If I'm not testing the actual data access layer, but I'm testing something that depends on it, connecting to a database and doing those retrieves or populating records takes time. Yeah. And if you've got a thousand unit tests, you don't want to use up all your Azure minutes just running the test. Yeah, also it takes resources, it's spinning the meter. Yeah, absolutely. So we're going to talk about that. X unit is a framework that I prefer to use these days. James Newkirk and Brad Wilson were instrumental in N unit. And this is, for lack of a better term, I'm sure somebody's going to put something in the show notes and not like the way I say this, but I think it's a next generation of unit testing libraries. There is a lot of things in N unit that work great at the time and I was a big fan of N unit for the longest time, but we've learned, we've evolved how we do testing. Some of the changes, for example, in N unit, you can do an expected exception attribute, which says anywhere in this test, if this exception gets thrown, then the test passes. Well, what if that exception is getting thrown in your range part of your test, you never call the system under test. Should that test really pass? The answer is no, right? Cause we wanted to actually be thrown at the right time. So there's some things that were dropped out of or not ported, sorry, rewritten in X unit that we've just learned over time that have become kind of anti-patterns in the way we use to do things. And this is not knocking the creditors then unit. We learn, we evolve, we adapt, right? And then the X unit.runner.visualstudio just enables us to run X unit tests in Visual Studio through the test window. And there's also team city support and resharper support and things like that. Today I'm going to be showing the Visual Studio test runner, because I know we want to focus on things you don't have to pay extra for. Plus it is Visual Studio Toolbox. Well, yeah, good point. Thank you for correcting me. So we got a couple of things in here. I've got some existing code. And I know one thing that we wanted to talk about is how do you get started? How do you be more effective in writing your unit tests and what should you be testing? But also you've got legacy code, right? And legacy code as in code that you're working on that isn't under test. And how do you deal with that? Well, the same way you need an elephant to use a cliche is one byte at a time. I don't wish on anyone the requirement to go, okay, you've been developing for six months, now everybody stop moving the ball forward and let's write tests for six months. That doesn't do any benefit. So we'll talk more about the patterns about that. But I know that one thing you wanted to talk about is scenarios and how to cover different scenarios. An N unit and MB unit and X unit are all custom built to handle this. MS test, it's a little more difficult so we're not gonna cover that today. So let's say that we're gonna use a canonical example of the calculator because it's easy. And so we're gonna do test driven development. We're gonna write the test first to use that to drive out the API in the code. So let's say I have a test that is called should add to numbers. And that's going to be, let's do our, do a little old school and explicitly call it out. When we talk about unit tests and we really have a range act and assert. So a range is going to set up anything we need to run this test. The assertion is we're executing code on the system under test. And then the asserts are making sure that it behave the way we expect it to behave. You can only have one act, that's pretty much canon. You don't wanna have more than one action going on that you're testing. And that's, I think our listeners and viewers will agree that's accepted. There is some discussion in the world as to whether we should have more than one assert. I am of the mind that you can have as many asserts as you need to prove that your action was correct. But we will have some people who will probably chime in on the boards and say you should only have one assert. I'm not saying that's wrong, I'm just saying that's not how I do it. So let's arrange, and usually this is setting up any variables we'll need. We'll get more involved when we start talking about mockings. But let's say int add end one equals five and int add end two equals 10. And then we have to create a new instance of the calculator, and we'll call it system under test or SUT. And that's new calculator, which doesn't exist. So we're gonna use the Visual Studio Refactoring to actually create and type calculator. And we would do it in a separate file, but just for demonstration purposes, we'll keep it in the same. And then we're gonna act. So what we want to do is say var result equals SUT.add and we're gonna pass in add end one and add end two. We don't have an act method or an add method, so we're going to create that as well. And it's gonna return an int and it takes two ints. And then we would assert that equal, we have expected, which is 15, and that equals the results. Now if we run this right now, the test will fail because we're gonna get an exception. And if we're doing strict TDD, we would run the test. This is really the obvious implementation. We don't have to run the test at this point. But what we want to do is write the bare minimum amount of code to make the test pass. So we would return 15. Okay. Right? Because that'll make the test pass, correct? Let's... So let's stop here for one second and let's chat about what we're doing. We're, test-driven development says you write the test first and then you fill in the actual functionality. So at this point, you haven't actually written the add method. Correct. Well, I have, but I've hard-coded it. Right, so you've hard-coded it, but that's not anything resembling what the real add method's gonna look like. Correct. And you've got a passing test because you hard-coded it to be equal to what your bogus add method returns. Yes. So I'm gonna play a little bit of devil's advocate here. What have you accomplished? What I've accomplished is I've flushed out an API. I have an add method that takes two numbers. That takes two numbers.  I do because it's a very simple or what we would call the obvious implementation. But what if it was something much more complicated and took in a couple interfaces and the logger and had call-outs to other things and we weren't sure what it was gonna do. So that's really, we need to, we consider this a cata. You ever studied martial arts? Wax on, wax off. So you repeat the same thing time and time again until you get good at it and then you start combining things. So in real life, I would never say return 15 because this is so obvious. I would say return add end, add end one plus add end two because it's obvious that's what add should be. But there are many times when you're doing this where it's not obvious. What about the cosine function? Or better yet, I did time and time, felt like it. I worked in insurance for a while and we were working with actuary tables. And that really did come, you're taking 27 parameters into this annuity calculator and I took the first row and I'm passing all these things in and the last cell in that row says this is what it should return. So I literally hard coded it to that just to make sure I had the API right? And I was passing in all the right things. So you can, sir, is it safe to say that the test it's actually part of the specking? It is. Okay. It is helping you define the API. Okay, so there's the speck in terms of the feature and now what you're basically doing is specking the code you're going to write. You have an add method that's going to take two parameters in and then you're specking what it's supposed to return and the various scenarios of what it could return and how it could act. It's really how it could act, not so much what it returns. You're specking how this method's going to act. What happens if you pass in zeros, right? It's a divide. What happens if one of these is a zero? What happens if something doesn't get specified correctly? What happens if they do get specified correctly? Is this thing going to do the thing it needs to do? So you can kind of think of the test you're writing as the speck of the code you're ultimately going to write and you do it kind of in parallel. Was that fair? That is fair, although you jumped the gun a little bit because we don't have any scenarios in here yet. Right. Well, we have one scenario. Right. We have 10 and five. Okay. We need to add more scenarios to make it a complete test. But I'm just trying to answer the question. But absolutely, what you said is correct.  Why are you doing that? And the answer could be because you're specking, you're helping to speck what you're ultimately going to write. And you're also writing your unit test while you do it. Right. And so a side effect benefit is, now I have tests to cover my code. Right. Right, but we're really driving out. And maybe divide would be a better one to do. Let's switch it. Do a little clipboard inheritance and we'll say should divide two numbers. I don't know my math, but one of them is a divisor. Right. Okay. And then we want to build out that. And this is actually going to return add end divided by divisor. And this should be, my math is right, point five. So let's look here and test explorer and we have all kinds of tests in here already. Well, let's run these, see how far off the mark I am. That's something else I like using unit testing for is sometimes we make assumptions. And yep, look at failed. So the result should be, why would that be zero? Because it's an int, right? So I've already failed in driving out the API. Right. Because I'm returning an int. So I need to change this to return, we'll just say decimal. Okay. Right. Possible loss of fraction. I'm okay with that because I don't care. And then we'll run the test again. If you will run it from here with the visual studio. Right. And so we're finding all kinds of failures because I don't know how to do math. What am I doing wrong? What's it saying? It succeeded to click on this again. Don't make me run, I'm gonna run it this way. All right, so we showed how to not drive out an API. But more importantly, I think this is meaningful in that we're on camera, it's live. I did, well, I went off script with this and so I screwed up a little bit. But as we're trying to figure out how to write a divide function, what we learned is that rapid feedback show this, we're doing it wrong. As opposed to saying, oh, I can write divide, that's simple, right? I just do add in divided by divisor and I go on and later on in the program, they're expecting 27 from an actuary table. We're returning four. Now you have to chase always through the program. Where did I fail? Well, the fundamental problem is, I don't know how to do divide and C sharp. So we'll just, these are not the droids you're looking for and we'll skip over that, but it does show how to drive out the API. I initially said an int in there, but then it came back and said, no, you're wrong. And I learned that early, it's all about the rapid feedback. Let's talk about scenarios. What we can do in N unit, NB unit and X unit, the methods are different, is we can do scenario-driven testing. And in X unit, we do that by writing a theory and then we can do this multiple ways and we'll show this in the next episode to do this, but the simplest way is with an inline data and it takes a list of params. And so we will say add in one. Actually, it takes the actual numbers. So we're gonna replace it with five, 10 and 15. And then what that does to our test is it now parameterizes the test. So add in one, int, add in two, and then int expected. So we don't need these anymore. Our arrange is actually done through the inline data, the first part of the arrange. And now when we run this test, we see that it passes. Okay. So now instead of having to clipboard inherit a whole bunch of tests to add different scenarios into it, some of the ones that you said is what if they didn't put a number in? What if we said that's null? Well, now we have a problem in that we have to make that nullable. Now we won't compile because it's not accepting a nullable int. So now we're driving the API. So we go down here to our add function and we're gonna make that one nullable. And now we have a problem in that adding those two numbers doesn't work. So now we have to fix our code. So we've solved that problem of, hey, if you're not adding, again, from a logical standpoint as a developer, we would never think of doing that. If I'm adding two numbers, that means I have two numbers. But maybe they just type in one number and hit Enter. So you're actually kind of forcing yourself to do this type of design up front, right? How is this going to be used? And perhaps more importantly, how is this going to be misused, right? And then ensuring that you cover that in the code. So rather than write the 90% case first and then having to go back and say, oh, well, what if somebody does this? Oh, what if somebody does that? Oh, what if somebody does this? You're getting all of that taken care of more up front so that it's covered, which then early on, not last minute at deadline, you're now thinking about the edge cases or the 10% of scenarios where all your errors are going to come from and you're handling that up front. So, yeah, it's more time up front, but it's then paying off big time down the road because you've already got it covered. Correct. And built into the API. So we can fix this by using the Elvis operator and doing it on both and we're like, okay, if they can pass in one that's null, they can probably pass in two that's null, right? So let's just add in the Elvis operator and see if that fixes, of course, our expectations have to be correct and run this. And what we will see in the test runner is that actually shows up as two different tests. So we expected 15, the actual was five, we passed in five and 10 and 15 and 10. So what I am showing here is again, my lack of knowledge around C-sharp by doing this wrong. So I had an assumption that adding in question mark, question mark would fix the problem. However, it didn't. So the problem's not in the assert because you're expecting 15? The problem is in the assert because I didn't change the test. That's a joy of life coding. So we've got the one with the null working, but the one with the five and the 10 bringing back 15 didn't work. So then we would go through and debug why it doesn't work. I mean, it doesn't matter whether or not this example works. The point is that as we add these different scenarios, we're flushing out the code to make sure that it returns the right thing. So obviously we want to fix it, but let's talk about another scenario that as developers, we would probably never think of doing. But I was putting question marks there. What happens if we add int dot max value and 10? Right. Right? We don't know what the expectation is, so we're gonna put something in there anyway just to make it fail. And I'm actually going to get rid of this test. Get rid of the divide so that we aren't occluding what we're trying to show. What happens when we run this? We know that's gonna be a failing test. Right. And max value plus 10 does not equal five. It's infinity plus 10. Well, actually I think it's int dot min value plus four. Right, it's not exactly infinity, but. Right, so we ended up with that. Right, so now we can start with very little effort on our own, adding in all these different scenarios to really flush out. And more often than not, you're gonna put in every scenario that you think of, and then users will get ahold of it, and they're gonna do something different, and you might get a bug report saying, hey, the calculator didn't work. Right. Well, how do you re-pro the problem? Well, we just started hitting numbers and it ended up being int dot max value plus int dot max value, and we got something weird. Right. Well, now we can start putting checks in there. Well, maybe we don't allow them to add a number bigger than a million. Right. Or we then find out what the reason is, we update the code to make the test pass. Once the test passes, we put that failing condition in as we have here, and then we flush out to code to make a pass. Yep. Okay. And then it drives the conversation of, do you handle that in the calculator or the UI? Right. Right. You might, as guidance have in the UI, make sure you don't enable this, but if someone does, then the calculator needs to handle it somehow. So you're really, again, you're driving, it's less, you know what code you're going to write, ultimately, but you're really driving much deeper thinking about how the whole system works and heading off a lot of issues at the pass because you've covered them and you've thought to cover them ahead of time. So again, one of the benefits of doing it this way is you're not only testing the code you write, but you're helping yourself design a much more robust system as you're writing the code. Correct. And so let's change the tester on a little bit and it comes back from the business that says, they have to put in two numbers. We can't allow them to do null, but they might put in a null, but we have to handle that exceptionally. So I've just changed the code and I'm doing this a little backwards. I'm doing the test eventual development here. I changed it to throw an exception if either of these are null. So then what we want to do is add a different test to handle those exceptional cases. And let's get rid of those. And so if it's null, we actually want this system to throw an exception. So I have my new calculator. I'm gonna call add, but I want to handle this a little differently and I'm gonna combine my act and my assert. The computer wakes up. And we have a special case where we can say assert.throws and we can specify the type. And that's an argument null exception. We're gonna time? No, we're at 30 minutes. Okay. So we will finish up here quickly and then prep for the next episode should not add nulls. Make that more meaningful.  If the exception gets thrown, then the test passes and it passes. So we had the exception. Which again, drives the decision of when do you want APIs to purposely throw an exception versus just return in some error code of negative one, if it's a connection issue or whatever. You probably never want calculators returning numbers because that's what they're supposed to do. Numbers as an error code. Right. So here you probably do want it to blow up and then the person calling it gets an expected exception because they violated rules. But again, you're driving that discussion. And that becomes a business decision to how you want to handle that. Cool. So here's our little intro. Let's get ready and talk about XUnit in great detail. All right, so that'll be in part two. Thank you for listening and watching. Watching. Hopefully people are watching. They're probably heads down working with a plane in the background. All right, we'll see you next time on Visual Studio Toolbox.


Hi, my name is Quinn Brinicki. I am a pastor at Prairie Street Mennonite Church in Elkhart, Indiana, and I am a Masters of Divinity student at AMBS. At AMBS, I'm digging into the roots of Anabaptism and discovering what this 500-year-old story has to offer to the global church, even here in Elkhart, as we face different challenges and many different contexts. Please consider giving today, if you can. Anything you give today through December 1st will be matched up to $50,000. Your generosity can make theological education and an Anabaptist perspective accessible to leaders around the world and here in the United States and Canada, rooted in the word, growing in Christ.


Greetings and welcome to the Introduction to Astronomy. In this video we are going to continue talking about stars and are going to specifically talk about the spectra of stars. Now a spectrum is what happens when we take light and split it into its component colors. And this would have been discussed earlier in the course if you need to go back and review previous videos, but we can use the spectra of stars to be able to determine many properties of a star that we would otherwise be unable to determine. That would include things like their sizes, it would include their compositions, and it would include their velocities that we will talk about in this lecture. But first of all we really want to look at how stars are classified and organized based on their spectra. So getting started with that, what we find is that we do classify stars by the appearance of their spectra. What kind of lines do we see in the spectrum? And the reason that stars will show different spectral lines has nothing to do with their composition. Their compositions are all essentially the same. They are primarily hydrogen and helium, and very minor differences will say that will tell us anything else about them. So what we will see is that all stars are made primarily of hydrogen and helium, but there are differences, and those differences have to do with the stars temperatures. So the lines that are visible do depend on the temperature, and let's look at the hydrogen line for example. This graph here shows how strong the hydrogen line will be versus various spectral classes. In spectral class A it would be the strongest, but it would be very weak in a class M or a class O. Now we'll talk further about those classes later on, but let's just look at this for right now. The reason that we do not see the hydrogen gas if we look at a class M star or a very cool star, we don't see the hydrogen lines because the cool stars are not hot enough. They are not hot enough to excite the hydrogen gas and cause it to glow.  The hot stars will ionize the hydrogen. Hydrogen atom has one proton and one electron. If we rip off that electron it has nothing to form spectral lines with, so for very hot stars we will not see hydrogen lines either. However, that does not mean the composition has changed. All of these stars of whatever spectral class have the exact same composition. They are mostly hydrogen and helium with the trace of other elements. The tracing of other elements is a very minor difference between the stars. It can be important, but it is very small. It does not change the fact that every star that we look at will be mostly hydrogen and helium, and in fact 99% of the atoms in any star will pretty much be hydrogen or helium. It is those stars that are right around 10,000 degrees that are the best at exciting hydrogen and therefore give us the strongest hydrogen lines. When we look at other things like helium, helium is harder to excite because it requires higher temperatures, so we don't begin to see neutral or ionized helium lines until much hotter stars. Other things like metals, and I should say that a metal to an astronomer means anything other than hydrogen or helium, they do not appear in these very hot stars. Again, they've been very heavily ionized at those high temperatures, so they don't produce lines. But when you get to cooler stars they are at the proper temperature to excite them, so ionized and neutral metals are then visible in cooler stars, and in the very coolest stars we begin to see molecules. Molecules like titanium oxide here could not be present in the high temperatures of much hotter stars. So the spectra that we see, the spectral lines tell us about the temperatures of the star. Now let's look at how these were classified, and they were originally classified by Wilhelmina Fleming back in the 1880s. She did the original classification and the first thing that she looked at was the hydrogen line. That was the most prominent line in many stars, so she classified them this way and said that the classes with the strongest hydrogen lines were class A, then class B, and so on down through the alphabet to very weak hydrogen lines would have been classes M or so. However, this was only based on the appearance of the spectra. It had no physical meaning, and a decade or so later Annie Cannon actually came up with a better way to do this. In the 1890s she rearranged the classes that Wilhelmina had come up with and reclassified them to be based on temperature. So we use the original classes that were developed back in the 1880s, and you can see some of them here, A's, B's, F's, G's, K's, M's, and O's. However, they were changed and reordered to be based on temperature, so that the hottest stars were the O stars, and that the coolest stars were the M stars. So the classification, as we see here, became a classification of temperature with very high temperatures up here at the top, very low temperatures down here at the bottom, and this table will tell you what you would see in each of those classifications. So you'd see helium lines very strong in the hot stars, hydrogen in the intermediate stars, metal things like calcium and sodium in the intermediate and slightly cooler stars, and then molecules beginning to appear in the very coolest stars. So everything was reclassified to become temperatures, and that is the basis of the classification used today. Now we have added some new classes as new discoveries have been made, so we can look at some of those, and the new classes become the Wolf-Rea stars, which are class W. These are extremely hot stars with emission lines, so actually giving off, having brighter lines rather than dark lines, which are associated with most of the stars. We see class C and S, which are the carbon stars, and these are red giant stars that have excess carbon in their atmosphere, and perhaps later when we look at videos on stellar evolution, we can see how that might happen as carbon that is being formed in the interior can be dredged up to the surface, enriching their surface in carbon more so than we would normally see. Now what I really want to look at are the classes L, T, and Y stars. These are what are known as brown dwarfs. They are cooler than the M stars, and so they would be down at the edge of that sequence that we looked at, down at the very end of that at the very coolest stars, and at those point dust begins to form in the atmosphere, so you're getting cooler and cooler, not only forming molecules and more complex molecules, but actually beginning to form small dust particles. So what is a brown dwarf star? Well let's take a look at this. If we look at stars with a mass less than 0.075 solar masses, they never become hot enough to be able to fuse hydrogen to helium in their core. These are what we call failed stars or brown dwarf stars. They can fuse deuterium. Deuterium is an isotope of hydrogen, which has one proton and one neutron in its nucleus. So this is the distinguishing factor between a brown dwarf and a planet. So a star is able to fuse hydrogen into helium, a brown dwarf star can fuse deuterium, and a planet is unable to fuse deuterium, so that's how we can classify these things. Anything greater than 0.075 solar masses would be classified as a star. Anything between 0.075 solar masses and about 13 Jupiter masses would be classified as a brown dwarf. Anything less than about 13 times the mass of Jupiter is then classified as a planet. So sometimes we consider Jupiter being so large that it's almost a star. It's not even close. It would need to be 13. We'd need 13 Jupiters put together just to get Jupiter into the stage where it would be classified as a brown dwarf star and many many more Jupiters to get it to the point where it would actually be a star. If we took all the mass of all the other planets in the solar system and include all of the other objects within our solar system other than the Sun, we would not even have one more Jupiter mass. So all of the material left behind is not close to being able to make Jupiter even a brown dwarf, let alone a star. So let's look at what we can determine by measuring some of these properties of a star. And what we find is that stars come in a wide variety of sizes. There are extremely tiny stars that we'll look at later. But just looking at ordinary stars, typical stars can be much smaller than the Sun. So if we look at some of these here, here is Jupiter in this figure in number three here. Jupiter is there. We can have a very small star like Wolf 359 which is a small red dwarf star significantly smaller than the Sun. In fact much closer in size to Jupiter than it is to the Sun. So there are very small stars but as these overlap you can look as we've gone through go through the scales here. This is Jupiter and in the next scale we scale down to make Sirius a very small star and look at even larger stars and we get into red giant and red hypergiant stars. Things like Betelgeuse here is a very large star and Vy Canis Majoris is the largest known star. These are many many times larger than our Sun. So you can see how big our Sun would be there. This is Betelgeuse. Betelgeuse compared to something like Aldebaran. Aldebaran would be this small but Aldebaran compared to Sirius would be this small and Sirius is significantly bigger than our Sun. So many of these stars are many many times larger than our Sun. So let's look at what we can determine. How can we determine the size of a star? I've shown you some of them here but how could we actually determine that? So we'll take a look at those here. First of all we can use the spectral lines of a star to help expand our classification. So large stars are more spread out and have a lower density and the spectral lines will therefore appear to be more narrow. So we can see differences there just in looking at the spectral lines. A very large star will have very narrow spectral lines. A very small star will have a higher density and therefore much broader spectral lines. We will also see differences in ionization and how many electrons have been removed from various atoms. The lower density and the large stars, the ions are less likely to recombine and will give us a slightly different spectrum. And based on this astronomers have made five luminosity classes to go with the spectral classes that are used. There are the primary three, there are super giant stars class one, giant stars class three, and dwarf stars class five. This is most of the stars that we will see are dwarf stars. Our own sun would be classified as a dwarf. Now just because something is classified as a dwarf does not necessarily mean it is small. It's simply referring to the luminosity class based on the spectrum. But what we'll look at and what we'll look at in other lectures are super giant stars, giant stars, and dwarf stars. We really will not go into the other two in this class. So let's look at how we can use this to determine sizes by looking at the spectrum. Now how can we use it to determine abundances? What are the stars made up of? Well, what we see is that the presence of absorption lines of a specific element shows that an element is present. So if we think about that, if we see iron lines in a star then guess what? Iron must be present in the atmosphere of the star. However, the converse is not necessarily true. The absence of absorption lines does not necessarily mean the element is not present. Because the temperature and pressure in the star's atmosphere will determine what elements can produce lines. A very cool star is not going to be able to produce lines of helium. But that does not mean that helium is not there. It simply means that the temperature is not correct to be able to excite them. What we see is that all stars have essentially the same composition. Ninety-six percent or more of the atoms in any star are going to be hydrogen and helium. Anything else astronomers will call metals. So anything heavier than helium is a metal called a metal by astronomers. So when you see that terminology about metals or metallicity that simply means the percentage of a star that is not hydrogen or helium. Now the other thing that we want to be able to measure are the velocities of the stars. How are the stars moving? Well, let's take a quick look at that. We can look at that. We can use the Doppler effect to measure the radial velocity of stars. But note that this is relative motion. Who is moving? Is it the earth moving towards the star or the star moving towards the earth? Is it the earth moving away from the star or the star moving away from the earth? We cannot tell that. All we can see is the relative motion of the two. If we are moving away, then that gives us a red shift. The lines are shifted towards longer wavelength. If they're moving closer together we get a blue shift that the lines are shifted to shorter wavelengths. So that's the radial velocity that we can see and we can measure that using the Doppler effect. However, there is also a transverse velocity which we measure as proper motion. This is very slow but is noticeable over long times. And we see in the image here, here is the big dipper as we see it today. However, 50,000 years ago the big dipper looks something like this. Nothing like it does today. You can see how it's been stretched out. And what we have in the big dipper is that five of the stars, these five in the middle, are moving in roughly the same direction through space. So their relative positions stay the same. However, the other two stars, the one on the end of the handle and the one on the end of the bowl, are moving in the opposite direction. So that 50,000 years from now this handle will have curved a little more and the ball part will begin to stretch out. It's not something that one will notice in a lifetime but over tens of thousands of years the appearance of the stars do slowly change. And this would be another velocity. This was what we would call the transverse velocity. So in order to find the true velocity of a star, we need to measure both of these. Both are important and both have to be measured by different methods. So if we combine the radial velocity, the proper motion, and the distance, we can then figure out the true motion or the space velocity of the star. The radial velocity here, whether it's towards or away from us, that portion can be measured by the Doppler effect. The transverse velocity can be measured by the proper motion and combining with that with the distance will give us a transverse velocity. And then if we can add those two velocities together, the velocity here, the radial velocity here, the transverse velocity, and when we add them together we can get the true space velocity of the star. Now the radial velocity is a lot easier to get because we just have to make a direct measurement. The transverse velocity can take time. We need to look at images, sometimes decades, or even a century apart to be able to see how that star has been moving. But together those will give us the true space velocity of a star through space. Now finally we want to look at the rotation of the stars. How can we determine the rotation of stars? We can also use the Doppler effect to do this. If a star is not rotating at all, then the light will be coming the same from whether it's from the edge or from the center of the star. However, if the star is rotating, the part that's coming towards us will be blue shifted, the part that's going away will be red shifted, and we will get a blue shift from one side of the star, a red shift from another, and that will broaden the spectral lines. So in a non-rotating star we'd get a very narrow, a very narrow spectral line. In a rotating star we would get a broaden spectral line. The faster the star is rotating, the broader the line will be. So the faster that we can determine something of the rotation by looking at how wide the spectral lines are. So let's finish up here with our summary, and what we find is that stars are classified based on their temperatures. So we use the OBAFGKM classification as how we determine different types of stars. New classes have been added since that was developed in the late 1800s for more unusual stars and for the more recently discovered brown dwarf stars. And the most important thing, the spectrum of a star that we need tells us about the size, the velocity, the composition, and the rotation of stars. So just by looking at the spectrum of a star we can determine a lot of things that would otherwise be very hard to find. So that concludes our lecture on the spectra of stars. We'll be back again next time for another topic in astronomy. So until then, have a great day everyone, and I will see you in class.


Hello, I'm Dr. Sunil Kini, consultant joint replacement and arthroscopy surgeon at Manipar Hospital's Bangalore. Immediately after knee replacement, we advise the patient to start walking the very next day after surgery. The extent of the patient walking is determined by the level of pain as well as the swelling. By the time of discharge, patients are usually comfortable walking in the corridor. They also can do a couple of steps by the time they are discharged. This improvement slowly occurs over a period of time to up to six weeks or even three months after surgery. The do's after a knee replacement is almost everything. So, the patient can be back on their feet, can do all activities including light work and after six weeks they can resume their most of the activities of daily living. In terms of people who drive, at six weeks would be the safe limit at which the patient can start driving as well. For patients who do stairs immediately after surgery by about two to four weeks, patients are comfortable doing a flight of stairs and this improves. By about four to six weeks after surgery, the patient can walk at least about half a mile and this improvement slowly is seen with progressive distance walking. In terms of patients who want to ride a stationary bike, six weeks to three months would be the time when patients can start to do so. A patient who want to play sport such as golf or doubles tennis, it will say probably three months to six months is the duration at which we start looking at. Swimming is also very good activity and we encourage patients who can do so to start at about six weeks to three months after surgery. The do's after surgery, the couple of things which advice patients not to do firstly is to a lot of impact activities such as a running or jogging which actually puts more strain on the plastic and the implant and subsequently there may be more chances of loosening and polyethylene wear. Also in the Indian patients we advise them not to use an Indian toilet because it requires a lot of forces on the plastic during deep squatting. Also a common question is whether patients ask whether they can sit crosslet on the floor. Although they could, we advise the patient that there are slightly more chances that the plastic wears off during this process and it's best to avoid if possible or only in certain occasions wherever needed.


So we're about to start our last talk for this session. We have Nothingness and Identity in Python by Daniel Procida, who was keynote speaker last year and has joined us again this year. So thank you very much and let's welcome him. Thank you very much. Thank you, of course, as usual, to the organizers for putting this on. It feels every time that we're being invited to a party that somebody wants to organize for their friends. It's a labor of love. I really appreciate that. So thank you very much, not just for the invitation, but for everything that you've done. It's really wonderful to be here. I'm going to have to rush through this because I only have a short slot and I have a lot to say as usual. So I'll jump straight in. So let me tell you a little bit about me briefly. I'm Daniel Procida. That's what I look like on television. That's how you can get in touch with me. But the best thing is just to come and find me and talk to me. I'm a Django core developer. I'm an ex-vice president of the Django Software Foundation, so I'm no longer on the Django Software Foundation board, which is something people forget, that I forget and the board forget, so it seems you can't get away. I work at DVO. We do cloud hosting for Python and Django and other things, but if you're interested in web hosting and it's giving you some travel, come and talk to me. Maybe we can. There's a better way of doing it. So the other thing that I'm really involved in that I want to tell you about is the very first PyCon Africa. I've been involved in, I've been attending African PyCons for several years, and this year we're holding the first PyCon Africa in Ghana, 6th to 10th of August. Please come and talk to me about that. Also, if you're interested in coming, sponsoring, I'm part of the organisation of that, and that's going to be very exciting. So here we are. This is a 16th-century fresco by Raphael in the Apostolic Palace in Vatican, and it depicts thinkers and scholars, mainly from antiquity. And here, at the centre of the painting, at the centre of attention are Plato and Aristotle. Aristotle, of course, was Plato's most famous pupil, and like every good pupil he felt obliged not just to learn from his teacher, but to respond to him too. And we have Plato pointing up towards the heavens in reference to a world outside space and time, one belonging to the pure forms that all the things in our material world are just a kind of shadowy copy of, whereas Aristotle points down towards the material world because he argues against Plato that form only exists as a form of actual substance, that knowledge and truth require us to generalise from the particular to the abstract and not the other way round that Plato goes. So these two directions of thought represent the single most important axis in Western philosophy, and the question for us is which of these directions do we prefer or turn to or choose to universal ideas and truths that lie beyond the world of the senses or to the actual world that presents itself at our feet? And, of course, you can't actually reduce Plato and Aristotle to something so simple as that. This is a very simple dichotomy, but this difference represents two, let's say, directions of thought, and you don't actually need to be a student of philosophy to recognise them. And people, given an opportunity to reflect on this, will usually recognise themselves in one of these two directions. Some of you will have intellectual sympathies that generally resonate with those of Plato, and some of you will have, find yourself thinking that Aristotle seems to represent the obvious way that our thinking should be formed. And most people seem to know which direction is there, as the Platonic or the Aristotelian, and I'm not saying necessarily that they believe in an ideal world of pure universal forms, but that generally they find themselves preferring to think in a certain kind of way. And you can also see this axis of thought as representing the two different directions taken by Western philosophy over the last 25 centuries. I started learning Python about 10 years ago, and I had a very memorable experience in my first Python lessons. It was a five-day introduction to Python and Django, and we were given a handbook. And I sort of lived in that handbook for years afterwards. It was literally always open on my desk, as you can see from the coffee marks, because I would put my coffee cup down on it. And I took it home one evening in that first week, and I showed it to my girlfriend Carol, and she leafed through it, and then she exclaimed, functions, classes and attributes. It's just, it's all Aristotle. And it is, in his ethics, Aristotle is concerned with virtue. He argues that the defining human function is rational activity. And he's very interested in the relationship between what a human being is, sorry, between what a being is and what a being does. And I mentioned this the next day to the person who was giving us our training. His name was Ian Millington. Some of you may even know the name. And it turned out that as well as having earned a doctorate in the field of artificial intelligence, his first degree was in theology. And he was also familiar with these ideas. And there were three of my colleagues in the room with us. And Ian and I, I were very happily chatting about Aristotle and reason and Python and functions and the human soul. And my colleagues endured this for a few minutes. And then one of them announced, I'm a creationist. And this talk about function and reason is making me feel very uncomfortable, which I wasn't expecting. And I was really taken aback. And I wasn't actually sure whether he was maybe teasing me or with a joke or if I'd misheard. And I started to ask him, what about it made him feel uneasy? And then my colleague Ben said, you needn't look so surprised. I'm a creationist too. And by this point, my mouth was hanging open. I don't think I was looking very intelligent. And then my third colleague said, Daniel, you're outnumbered. I'm also a creationist. And of course, I was completely flawed. And there were so many questions I wanted to ask at this stage, like, should we accept Aristotle's account of virtue as a disposition? Or what do you make of Aristotle's conceptual function as defining activity rather than purpose? Or do you identify a contradiction between Aristotle's form-substance dualism and a creationist account of the soul? So had all these thoughts and more intelligent things to say going around in my head in quick succession, but the only thing that formulated itself into anything resembling a coherent sentence was, what about the dinosaurs?  And if there's one thing I've learned over the years, it's to recognize when I'm outnumbered. So I was pretty intrigued, but I didn't pursue the question. And I've never forgotten that experience, that how quickly we got from basic concepts in programming to ideas in metaphysics and ontology that are not only important to academic philosophers, but will resonate and trouble and bother people who haven't studied philosophy and that have the power to shake people when they start thinking about them. And shaking people is exactly what important philosophical concepts tend to do. And what I realized as I learned programming was that philosophical concepts are literally expressed in programming itself. And that as programmers, we are working with philosophical ideas when we think about our code. And the more I've learned, the more obvious it has become how deeply embedded in programming these ideas are. And you might think that's expected. Logic is a branch of philosophy. And of course, programming involves logical thinking, putting together sequences of logical operations. But as the experience with Aristotle and Function suggests, it goes deeper and further and it's more interesting. Now, for a programming beginner like me, this connection gave me something to hold onto, a way to understand certain things in programming through something that I was already familiar with in philosophy. Because I already knew my way around things like attributes and ontologies and identity and truth and nothingness around types and instances and abstract classes, which you will all find in philosophy. I can't say I knew exactly what they meant because in philosophy, they're heavily contested anyway. Whereas in programming, at least somebody's gone to the trouble of writing a definition for you. But they were things I was used to talking and thinking about. I felt I was on familiar territory. And another thing that I found that seemed quite familiar about programming and that I also enjoyed were these declarations that I would read or hear. And they had a kind of profound and poetic mystery about them. So my handbook said, functions are first class values. And it said, values have type, variables don't. And it reminded me of Wittgenstein. Truth functions can be arranged in series or can't. Existence is not a predicate. And these are things I couldn't really judge whether they were true or not or what the implications were. And I didn't even know what kind of things they were, whether they were discoveries or axioms or necessary truths or something else. But I could feel, I could tell that there was something important about them. There were significant declarations about something important. And reading these things about Python reminded me of the things I read when I was studying philosophy. And the feeling that I had when I read similar things in philosophy, I couldn't judge whether they were true or false. But they seemed to lie upon a line of truth. They seemed to stand out to me as being important. And that they seemed to me to demand some kind of response from me. And often I would never understand them the first time or the 20th time I read them. But they seemed to demand that I return to them again and again until I did or thought I did. And so did the things that I read about Python. And when you find an idea that seems to lie upon a line of truth, then you feel this obligation to explore it, decide where you belong or which direction you're good to take on this line. Sometimes they have the kind of side benefit of giving me a reason to feel superior, which I'll take any time. So in my handbook, Python correctly distinguishes between an initializer and a constructor. Many languages, like Java, conflate the two, incorrectly calling this a constructor. So you can only imagine the pity and scorn I felt for those who might conflate a constructor with an initializer. And I had literally no idea what a constructor might be. But I knew that I would never be so vulgar as to conflate one with an initializer. And I had the same feeling sometimes reading philosophy. So here's Kant dismissing the appeal to common sense, which he says, the appeal to common sense, a convenient way of being defiant without any insight. So maybe some politicians might benefit from that. So I'll take any opportunity to enjoy a feeling of superiority. However, undeservedly, I've earned it. Now, when I started programming, I kept running into surprises that were not unlike the problems that philosophers find themselves with when they confidently pick up something that looks simple and then have a closer look at it. So a child very quickly learns to use the word nothing with confidence. What are you doing up there? Nothing. And then it turns out that you've got a pair of seven year olds in a bunk bed trying to inflate a balloon with a candle. So we use the word nothing several times a day without doubt or hesitation, not just in speech, but in our thinking about the world too. We use it to represent the world. Nothing is simply the absence of something. And just as in philosophy, nothing starts to look a little bit more troublesome when you unpack it. It also does in programming. One of the most common things I had to do as a programmer was to check for the absence of something. And all of a sudden, it was quite a marvel to me how many different kinds of absences of something could exist. I had to deal with several kinds of them. There was none. And there was zero. And there were empty lists and sets and other collections. There was the empty string. And then when I was doing Django in Django model fields, there was null for the database and blank for the forms. And they were all not something. They were all different kinds of nothing. And they were all different from each other. And in the Django applications I was building, I needed to represent the world, to construct a picture of it, not just of its matter, its content, but also of its logical form. So let's say I needed to represent actual people. Well, then you need a person model to capture that.  And then I would need to figure out my own adequate mental representation of a person in my thinking. And then in my Django models, in the database, in the forms which capture the data, and in the output. And all the different kinds of nothingness didn't really make a difference here, but they made different kinds of difference in all of these contexts. So consider something like a person's name or parts of a name, which parts of these will be allowed to be none or null or blank, and how are you going to deal with it? How are you going to display them? How are you going to order them? It turns out that to be very complex, because nothingness is not a simple business, and it affects everything it touches, and nothing really does matter. Now I found another abiding fascination in the other side of nothingness and negation in being. And just as negation has its origin in nothingness, so identity has its origin in being. Again, very simple. Being an identity, they belong to the verb to be. And even a child learns to use that simply and correctly and confidently. And so does the Python beginner, usually using these in simple and successful ways. And we can say 7 and 7 is 14, or 7 and 7 equals 14. And we know what we mean, and they're both true and they both make sense. And there doesn't seem to be too much pressing need to worry about it, because it works at first, until you do something similar that you thought would be the same, and then it doesn't work. And then you'll continue to run into puzzles in which their expectations, built on apparently similar outcomes of apparently similar operations, are confounded, where you have two operations that are only apparently similar, but not. You might say superficially similar, but I think actually the similarity here is deep and not superficially. It's only because we're human beings with the only human beings would perceive the profound similarity here and as a result get tripped up by the differences. And the puzzles will catch them out in their code. So, well, this works. That's fine. And that also works too. And so does that. And that doesn't. And does anybody know immediately what? Exactly, so the representation of integers up to the value, I think, of 256 in Python is a special case. And as people explore what is is and what equality is and what assignment is, it's quite a time before they internalize these rules and learn to ask the right kind of questions. What somebody thought they were asking was not what they were actually asking. So these are simple things, but the idea of is is such a simple thing. But philosophy has spelt a vast amount of ink trying to understand it. And this might seem like unnecessary quibbling to people who aren't philosophers. People don't like it when you have big discussions about small words. It's very suspicious, like when Bill Clinton said, famously, when he was facing the grand jury about his relationship with Monica Lewinsky, he said it depends on what the meaning of the word is. And he was not a good look. He was squirming and sweaty on television with good reason. But a Python interpreter has got a lot more patience than a grand jury and also no powers of understanding. So when we're dealing with a Python interpreter, we have to get the meaning absolutely right with respect to what the Python interpreter is expecting. We'd better agree with Python on its own internal metaphysics of being. So let's go back to Plato and Aristotle. Carol was very happy to read about functions and attributes in Python because it reminded her of Aristotle. And he has a lot to say about them. So we have Plato with his ideal forms that exist in and of themselves that define concrete things, whereas Aristotle wants us to start with concrete particulars in which we find that form inheres in which we discern the generals. Now this aligns with another nice distinction. Because the object-oriented programming that we do in Python is class-based. And this might be old news to you, but that's not the only kind of object-oriented programming. In JavaScript, you have prototype-based programming. So in class-based programming, we define abstract classes. In prototype-based programming, we create concrete objects. The classes exist as formal ideals from which we instantiate objects. In prototype-based programming, we find the form of our objects in hearing only in the particulars. And we clone concrete objects to create new ones. So the ideal form of an object, the blueprint, the class that defines it, exists in and of itself for Plato and class-based programming. But Aristotle, JavaScript, and prototype-based programming take a different approach. So it seems to me that Plato is to Python as Aristotle is to JavaScript. Maybe Aristotle is a better model. Carol didn't know that, but she's a philosopher, not a programmer. Even I didn't really know this until quite recently. So here we are back again in the Apostolic Palace, with Plato pointing up and Aristotle pointing down. To say that one is right and one is wrong is not really the point. It's a difference that demands somehow that we take sides. And if we want to answer the question, Plato or Aristotle, which side are we going to take? Well, I think kind of a sensible answer is, I don't have to choose. But actually, my answer is Plato, obviously. Because everybody finds themselves on that line. So here for the last time, here they are on the wall of the Apostolic Palace. Plato pointing up, Aristotle pointing down. They're the center around which everything else is revolving. And here's John Travolta in Saturday Night Fever. And he's a center around which everything is revolving. And he's also pointing up and pointing down at the same time. And those two directions give us a line. It's a line of truth. And we can choose for ourselves a direction on that line. We don't have to, but we can. And the important thing is not to choose the direction, but to be aware of the dimension, which gives us both dimensions at once, like John Travolta. And we must live on this dimension in our thinking, I think. We must find our way on this line of truth. When you find something like this, you feel obliged to explore it to choose your direction. And that was the kind of force and the demand that I felt in philosophy. And it has been with me ever since. Now, of all the people I've met in the world, since I started my philosophical studies a very long time ago, the ones who respond most strongly to philosophical questions are actually programmers. Maybe these people who think that way tend to become programmers, or maybe programming does something to the way they think. I don't know. But I've never met any other population of people, including actual academic philosophers, who can think about philosophical questions as intelligently and wisely and illuminatingly as programmers can. And it's an experience that I've had again and again, including when it comes to questions of things like ontology and metaphysics, existence, identity, and nothingness. And they've been, on the whole, much more rewarding conversations than the ones that I've had with actual students or academic colleagues, or, as we call them in academia, opponents. And I'm sure that if programmers became philosophers, they'd have lots of interesting things to say about some of these things. So here's Kant's treatment of nothingness, which is equal in rigor to anything that you'll find in programming. Or his table of judgments, by the way, he calls judgments, logical functions of unity. There we are with functions again. I've read so much rubbish on this subject, mostly not from undergraduates in their essays, but in books that I've gone out to buy with my own money. So that gives you an idea of that. I'm sure programmers would do better at this. And there are so many places to go and things to think about that are connected directly to these ideas, where substance, identity, equivalence, positivity, objecthood, and their corresponding ideas on the side of nothingness. And these things may well be wider and further than you imagine, these connections may be deeper. Now, Plato argued that we'd never have a just society until philosophers became rulers or rulers became philosophers. And I found this very appealing about 30 years ago. But it started to look a little bit more implausible, especially since I got to know a little bit more about the way philosophers actually managed to run things, like philosophy departments. So what about the idea of programmer kings? Well, programmers already have a vast amount of power and influence because their thinking is responsible for much of the construction of our world right now and is becoming increasingly slow. And while it's a subject for another discussion, I think my main response is to say, no, thank you very much. I'd probably even take my chances with the philosophers. But the idea of programmer philosophers is something else. Programmers are made for this. They're genuinely good at this. And I find it nothing less than fascinating that they are. And I continue to have fascinating encounters with programmers that illuminate and add new dimensions to the philosophy that's been one of the most important things in my life for most of my life. So I would say thank you all for the conversations. And I hope there will be many more. I don't know if we have time. I'm happy to have some questions if we have time. So thank you very much. We have time for literally one question. That was quite amazing, Daniel. So clearly, metaphysics has to give way to epistemology. The question of what is has to give way to the question of how can we know anyway. How would you see that as informing your programming style? Well, first of all, I should say that you can spot an Aristotelian a mile off when they ask questions like that. Because I actually dispute that. I think that, for example, we need metaphysics because metaphysics will we need metaphysics to understand how we know how knowledge is possible, how understanding is possible in the first place. So I'm not sure that we can start with metaphysics. About my programming, my programming is actually extremely not even Aristotelian. It's kind of common sense inductive, just trial and error until something seems to work. So I wouldn't, yeah, you showed me up there a little bit because I don't think that you could really map it onto anything so grand. My programming is actually very poor. But I love thinking about these ideas. I loved your talk because of the way it illuminated some of these things. And I was able to look at your description of the construct and say, well, yes, I know that, of course. The constructor cannot be confused with an initializer. So yeah, I think there probably are programmers. But they are programmers who are operating at quite a different level from the level at which I operate as a very clunky, clumsy programmer feeling his way. I think that's probably it, unless we can squeeze one more in. No, we have to go. OK, thank you. Thank you very much.


This presentation is a continuation of the exchange that Dr. Brown and myself were having over here. It is a response to Dr. Brown's two-part video entitled Dr. Brown Responds Again to Rabbi Blumenthal Part 1 and Part 2. I would like to begin by thanking Dr. Brown for taking the time and the effort, investing time and effort in this exchange. Now Dr. Brown has complained in these videos that it's getting tedious. It's going round and round.  So I would like to take a minute to explain why I believe this exchange of ideas, these presentations, these video presentations that we are making is beneficial and a blessing and why I sincerely thank Dr. Brown for taking part in this exchange. You see, we have two communities over here. We have a Jewish community and a Christian community. I'm talking about those Jews and Christians that are loyal to God, loyal to the Jewish scriptures. Both of these communities' communities respect the Jewish scriptures. They revert them. They study them prayerfully, humbly before God, and sincerely. And each of these communities sees a completely different message emerging from the pages of the same scriptures. And each of these communities sees this message as harmonizing with every verse resonating from every page, but only one of us can be right. We cannot both be right. One of us is reading the correct message of scripture and one of us is reading an incorrect message of scripture. Now, there are a few ways we can go about to determine which one of us is right. We can trace the conflict, the friction to its original source.  Go back before Jesus appeared on the scene, before the church presented any of its claims to the Jewish people. And ask yourself, put yourself in the shoes of a Jew back then 2,500 years ago. How would a Jew have read these scriptures? How would he feel about the scriptures? How would he see in what context would he read these scriptures? How would he seem self-standing in a covenantal relationship with the God of these scriptures? And try to read the scriptures in that light and develop a world view on that basis and then hear the claims of the church and examine them in light of the Jewish scripture from the standpoint of a Jew who lived before Jesus. That's one way of trying to figure out which one of us, which one of the communities is reading scripture correctly. Another way of doing this is listening to the rendition of scripture presented by the Jew, the rendition of scripture presented by the Christian. And try to find the fault lines, try to find the weak spots in whichever rendition has those weak spots. Try to figure out which rendition is actually loyal. Try to trace each argument back to its scriptural source and see which one of them is actually loyal to scripture. Let me just say, it's only very simple, is that one of us has to be obfuscating. One of us has to be engaged in rhetoric. One of us has to be engaged in smokescreen. That's just a mathematical fact. It's either the Jewish community or the Christian community because scripture is not giving us two different messages. Scripture is in fact only giving us one message and only one message could be true. There's a third way and that's where these video presentations come in. The third way is listen to the proponents of either side. And here I'm trying to present the Jewish position, Dr. Brown is trying to present the Christian position and watch how each of us reacts, responds when the fault lines in our respective positions are exposed, are brought to light, listen and try to digest the arguments of each side as they react to the arguments of the other side. So yes, we're human beings, there's going to be misunderstandings, there's going to be human error, it's going to be tedious, it's going to be frustrating and it is going to go round and round to some degree. But it's a search for truth and there is no more rewarding activity in life than searching for truth. I spoke in the past about Zechariah chapter 6 verses 9 through 15. I'm going to be going back to that because you see when the Christian wants to get the Christian message to emerge from the Jewish scriptures, the Christian rendition of that message, he's going to have to do two things. He's going to have to marginalize concepts that the author emphasized such as observance of the law of Moses, the eternal choice of Israel as a covenant nation and as a witness nation before God. So that's one thing he's going to have to do, he's going to have to marginalize what the author emphasizes and highlights and then he's going to have to highlight concepts that the author never said. For example, there is no remission for sin without the shedding of blood. A concept appears nowhere in scripture. According to the Christian, it's a central pillar of the Jewish scripture, the theology of Jewish scripture. So the reason I'm focusing on Zechariah chapter 6 verses 9 through 15 is because in this short paragraph, in his interpretation of this short paragraph, Dr. Brown actually does both of these at the same time. He takes the primary message of this passage, the Messiah as a temple builder and he relegates that to the background. He uses the words hardly significant to describe the Messiah's role as a temple builder and a concept which appears nowhere in the text and Dr. Brown admits that it appears nowhere in the text. The Messiah as a vicarious atonement suddenly becomes the primary message of this short paragraph. Now Dr. Brown in his most recent video said again and again, no, he never said that the text says that the Messiah is a vicarious atonement. Yes, and I know that. That's exactly my point. The text doesn't say that. The author never said that. What Dr. Brown does is he takes one detail of the text. The high priest sitting on a throne and he tells us that that is the most significant feature of this little passage. If you will note, the author didn't tell us what the meaning of that. Why is it that the high priest is sitting on a throne and what lesson we're supposed to learn from that? But Dr. Brown tells us that the lesson that we're supposed to learn from that is if the high priest is sitting on a throne, that means that the Messiah is invested with a priestly role and therefore he's going to die as a vicarious atonement. That's only one interpretation. The author didn't say that that is the interpretation of the high priest sitting on the throne. I actually offered two other interpretations. I said perhaps the high priest is sitting on a throne in order to not to invest the Messiah with a priestly role, but rather to invest the priest with a messianic role. This particular priest was a temple builder. So maybe the prophet is putting him on a throne, giving him a crown in order to show that this particular priest is acting as a messianic figure or another interpretation. Perhaps, yes, the high priest is sitting on a throne wearing a crown to show that the Messiah has a priestly role. But the priests had many functions. The priests were judges and teachers. Perhaps the prophet is telling us that the Messiah will be a judge and a teacher like the priests were. So the idea of the priest sitting on a throne doesn't tell us vicarious atonement, but that's the only interpret that Dr. Brown says my two interpretations don't explain why the high priest is sitting on a throne. He doesn't tell us why not. Why doesn't it explain it? All of Dr. Brown's protests, notwithstanding, Dr. Brown is saying indirectly that this passage is saying vicarious atonement. He's saying that the passage is speaking about the high priest sitting on a throne, and the only interpretation he's allowing for is vicarious atonement. But the author left that on said. The concept, which in this short paragraph, in these few short verses, the author repeated three times, temple building, that is to Dr. Brown, hardly significant. And I think this is a serious fault line in the Christian rendition of the message. If you have to take something which the author says three times in a short paragraph and say that's hardly significant, and then take one concept and invest it with meaning and project a whole idea into which the author completely did not say, and make that the significant and the most important teaching of this passage, that should tell you something about the Christian's rendition of scripture. And before I leave that vicarious six, let me just ask you a question. If indeed, as Dr. Brown claims that this is the only place in all of scripture where the Messiah is portrayed as a temple builder, then why is this not the most striking feature of the passage? Why is it the high priest sitting on a throne that Dr. Brown says is the most striking feature of the passage? Let's move on to the subject of idolatry. See, in this particular stage of the discussion, we actually made some progress because Dr. Brown in his most recent video acknowledged, finally acknowledged, that my position is not that the Christian only worships Jesus and doesn't worship God. Dr. Brown is finally recognizing that my position is that the Christian worships both God and Jesus. So we've made progress with this discussion as tedious as it is and as round about as it goes, but we got somewhere. Okay, now we can move forward. Dr. Brown defends Christianity against this charge and says, no, these two loves are not two different loves. It's the same love. It's only love for God. And this is how he explains it. He provides an analogy and illustration to explain his position. He says, imagine if the Messiah is not divine, which is actually the Jewish position. It's also actually the position of Unitarian Christians. And the Messiah is not divine and God sends this non-divine messenger of his to accomplish his purpose on earth. Wouldn't we love God all the more now that God sent this glorious messenger and did such great things for us? And therefore, Dr. Brown is applying that to Jesus and saying, yes, now that Jesus came, we love God all the more. I'm going to use Dr. Brown's analogy to illustrate my position. Let's talk about a Unitarian Christian who actually fits Dr. Brown's analogy. The Unitarian Christian believes the same thing that many that Trinitarian Christians believe, that Jesus is the Messiah, that his main function of the Messiah is to die for the sins of the world, and that Jesus fulfilled that function, that there is no salvation without faith in this ultimate sacrifice of Jesus. The Unitarians believe all of those. The only difference is a slight difference between the Unitarians and the Trinitarians that the Unitarian believes that Jesus is not divine. He was a human being, an exalted human being, but a human being. Now let's look into the heart of the Unitarian. I'm not trying to judge anybody. This is theoretical. In the mind of the Unitarian, there are two entities. There's God, the Creator of heaven and earth, the one who sustains every facet of existence every second of the day. That's God. Then the Unitarian sees Jesus. A human being, a great human being, and I would imagine that the Unitarian has feelings in his heart towards God, the Creator of heaven and earth, thankfulness for creating him, for giving him every breath of life, etc. And the Unitarian has feelings in his heart towards Jesus, who he sees as a human being. The sacrifice of Jesus, the self, the righteousness of Jesus, and all those things attract the heart of the Unitarian towards Jesus. In the heart of the Unitarian, these loves are two distinct loves. Yes, the Unitarian loves God all the more because God sent Jesus, but he also loves Jesus as a human being. Imagine if this Unitarian becomes a Christian, becomes a Trinitarian. He becomes a Trinitarian. What happens to these two loves? What happens is that he will fuse them together in his mind and tell himself that these two entities are some mysterious way, one, but there are still two different loves, two different attractions. There's an attraction towards the Creator of heaven and earth, and there's an attraction towards an entity that operated within God's creation. Or imagine if a Trinitarian becomes a Unitarian. He decides, no, Jesus is not divine. He was just a regular person. Does the Trinitarian have to build a whole new love in his heart that didn't exist before now that he became a Unitarian? No. All he has to do is tell himself, this that I was telling myself until now, that these two entities are in some mysterious way, one or not. It's just some theological rearrangement. But it's two different attractions that pull your heart towards one entity and towards another entity. And obviously, the attraction towards God as Creator of heaven and earth that exists in the heart of the Christian and in the heart of the Jew, that's the attraction that David sings about in his book of Psalms. That's the love that all worshipers of the Creator of heaven and earth have in their hearts. And the attraction towards the man, Jesus, whatever you believe about and whether you believe he's divine or whether you don't believe he's divine is a different attraction. Appears nowhere in the Psalms of David, appears nowhere in the Jewish Bible as an attraction that we should elevate to worship of the divine. So thank you, Dr. Brown, for providing this analogy, which helps us illustrate the Jewish position on this matter. In one of my previous videos, I asked Dr. Brown, why is it that Genesis 18, Exodus 24-10, Numbers 12-8, do not appear, are not presented by the author of the Bible as teachings on directing devotion? What was I saying? The point is, Dr. Brown uses these passages that I just mentioned, Genesis 18, about the three angels, Exodus 24, Numbers 12-8, to justify devotion to Jesus. So Dr. Brown first responded by saying that no, he's not using these passages to justify devotion. But in his most recent video, he said that Genesis 18 appears before the Sinai Revelation, which is in the book of Exodus, which is after the book of Genesis. And he seems to be saying, what if I understood him correctly, what he's saying is that by the time we get to the book of Exodus and read about the Sinai Revelation, we already met the three angels in Genesis 18, and Genesis 18 provides context for the Sinai Revelation. And he says that Exodus 24-10 is part of the Sinai Revelation, and Numbers 12-8 appears before Deuteronomy 4, and also modifies or provides context for our read on Deuteronomy 4. So basically what Dr. Brown is saying is that Genesis 18 appears before the Sinai Revelation. Really? Genesis 18 appears before the Sinai Revelation. That is if the Sinai Revelation to you is words in a book. But the Sinai Revelation is not words in a book. The Exodus and the Sinai Revelation is where God married the Jewish people. That's where the covenant was created. That's where the covenant was sealed. A marriage means that each partner opens themselves up towards the other one in a way that they open themselves up to no one else. That's what marriage is all about. The Jewish people open themselves up to God, that we surrender our hearts in complete devotion to no one but the Creator of heaven and earth. How does God open himself up to us in a way that he does to no other? That was Exodus and the Sinai Revelation. That's when God brought the truth of his absolute sovereignty to our hearts in a way that he did for no other nation. Not just as a matter of knowledge but the weight of that truth. The beauty of that truth. The attraction to the human heart that's inherent in that truth was brought to the people of Israel through the miracles of Exodus through the Sinai Revelation. And that's the basis. That's the context for everything else. That's where we stand. That's where our covenant with God started. That's where it begins. And that's where it grows forth from. We read all of the Bible in that context. Let's just consider this question. Open the Bible. It's her first verse in the Bible. In the beginning God created heaven and earth. Ask yourselves the following question. Did the author of this book expect that you should understand what the word God in Genesis 1-1? Did he expect you to know what that word means? Or are you supposed to read it like an algebra equation? You know, like an X or a Y? And only after I study the entire equation and figure everything out can I figure out what the word God means. No. It's obvious that God expected his readership to know what that word God means. Not only to know what the word God means, but to see themselves, to see the readers, because the target audience of Scripture is the Jewish people, to see the readers should see themselves as standing in a covenantal relationship with this God and have a clear understanding of who they're talking to and who the book is talking about. And where were they supposed to get that understanding from Exodus, Sinai, as preserved through the testimonial observance as the Jewish people passed on from generation to generation? So Sinai Revelation comes before the first word in the Bible. And it's the basis of our ongoing relationship to God. Obviously our relation to God is not limited to the Sinai Revelation. Every day we thank God for his blessings. We pray, we study his law. But the Sinai Revelation is the context and the background for everything that a Jew sees, including the Bible that God gave us after the Sinai Revelation. So for Dr. Brown to say that Genesis 18 comes before the Sinai Revelation tells me that he's looking at the covenant that God shares with the Jewish people as an outsider looking in. He's not part of that covenant because if he'd be part of the covenant he would realize clearly that the Sinai Revelation comes before Genesis 18 and before Genesis 1. The entire Bible was given to us in the context of the covenant that was sealed, the marriage between God and the Jewish people that was sealed through the Exodus and the Sinai Revelation. Let's move on to the subject of Atonement. At this point we're coming to the second part, Dr. Brown's part two video, the second part which he posted on January 10th, 2017. Now at one point in this presentation Dr. Brown complains that I'm applying a double standard. When he asks me a question and I say, well I address that question on my writings, on my blog, in the various writings that I have written. So Dr. Brown says, okay, says, and why is it that when I ask a question he can't point back to his five volumes and when he does that I say he hasn't answered the question. It seems like Dr. Brown doesn't fully grasp what we're trying to do over here, at least maybe he has a different understanding of what we're trying to do over here in this ongoing exchange of presentations. The audience wants to see in this world. I think the audience wants to see is how Dr. Brown reacts to my questions and the audience wants to see how I react to Dr. Brown's question. So if Dr. Brown presented a question and I answered it and Dr. Brown just repeats the exact same question without elaborating, without explaining why my answer doesn't satisfy him. So then I just say, please, here's my answer. Tell me why your answer doesn't satisfy you and we'll take the conversation from there. So when Dr. Brown asks the same question that he asked in the past and I gave my answer he never interacted with that answer. So I just say, please interact with my answer and then we'll take it from there. As opposed to when he points back to his five volumes, all of my writings were written after he wrote his five volumes. They present my reaction, why I'm not satisfied with his five volumes. And therefore I'm asking, don't just point back to the pages of your five volumes. Tell me why you're not satisfied with my answer, why my question is meaningless to you, et cetera. In fact, in this presentation about the subject of atonement, Dr. Brown didn't bring much that is new to the table, except for one argument. So let's focus on that argument right now. The Christian believes that there's a foundational principle in the Jewish Bible. There is no remission for sin without the shedding of blood. And my question to Dr. Brown was, why is this concept not stated anywhere explicitly in the Jewish Bible? Why is it only a deduction that emerges from between the lines? And Dr. Brown now responded by saying, well, some of my modernity's principles, which concepts theological doctrines, which my monies consider as principle to the Jewish faith, are also not explicitly stated in the Bible. That's an answer. That's something that Dr. Brown did not write in his book and is now interacting with my argument. Beautiful. This is the purpose of the exchange. It's a nice argument. Answer. Now I'm going to interact with Dr. Brown's argument.  Dr. Brown is admitting that no remission for sin without the shedding of blood is only a deduction. It's not explicitly stated anywhere in the Bible. So when Christian missionaries say, Leviticus 1711 says, there is no remission for sin without the shedding of blood, it doesn't say that there. And Dr. Brown knows it doesn't say that there, as he writes in his book. It's only a deduction. So let's put that clearly on the table. But to answer the question, my monies is operating in a completely different framework and a completely different set of rules than Dr. Brown applies to himself. Dr. Brown sets the standard in the beginning of his five volumes. And he says, the only rule for Jewish belief is what it says in the Bible. My monies didn't believe that. My monies wasn't a Protestant Christian who believes in the principle of Sola Scriptura. My monies had the complete testimony of God before him, the Bible, and the testimony of the Jewish people and Jewish principles from the full body of God's complete word. So that's one difference. And the second point is that each one of my monies' principles are more clearly affirmed in the Jewish Bible and more explicitly affirmed in the Jewish Bible than any Christian doctrine, especially a doctrine of there is no remission for sin without the shedding of blood. The rest of Dr. Brown's video is basically reiterating arguments that he presented in his five volumes. So let me address two of those arguments. One of those arguments is that Dr. Brown points out that the Hebrew word kaper, or derivative of that word, that word means purging, atoning, cleansing, appears so many, so many times in the Bible and it appears almost exclusively in association with the Levitical Sacrifice, with the sacrifices, the blood sacrifices of the temple. And Dr. Brown then comes to the conclusion, well that means that the only way you're going to get atonement is through those blood sacrifices. Responds. There are many expressions that the Bible uses to describe God's forgiveness, remission for sin. I'll give an example of an expression. In the book of Ezekiel, it says, all of the sinner's sins will not be remembered against him. You know it says that in relation to repentance. It doesn't say that in relation to blood sacrifices. Or in Deuteronomy 30 where it describes God rejoicing to restore the blessings upon his people, to bring back our captivity, to accept us favorably. These terminologies are used in association with repentance and not in association with blood sacrifice. So who tells Dr. Brown which term is more important and more foundational in the atonement process, in the cleansing process, in the process of regaining God's favor after we sinned? Who said it's the expressions used in relation to Levitical Sacrifice as capoeir as opposed to the expressions used in Deuteronomy 30 or Ezekiel 33? Furthermore, every Christian would tell you that Isaiah 53 is one of foundational teachings of Scripture on the concept of atoning for sin and purging. And the word capoeir does not appear over there. So I'm not so sure what Dr. Brown is emphasizing, what he sees in the word capoeir. The Bible doesn't tell us that the word capoeir is the only word that expresses atonement for sin as Dr. Brown. It's not the Bible. I can offer an explanation why that word is used in association with the biblical sacrifices because you have to realize the point of the biblical sacrifices is that it's an outward expression, it's an expression that is out in the open here in this world and the practical world of what's going on in the person's heart. It's an expression of the repentance that's in the heart that's done on the outside. Those biblical sacrifices are relevant in a time when God's relationship with the Jewish people is expressed openly and on the outside here in this world in a way that everyone can see in the temple. So when you have a temple, you have an open relationship with God, the repentance in the heart needs to have an open expression of blood sacrifice. But when we don't have the temple, that's not what we're missing. What we're missing is the repentance as described in Ezekiel 33 and Deuteronomy 30. Another argument that I would like to address is Dr. Brown's most recent video tells us that the word Asham in Isaiah 53-10 is a reference back to the Asham sacrifice in the Book of Leviticus chapter 5. Let's put this argument into context. What happened was is that when Dr. Brown emphasizes and highlights the biblical sacrifice of the Book of Leviticus, that still did not bring him to a theological destination. That's not what he wants to get to. He doesn't want to get to animal sacrifices at a temple. He wants to get to Jesus. So that's only one stop. And he had to use the word Kaperot, one deduction to get him there that there is no atonement for sin without those sacrifices. Then he has to get from the biblical sacrifice of Leviticus and he has to get to Jesus. And my question to him was, where does the Bible say anything about the Leviticus sacrifice, the sacrifice described in the Book of Leviticus? Where does the Bible tell us that they point to anything bigger and better? So Dr. Brown's response was, well, the word Asham in Isaiah 53-10 tells us that the suffering of the servant is somehow a fulfillment of the sacrifice of the Leviticus. And my response to that was that the word Asham in Isaiah 53-10 is not a reference back to the Book of Leviticus. It simply means an offering that expresses guilt. We find that the Bible uses the same word to describe money offerings or other offerings that express guilt, not necessarily the sacrifice of the Leviticus. So there's no Dr. Brown's argument, has no basis in the Bible. And I did also point it out that the Bible does know how to tell us that the sacrifices point to something else. In Psalm 51, verse 19, it tells us the offerings of God, Zivche, the sacrifice of the Lord are a broken heart. In other words, the sacrifices point to repentance. The Bible made that clear. The Bible did not make clear anything about the sacrifices pointing to the vicarious atonement of any given individual. Let me recap. Again, let me go back to the beginning. We're talking about two renditions of Scripture. What I've done over here is exposed some of the fault lines in the Christian rendition of Scripture. I pointed out how in Zachariah chapter 6, verses 9 through 15, the Christian needs to take a concept that author repeated three times in that little passage and relegate that to the background and take a concept that appears nowhere in that text and have the text point to it in some interesting way. How the love that the Christian is encouraging and advocating is not the love that David sings about in Psalms. How the Christian rendition of Scripture sees Sinai, the Sinai revelation as words in a book and not the love expressed between God and the Jewish people that it actually is. How the Christian teaching on atonement is built on deductions that have no foundation in the Word of God. Please consider these questions, study them, feel the weight of these questions, study Dr. Brown's responses to these questions or lack thereof, and come to your own conclusions.