 This is the introduction video to a whole series of videos that teach programming. In it, I'll briefly enumerate all the things that you need to learn if you want to learn how to program. And then I'll discuss the approach of this series towards the material. And last, I'll talk a little bit about the future plans for this series. About some material that will be coming later. Now, if you want to learn to program, what everyone tells you is learn this particular programming language. But just learning one language or a few languages, even if they're the right languages, that's really only a very small part of what you need to learn. First off, you should have a decent understanding of how data is represented inside computers, basically how things like numbers and text are represented as bits. From there, you also need to understand some basic things about the nature of the machine, the nature of the hardware, and also the environment in which your programs are going to run, namely the operating system. And to do our programming, we use a wide range of tools that is existing programs to do our programming. Compilers, interpreters, text editors, debuggers, terminals and shells, version control systems, build tools, profilers, co-generators, et cetera, et cetera. There's quite a long list there. And if you're going to be learning more than one language, and you absolutely should, you should be learning at least a few, it's really helpful to have some understanding of their fundamental differences. You should be able to say whether this language has object-oriented features, whether it's dynamic or whether it's static, whether it has strong typing or weak typing, and those sorts of things we can file under language theory. In just about any computer science program, one of the introductory courses is going to be a class usually called something like Data Structures and Algorithms. And this class generally covers the essential data structures for collections of data and also the algorithms to search over those collections and also to sort them. These searching and sorting algorithms are really all quite simple, but they're definitely the most essential you can learn. And unlike some more specialized algorithms, these get used pretty much in any body of code you can find. If a program needs to manage and retain a large collection of data, it almost always makes sense to use a database for that program. A database system is just generally a program that specializes in that task of retaining and managing a lot of data. Most databases in use today are called relational databases because they organize their data in what's called the relational model. Closely associated with these databases is a standard called SQL, which stands for Structured Query Language. It's basically a standard way of talking to the database. So the idea is that you have different relational databases out there that you can talk to them all using the same structured query language. So generally when it comes to learning to use databases, that's where you start. You'll learn SQL. Tons of programming these days involves the internet and the web. So you're going to want to learn about internet and web standards like TCPIP, which is the standard protocol for the internet. HTTP, which is the standard protocol of web browsers and web servers. HTML and CSS, which are standards for the description of web pages. And then also you should learn what's called server-side web programming, which basically refers to programs on web servers, which generate the pages you see when you visit a site. Now, security to a large extent is a specialized expertise within the domain of programming. Not all programmers are experts in security. However, there's a good set of stuff about security that every programmer should know, including some basics like how does encryption work, what kind of vulnerabilities can a programmer have, and what are some best practices for avoiding security problems in your code. A good programmer should also be versed in some more general coding practices, meaning basically that there are some generally accepted ways of writing good code rather than bad code. And any good programmer, needless to say, should strive to write good code. There are also what we call methodologies of programming, which refer more to the general strategies of how do you go about your projects. How does an individual programmer or a team of programmers or a team of programmers and all sorts of other experts, like graphic designers and managers, how do they actually go about the business of undertaking a project? How should they plan for the project? How much planning should they do? Things along those lines. A prescription for how one does all that stuff that's called a methodology. And of course there are competing, conflicting methodologies out there. So there's no definitive methodology, but you'll want to be versed at least in the basics of some of the more popular ones. Lastly, there are some areas of programming which are really specialties. Like for example, graphics, audio, game programming, AI, voice recognition, safety systems in vehicles, like the computer that controls your anti-lock brakes maybe, or the flight control systems of a rocket. The point is that even if you do know how to program, that doesn't mean you can just do anything in code. There are just a lot of specific areas out there that require a lot of study unto themselves. So just like say a doctor can't specialize in everything or a lawyer can't specialize in everything, you're going to have to pick and choose your own areas of specialty. It's not quite as restrictive as say in medicine where one picks a specialty early in your career and you stick with that for the entirety. Program is quite commonly transitioned between a few or several specialties over the course of their whole career. Just understand that when you do decide to pick up a new area of specialty, it's almost like you're going back to school. So the main specific specialties aside, everything I've listed here is covered by this series with only a few exceptions where I haven't yet completed the videos, namely data structures and algorithms and security. Those are the two big pieces missing, but I'll probably have those in place in the next few months. You can see the list of these videos either from my YouTube channel or better if you go to the codeschool.org site and click on core units that shows you the list in the order in which you are intended to view them. So if you're just starting out and you haven't programmed at all, you're going to want to follow this order. Also note that on this page you have more than just a link to the videos. In some cases there are some notes you can look at and in some cases a bit of supplementary material. Now again, the order you see here on this page is the prescribed order, but I have to admit that some of the earlier videos are a bit of a slog I have in mind here the second and third video, numbers as bits and bits in text. Those two videos explain how data is represented as bits, namely how do you represent numbers as bits and how do you represent text as bits. They are actually two of the shorter videos, but by the nature of the material they are a bit dull and it doesn't help that these are two of the earliest videos I did. And when I listen to them now, I think my voice gets a bit droney and mumbly, even more so than usual. So at some point in the future when I go back and revise a lot of videos, I'm going to start with those two. So in the meantime I will say give them a try, see if you can tolerate them. If you find yourself zoning out when you try and watch them, go ahead and skip them. The notes on the site for those two videos pretty much summarize what you really need to know. Now you're probably wondering which programming language I teach, because which programming language a learner should learn first is one of those topics which programmers like to debate endlessly. My answer is actually that you should learn more than one language, and those languages are JavaScript, Python, C, and Java. Where the series starts off, though, is with a language I made up myself, which I call Pigeon. The idea behind Pigeon is that it's a reductively simple language that introduces you to all the core concepts we'll find in real programming languages like Python, C, and Java, yet it lacks the distracting complexity of a real language. So the very first video covers Pigeon, which, in its entirety, takes about 90 minutes to explain. Once you've gotten the gist of Pigeon, it then becomes easier to learn JavaScript, and once you learn the gist of JavaScript, it likewise, in turn, becomes easier to learn Python. Pigeon, JavaScript, and Python are all classified as dynamic languages. At the superficial level, the code written in these languages looks quite different, but the semantics underneath, what's being described by the code, is very, very similar. So they actually complement each other really well. The C language, though, is a static language, and also it was designed with very different goals in mind. It's a language generally geared for more low-level programming, like, for example, most of the Linux operating system is written in the C language, whereas, say, you would never write an operating system in Python or JavaScript. Strangely, though, at a superficial level, the way C code looks actually most closely resembles JavaScript. So the syntax which you learn in JavaScript actually helps prepare you to learn C. Though I should note the semantic differences between C and Python on JavaScript. Yes, C is a static language designed for quite different purposes, yet there really is a common set of concepts that are shared between all these languages. So it's not like the concepts you learn in JavaScript in Python don't carry over when you learn C. The basic essence is still there, just with some twists and some new complications. Lastly, the Java language, not to be confused with JavaScript, despite the name is really a totally separate language. The Java language, like C, is a mostly static language, and it sort of hovers in the middle ground between the low-level programming of the C language and the high-level programming of languages like Python and JavaScript. Java is actually the one language here you can skip if you don't want to bother. I include it because it is one of the most popular languages out there, but also because Java represents a certain approach to object-oriented programming, which you also see in a language called C-sharp, which, confusingly, is not really like C all that much. It's much closer to Java. And the object-oriented approach to Java also quite resembles what you get in C++, which also, confusingly, is a language that was based off of C, but added some features for object-oriented programming. So learning Java is not just useful for its own sake, but it also, I think, is helpful if you want to get into learning C++ or C-sharp. You could, of course, just learn those languages directly, but I think Java is actually the better starting point. Now, in my coverage of these languages, I attempted to cover them as comprehensively as possible that is not leave out any details or features because I know from my own experience how annoying it is to learn a language, say, from a programming book and then go out in the real world and encounter actual code in that language and find all sorts of examples I can't understand because they use features which weren't covered in the material I read. That can be extremely frustrating because generally when you look at code and there's something going on which you don't understand, it can be very hard to try and find that explanation for what you don't understand by doing a Google search because you don't know what to search for. So comprehensive is good. On the other hand, when you're learning, you really want to learn those things which are essential first without any distractions of all these other complications. So the solution I hit upon is that in the videos, I will cover mostly those things which are really essential. Anything non-essential for your understanding of how the language works, they get punted into other material, like, say, into the notes that you'll find linked on the site. At the very least, when there are aspects of these languages which I don't cover, I try and be very clear about which things I've alighted over so you can go and look them up yourself. More generally, when I make these videos, I always have in mind this distinction between concepts and particulars, whereas what I call a particular is just a factoid. It's just a piece of data you can memorize by rote. A concept is not just something you can read and memorize. It's something you have to actually understand. And while it's true that learning a whole bunch of particulars is difficult and learning programming involves lots and lots of particulars you have to learn, the nature of particulars is that they are much easier to learn when you have some conceptual framework on which to latch them to. Particulars in themselves just tend not to be very interesting. So quite often, someone could say a particular thing to you dozens of times and you would still forget it. Concepts, on the other hand, while much harder to absorb, once you get them, they're much more memorable. So my basic approach is that concepts always come before particulars. So the question then is, how do you best present concepts? Well, my theory about this is that there are three of what I call modes of exposition. Basically, three different ways of laying things out there. And I call these different modes reference, tutorial, and narrative. The reference mode is fairly self-explanatory, reference material are things like dictionaries, the sources, encyclopedias, charts, graphs, lists, basically anything which is a big dump of information, a dump of particulars. A well-designed and written reference, of course, is very useful. It's easy to navigate. You can just go directly to that one thing you want to know and you can find it clearly stated. So good reference material is obviously very useful to learners and in fact it's useful to everyone, even experts. When learning, what you obviously don't want is someone to just dump reference material on you and expect you to cope. That's not very helpful. So the real choice is between the other two modes, which I call tutorial and narrative. The way I define tutorial is that it is the mode in which you take the learner by the hand and you walk them through some example. In some cases you might have the learner themselves go through the steps as you go through them. Other times you might just have them watch. I consider it a tutorial. In the narrative mode in contrast, you're not laying out some practical example. Rather, you're simply trying to convey the concepts directly. I call it the narrative mode because generally with concepts you have explanations of why. Why does this work the way it does? What are the alternatives? And so with concepts there's generally a story there. Not a story with dramatic action or dramatic characters in most cases, obviously. But still a kind of story. You can lay it out piece by piece and follow along potentially with interest. Particulars just aren't like that. Maybe individual factoids can be in themselves interesting. But if you just string them together and it's a bunch of non sequiturs, there's no narrative there. Whereas when you understand a concept for the first time, you have this sense that the pieces fit together because that's the way they must fit together. With particulars you don't get that sense, and everything in itself just seems sort of arbitrary. Put simplest though, the distinction between narrative and tutorial is that in a narrative, the instructor or the author is actually trying to figure out how to actually convey concepts. Whereas in tutorial, the instructor or author is just pointing the student in the right direction. They're putting an example out there and effectively expecting the student to figure out the concepts themselves. Of course if we're talking about a pure tutorial, most material out there tends to be a mix of tutorial and narrative. Tutorial and narrative are best when kept as separate from each other as possible. And secondly I contend that the proper balance between narrative and tutorial is a two phase process where the student always starts off with narrative material and then later reinforces what they learn in the narrative via tutorial. So generally tutorials should not be introducing any new material. Certainly not any concepts. You can get away with introducing a few particulars in a tutorial, though even then it's something you want to avoid if you can. So actually the motivation behind this whole series is that I felt that all the material out there that I had to use when I was learning programming mostly on myself, mostly from books and so forth, what I found generally deficient is that almost everything out there not only mixes together tutorial and narrative willy-nilly, it tends to rely heavily upon tutorial as a crutch. And the main explanation for this I think is quite simple. And that is generally that tutorials are generally easy to create. Tutorials done well are very, very hard. In writing a tutorial if it's a topic you know about the only real hard part is coming up with an example to use something to walk the student through. Once you've settled upon an example assuming it's something that you yourself know how to do easily enough the tutorial then almost writes itself you just go through all the steps one by one you pick your starting point and the end point and then you just fill in all the gaps. When writing a narrative in contrast it's very hard about all the pieces you're going to present which order you're going to present them in and how precisely are you going to present them in particular what precise language are you going to use that will convey a concept without falling back on just presenting some example to which you can just point and grunt. So I hope that gives you some idea of why the videos are the way they are in particular why they tend to very densely focus on conceptual material rather than practical examples as of yet this whole series is not a practical course in programming even though I will contend it's the most efficient way you can go about learning the program. What's obviously missing though at this point is the tutorial material because as many bad things as I said about teaching with a lazy reliance upon tutorials I think tutorials yes really are a necessary part of learning because once you go through these videos I think you'll find it very easy to understand the concepts as I present them but without more practical tutorial material to supplement the danger is that you'll have trouble retaining and also you'll have some difficulty actually applying it you'll sit down to program and you'll really still feel like you don't entirely know what you're doing that's just inevitable until you have some practice of some actual programming you just won't feel comfortable and you really won't be able to call yourself a programmer So as it stands my expectation is that you'll go through this series but you'll have to look for more practical material elsewhere to supplement what you learn here Once I have videos for the two or three topics I haven't covered yet but I think it is to begin supplementing the narrative material with more practical oriented tutorial material I probably won't get around to any of that stuff though until maybe around the end of 2012 In the meantime if you have feedback or questions they're greatly appreciated you can leave them as comments on YouTube or look for a link to the discussion group on thecodeschool.org site