Transcript from the "Introduction to Programming" Lesson
>> Kyle Simpson: Our goal now is to jump right in, and where we're going to start is Chapter 1 of the up and going book. So if you wanna follow along, again, if you don't know js.com gets you to the repo, and if you wanna follow along with us, essentially we're gonna start from Chapter 1.
[00:00:15] I'm not gonna read word for word the book to you, but i'm gonna try to distill the same concepts that we deal with in the book. We'll try to go through those things. We'll take plenty of little mini breaks after we've dealt with a concept or two, we'll take a little breaks, and we'll have some time for you to practice these things.
[00:00:33] There is no substitute for you typing this in yourself, either in your own code editor or In the dev console of your browser. Trying each one of these things yourself is really important. And that's true even if you already come to the table with experience. Don't just forsake the things and say, I get that.
[00:00:51] Definitely I encourage you to follow along and participate. So we start this book series, the Up And Going book is conceptually the first book of the series. This is the place to start, and it makes most sense to start from literally the very beginning. So for those of you that don't really have a lot of programming experience, let me try to dispel a couple of myths and fill in a couple of details that you may not have heard before.
[00:01:15] So when people talk about programming, when they talk about writing code, essentially what they're talking about is typing into a text file, and that text file is referred to as your source code. Now, the source code is a set of special words, and phrases, and operators, which are special characters.
[00:01:35] They're designed to give instructions to the computer on what to do. But the symbols, and words, and phrases that you put into that program are not actually in a form that the computer can directly understand, it needs some assistance. And so there is a step after you write these instructions into a text file, there is a step that comes along, and it goes by different names depending on the context that you're in.
[00:02:01] But there's a step that essentially comes along and converts the physical words, the readable code, as we would say, that you've written, into a series of instructions that the computer can actually understand. And those instructions are in the form of binary, the ones and zeros strung together. So the first observation that I would make, and I think this is an important one regardless of what level of your experience in programming, is that the source code that you write is not really for the computer.
[00:02:29] It's almost sort of a side artifact of what the computer really cares about. There's a special program on your computer, a compiler, or an interpreter, or something like that, that does care. But the overall computer system doesn't care about the source code. And it is actually possible to write a potentially infinite different set of source code files that when boiled down to those ones and zeros would produce exactly the same stream of ones and zeros.
[00:02:58] So if you could literally write an infinite number of different programs that do the same thing for your computer, then what difference does it make what source code we write? And that's the first big observation that I'd like to make is that the difference is that source code is not for the computer, I mean, yes, it's used by your compiler, but it's not for the computer, it is for the developer.
[00:03:20] It is for you to be able to look at what you've done and understand what your program is intending to do. And it is also for other developers, people on your team, your future self, if you come back six months later, and you're looking at a program. You want to write the code in such a way that it not only does the correct thing, but it also makes sense.
[00:03:41] That's an often overlooked topic. In fact, many times people come back after having written a completely nonsensible program and try to sprinkle in bits of sensibility to it. And I would encourage you to try to strive to go in the opposite direction. Try to write everything that you write in such a way that your future self, having no context and having completely forgotten, having had many margaritas and many nights of sleep since, that you could go back and look at that line of code and understand what it meant.
[00:04:12] What was it intending to do? What was its pros and its cons? Don't assume, if you think, I know this variable can only ever have numbers in it. But if that's not obvious from the line of code, then that's an assumption that you've made that isn't obvious in the code and won't be obvious to another developer and won't be obvious to your future self.
[00:04:32] So it's incredibly important to approach writing source code from the perspective of the developer, more so even than the perspective of the program. Of course, you have to write syntactically correct code, you have to write code that works the way the language expects. And we'll spend plenty of time talking about that in a moment.
[00:04:49] But I did not wanna gloss over the fact that the source code that you write is for developers. And there's lots of different things that you can do, and it will be an ongoing process, you will never completely master the skill of writing sensible programs. You can master the skill of writing functional programs, with given enough practice.
[00:05:29] It is something you have to work at, it's something you have to try, you have to practice, you have to learn over periods of time. And I consider myself particularly not good at this. Most of my effort in teaching is not writing code, but writing code that's more teachable.
[00:05:45] And I struggle with that, to be completely honest. I struggle to figure out how can I rearrange this in a way, it's not just about what I call something, but how can I rearrange this in a way that actually makes sense to people? That fits the way our brains kind of try to linearly process through stuff?
[00:05:59] That's a difficult process, so it's not something I can just teach you as a road skill and then you can be certified in it. But it's something I would encourage you to not gloss over it, something that's very important to try to do. [COUGH] So I already have started to skip over some things, so let's fill in some gaps.
[00:06:35] It will tell you what are the valid combinations of characters, the valid combinations of words that you can put together to do what you wanna do with your program. So the syntax of a programming language is much like the syntax for English or whatever your native tongue may be.
[00:06:53] There are actual physical things that you can do, there's punctuation marks in the English Language, like the comma, and the period, and the exclamation mark. There are parts of phrases that work together, like a word used as a verb versus a word used as a noun, those sort of things.
[00:07:11] But the way you put those things together into a phrase, and then put phrases together and make a sentence, that's called grammar. And you maybe remember, back in school you learned English grammar or whatever. So there's a very similar concept in programming. Learning first the syntax and then the rules of how to put the syntax together to make a coherent, what we call, statement, that's what we call grammar.
[00:07:32] So I will put the word grammar and the word syntax together from here on out, and I'll just use the word syntax, most people do. But just so you understand, they're are two different faces of the Rubik's Cube, if you will, they're different parts of the same thing.