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