How Should I Teach a Basic Programming Course?
riverman writes "I have been 'provisioned' at the school where I work to teach a new Computer Science/Programming course. I'm supposed to be teaching everything from the very-very basics (i.e. where that myspace thing is in your computer monitor, and how it knows who your friends are) to the easy-advanced (i.e. PHP classes and Python/Google App Engine). I'm an experienced programmer, but I'm not sure where to start — I could easily assume that my students know something basic they don't. Are there any resources on the internet that could help me find a solid curriculum? What are your suggestions?"
I'm sure many of us have gone through intro-level programming courses of some sort; what are some things your teacher or professor did that worked well, and what didn't work at all?
Computer basics, ie how to use the web, and computer programming do not belong in the same course. People in the audience for either will not be happy with the other.
Don't teach things in 'the abstract'. Give them a task to accomplish that needs particular 'features'.
Then the next 'task' adds more 'features', but doesn't drop the earlier ones learned.
And don't make the tasks abstract either. "do a bubble sort" would qualify as too abstract. While "collect 5 client names from the user and sort them" wouldn't.
---- Booth was a patriot ----
You have to taylor the content to the audience.
Not knowing what age range is your audience makes it difficult to give you concrete
advise.
Avoid the history of computers, most young people (i.e. everyone under 40!) finds
it boring and in reality it is useless.
You can use Scratch as a great tool to introduce
programming concepts without the boring theory.
In general, do not bore your audience, that's the secret.
Be very, very careful what you put into that head, because you will never, ever get it out. - Cardinal Wolsey
1) Teach them to understand that a computer does what a computer is told. So as a class building exercise get them to "program" a robot in pseudo code. You give them a fairly complex assignment that involves decisions. The test in this is that you the teacher are the robot. And the students who thought of this as a joke or simple assignment will quickly realize that garbage in garbage out means something.
2) Do the assignment again, but this time add "testing" routines. Make them write little assignments, that are assembled into bigger tasks. Show how this could be a "test driven" environment. You teach the robot little things, and then those things are assembled into bigger things. This teaches them components, modules and test driven.
3) Take all of that knowledge and apply it to a programming language. I personally would choose something along the lines of python and ruby. They have enough problems and they need a quick turn around.
4) Teach them about OO by introducing them to a programming language like C# or Java.
5) Finally teach them functional
Though I would stress team exercises thus giving them the benefit of XP (Extreme Programming) type training.
"You can't make a race horse of a pig"
"No," said Samuel, "but you can make very fast pig"
...my first class in programming: the teacher wrote "x=x+1" on the blackboard, and my reaction was "Huh? That is unsolvable!"
So, one of my friends in college did his senior research on alternative ways to teach introduction to programming and gave a very convincing argument for teaching it with Python and Blender (the 3D content creator). Blender allows you to use the Python programming language to set everything up and manipulate the objects so they learn programming, but it's a lot more satisfying. For example, what's more fun: reading input from stdin and saying if that integer is divisible by 3 using % or creating some 3D objects and moving them across the screen in a specified way?
Maybe someone else has a better idea, but I thought I'd share
This was a recent topic on stackoverflow. There are some really good suggestions there.
Find Steve Drasner. He's a Computer Science professor at Northern Virginia Community College in Annandale.
His intro to programming class starts at the bottom, teaching only pseudocode without the use of computers whatsoever. After giving the students a good grasp of concepts of structured programming, he uses it to segue into the concepts of object oriented programming.
I took Java prior to Drasner's class and, while I understood most of what I learned, I never quite understood the purpose of OOP/D until I took Drasner's course. Everything snapped into place.
http://www.nvcc.edu/home/sdrasner/
Viable Slashdot alternatives: https://pipedot.org/ and http://soylentnews.org/
You could check the Stanford Engineering Everywhere program's resources. They released some great beginner level programming courses under the Creative Commons Attribution-NonCommercial-ShareAlike 3.0 Unported license. Those could be adapted for teaching the subject to students, and the content used for instructional material.
I attended a fascinating talk by Mr. Vern Ceder at the past PyCon (Python Conference) on teaching programming to secondary students. You might review his papers from that and other conferences, and email him for advice (see linked page).
As a college student currently enrolled in an introductory java course, what I found particularly interesting was the initial teaching of really basic HTML and its tags to introduce the idea that programs need to follow a rigid syntax for them to function. Although I already had previous knowledge in Java and understood this, the rest of the class seemed to benefit from the way that the class was introduced. Regardless of the language, the professor can then go into basic programs for the target language (Java, HTML, Ruby, etc.) and build from there.
Thinking back (waaaay back) to my first programming class in HS, there are going to be two kinds of students, those who have an active interest and those who do not.
The ones with an active interest will just need a little bit of "fuel" and point them in a direction and let them go. For these students you can show them a quick demo, tell them where to find more information, give them a project, and all you need to do is be available for questions. Too much guidance or restriction will either bore them or make them frustrated.
The other kind, lets say they have a passive interest, might be curious but maybe they don't have the same motivation as the others, so they will like to see many demonstrations, and have hands-on exercises where you guide them through something. I don't know if the active and passive interest students could be taught effectively in the same class.
I Heart Sorting Networks
If you are covering more than one language in a "basic programming course" then you are already off mark. Now if your goal is to do more like a survey of programming languages, or an introduction to programming languages, then it is appropriate to explain why there are different languages, the types of languages, why languages are used in specific roles, etc.
If you are truly teaching programming, as in at the end of the course the students will be creating programs that do things, then you need to stick with one single language and development environment. Otherwise, every time the students begin to grasp the language and how it is invoked you are switching to something entirely different.
Better known as 318230.
Don't teach BASIC.
Scariest title ever.
Faster! Faster! Faster would be better!
When I first learned to program, I remember the teacher asking us how we got to school that day, in as minute details as possible. Example: awaken, open eyes, elevate torso, rotate 90 degrees, bend legs until they reach the floor, stand, walk to bathroom, etc.
From there, you can explain the concepts of procedures to compartmentalize the code. Brushing your teeth may take thousands of steps, yet cut down dramatically with looping, etc.
While it starts out as a new way of looking at how computers process the steps in a more methodical sense than we do, it soon becomes a way to introduce functions, procedures, and other syntax in a practical sense.
The majority of people - even those with college degrees - have a difficult time with logic. Something as simple as an if-else construct can be very confusing to the average person at first.
And there's another twist. About 40% of learners can understand and manipulate abstract concepts, and learn them without any practical experience whatsoever. The other 60% require experiential learning - they have to do before they understand. Fortunately, computers can very easily demonstrate concepts such as if-else...
And how computers work is a mystery to most people. Before you start the course, you should come up with a simple mental model that you can use to explain how a computer works to someone with absolutely no understanding of electronics, logic, etc... For a basic programming course, you should first assess class understanding:
For most programming courses, you should not even assume your students understand how to use the compiler. Furthermore, you should probably come up with a series of simple examples which demonstrate your point without any extraneous code. Because most people learn by doing, one of the first exercises should be to build a simple "hello world" type of application to familiarize themselves with the build tools.
And have fun! Come up with interesting problems. Your students will most likely spend most of their corporate careers doing boring stuff, so they'll appreciate the chance to do fun things like games.
The society for a thought-free internet welcomes you.
I was not a comp sci major (a physics major), but I took comp sci classes, and am self-taught in compilers, language theory, and everything else I know about computers - including the hardware level, like the majority of people in the field. Looking back on the courses I did take, I feel that they left out a discussion of the flaws in the current paradigms. For example, the failure of the core von Neumann model of computing to address the problems of parallelism. The failure of procedural languages to enable intentional decomposition so that one can be sure a program is correct. The failure of OSs to be secure, and why that is. People think this technology is mature. It is anything but. The situation we are in has to be transitional, or we are in "deep sh**". While teaching them how to hack in the current languages (one can do no better than that), give them the message that this stuff is fundamentally broken, and that something better is needed.
As a starting point, I suggest this (draft) paper, because it's interesting, and short, flippant, and gets you thinking. The Camel has Two Humps
Belief is the currency of delusion.
HTML in a basic text editor is a great place to start. It teaches how to open and close tags and the importance of correct syntax.
You can also make it more complex by adding CSS or Javascript which resemble real programming.
Former teacher here. I was in a similar situation. Here are some pointers:
* Go low level. Dedicate a lecture early on to bits and bytes and how binary logic becomes maths. The students don't need to know how to build a processor, but you need to dispel any notions of magic from the bottom up. Without some understanding on this level, computers will forever seem slightly magical. (Keywords: Relay, light-switch, bit, byte, register, instruction, Assembly, bus, ram, hard drive.)
* Build upon the previous and explain digital audio and more importantly, graphics, as examples of how the numbers become sounds and pictures. (Bitmaps, graphics memory, sample rates, bit depth.)
* Operating systems. Students should know which ones are out there how they differ and what they have in common. (Driver layer, process, program, gui)
The more you put into these steps right away, the easier it will be to teach programming. Also, it tends to equalize the student pool. I put it into two two-hour lectures, but you may want to be even more through.
Proceeding from there depends a lot on what the goal is, but for programming, I found that interwoven lectures and exercises with support time (teacher/TA in the computer room) usually works the best.
One of the issues I had when I was in school is that the computer classes were radically changed as I progressed through my grammar/middle/high school career.
In 3rd and 4th grade, we learned LOGO on some old Atari computers and were basically taught about pixels and where home row was on the keyboard. It was all very simple to grasp and we did a lot of projects (drawing pictures in logo) that required us to use the keyboard a lot.
In 6th grade, we had a BASIC class (not Qbasic, not visual basic... straight BASIC) on PCjr systems where we learned how to draw shapes to the screen and were taught the basic ideas behind computer resolution, very simple loops, how to print text to the screen, read input and use if/then. We also learned what input and output devices are and the names of the various computer parts (monitor, keyboard, printer, etc).
I liked those classes and they went at a good pace which was great because I was the only kid who had a computer at the time (this is like 1991/1992) and everyone seemed to get what was going on and it was great. When I got to high school, there was a VisualBasic class which had a pre-requisite of Intro To Comptuers. I opted not to take that since not only did I have a computer for my whole life, but I also had the previous classes. When I talked to my guidance counselor, he said that the intro to computers class was just a typing class. The visual basic class was not a programming class... it was a class that teaches you the basics of computers (what a floppy is and how to print) and then ends with showing you visual basic.
I opted not to take either class.
My senior year of HS (98/99), they added a c++ class which I managed to sign up for by talking to the teacher and showing him that I already knew a little C++ and already knew computers better than most others (I would have had to take intro to comptuters and the VB class, otherwise), but that class wound up spending half the year teaching about how to use a web browser and what the difference between RAM and ROM is before we even got to 'cin' and 'cout', and that's all we ever did.
So my advice is to spend very little time on the basics of computers in general and dive right in to projects that get them applying what they do know to do things that they want to do. Also, use a language that lets you dive right in. Java is a programmer's programming language. New programmers never understand it because it requires so much up-front knowledge to even understand what a simple hello-world app does. Especially if they are coming from visual basic or something similar.
I think that C is the best beginners language out there. It's very simple. It's super straight-forward. There's a ton you can do with it right out of the box.
PHP may be another good beginner's language, too, since the web is what most people use the most when they're on a computer and it would enable people to show off what they've done. It would also spark much more interest than C, especially since building a C app to work in windows isn't really a piece of cake... although programming in windows, in my experience, has been very difficult... there's a limited amount of free tools and it comes with virtually nothing built-in for that.
...spike
Ewwwwww, coconut...
Start off without a computer. At the basis, computers are sequential, even if some other from is used in the programming. Students must be able to break processes down into steps. They will invariable create ambiguous steps or leave steps out. Act out the process to show the missing steps. Use humor show undesired outcomes. Kids tend not to fully comprehend cause and effect, sequential logic, and the like. They tend to want to told a process, then apply the process mindlessly. The creativity and flexibility at the basis of programming a computer must be taught. At this point language only limits the students options, so it is not necessary to worry about that yet.
Second, the student must understand the limitation of a computer, and how they function. A sideline into binary math and boolean algebra is useful to teach these limitation, and get the student to think on this detail. If an AOI circuit simulator is available, this can be used to teach these limitations, as well as get the students used to using the computer in a product creation manner. This last bit is important, because many students have never used a computer to create anything significant, and don't really understand that this is what many professionals do. They know how to use proxies to bypass security, but not how to load an IDE to create a program. Many can't even comprehend it, and play with their proxies not understanding that there is something else they could be doing.
This is a bit abstract, but computers do work in the abstract, which is why CS majors, and scientists, engineers, and math people tend to earn a premium. Such people can think in the abstract, and they can not only because of innate ability, but because they were taught to. Teachers that shy away from the abstract because the kids complain and it is easier not to are leaving out a part of the educational process. But use concrete examples to keep the abstract grounded in something the students can relate to.
At this point, when everyone is familiar with the computer function, some time can be spent detail the general workings and components of the computer. I have seen children as young as 9 forced to memorize, rote, the names of each part of the computer, and match the name to the part. I have seen high school kids repair computers with a high level knowledge, not quite knowing how everything really fits together. I don't know what level of detail is necessary for computer programming. They should now what a computer is, but I would not formally assess or punish the lack of rote memorization.
At this point, it depends on what is to be taught. Something like Alice can teach OO concepts in a very accessible and high level manner. Since most everything is moving towards using a high level API with short bits of glue code, this may not be such a bad choice.
If actually programming is to be taught, I would not use an overly complex IDE or language. The basics need to be taught. for instance, to switch values i=j; j=i does not work. Variable scope is important. How one passes parameters is important. Global variable can be very bad. That sort of thing.
At higher level, creating reliable contained data structures is always a fun topic. Write a web engine or a word processor is now a well known problem and can be handled in a year. If there is a science or math component, well formed solutions to such problems are also quite instructive.
A key thing that is often missed in debugging. Give students time to debug their work. Don't cave to the crying. Let them help each other. Assessment is best done in their ability to fix a bug, rather than sketch out a section of code or a data structure.
And of course project based and group learning is the soup du jour. As mentioned, it is possible to have the students write a si
"She's a scientist and a lesbian. She's not going to let it slide." Orphan Black
We need to change the stereotypes of future generations of programmers!
The CB App. What's your 20?
The simpilest example I can give you to use is the making of a peanut butter and jelly sandwhich. Bring loaf of bread, knife, jar of jelly, and a jar of peanut butter to class and ask the class for instructions on how to construct the sandwhich.
statements like 'put the peanut butter on the bread' would result in taking the jar of peanut butter and placing it physically on top of the loaf of bread. Similarly, the statement 'add the jelly' would mean moving the jar of jelly onto the pile you've created. Until the students understand that each (and every) step must be stated, they won't correctly grasp the concept of what programs do.
Jerry
"Software is the difference between hardware and reality"
Maybe now that you are in teaching, maybe you should have a look how others do it, here is an example:
http://groups.csail.mit.edu/mac/classes/6.001/abelson-sussman-lectures/
I've been watching these for a while now, I liked them (although to much beginner for me, it's a nice way to get to know a 'new' language).
New things are always on the horizon
I've taught introductory programming several times. I never thought that my goal was to teach a skill, or an abstract concept, or logical thinking. My goal was to convince the students that programming is fun and easier than they thought. If I succeeded, my students would run out of the class saying I CAN DO IT!
To capture their imaginations, I used Visual Basic. I taught them how to draw a ball on the screen, how to make it move, how to bounce it off the wall, and finally how to turn it in to a kind of Pong game. I can take a group of random people off the street, and teach them to make their own Pong in about 3 hours.
Graphics and motion are much more emotionally appealing than any kind of abstract logic. It also presents them with the opportunity to analyze symptoms to debug their own programs. They are better able to grasp the relationship between incorrect behavior and incorrect programming when the subject is graphics and motion.
Something fun like Pong, also teaches the students that programming is a means to an end, not the end itself. The interesting part is clearly what happens with the ball, not what the source code looks like. Later in more advanced courses, a subset of the students might become entranced with programming as an intellectual end, and go on to become software professionals. Good for them.
For those who never do become professionals, they at least grasp that,given a lot of work and common sense, one can create source code that shapes and steers behaviors in the run time. Never again will they think of software as some kind of incomprehensible black magic.
Let's face it, most programming languages suck from the point of view of teaching. Python's pretty cool, but the syntax has lots of special cases and many, many weird (but useful) language features, all of which are confusing. Ruby ditto. Java is useful but unspeakably complex. C++ is even more useful and even more unspeakable. C requires you to be anally retentive. Basic is a crime. etc, etc. If you pick any of these, you end up having to teach the language, rather than teaching the abstract concepts that underly the language.
My university got round this by designing their own custom language, S-Algol, and all the algorithms courses were done in it. Of course, it didn't help that it was a weird, half-implemented language (a garbage collected language with no actual garbage collector!) with lousy error detection (anyone who knows it will remember, and shudder at, the phrase 'void and void are not compatible in this context') and a half-assed IDE (the only editor I've ever seen where you had to move the cursor with the mouse. Yes, the arrow keys didn't work).
If you want an existing language that's powerful enough to teach proper algorithms and yet simple enough for novices, you could do a lot worse than Logo. Yes, yes, stop laughing. But underneath the cute turtle interface it's surprisingly powerful and rather deep: it's best described as a stealth Lisp.
Logo's biggest problem is that when it was introduced and heralded as the best thing since sliced strings, most affordable computers weren't powerful enough to actually run it; I remember Acornsoft Logo on the BBC Micro, running a Prolog-alike rules database, where a simple query took several minutes. Since the only thing that would reasonably run on a Logo on one of these machines were toys, Logo itself became known as a toy.
But if you have another look at it today, you might be impressed. Okay, the syntax is a bit weird in places --- particularly when it comes to local variables --- and there's no object oriented system (although it's pretty much trivial to write one), but it's pretty much ideal for teaching basic concepts such as conditionals, iteration, abstraction, data structures, etc. And that bloody turtle gives instant gratification, making simple programs considerably more interesting than they would be in, say, Python.
These days, you still won't find a better introduction to the utter basics of what computer programming's all about than the hoary old Logo tutorial. You know: "Let's move the turtle around! Let's draw a square! Let's make a procedure that draws a square! Let's draw several squares! Let's change the procedure to draw different sized squares!" That one.
When I was in 6th grade, computer class used Apple II's and we learned out of the Kids and the Apple II book, which took us through the basic language from the ground level and, looking back, I think it did a decent job of teaching us programming concepts in a fun way. I think this background gave me a good foundation of programming that helped me even through college C++ classes.
But I'm not writing to specifically recommend that book, but to share my observation about that time period of learning. Sure, we had our share of boring calculator programs, and I wrote a fair amount of spaghetti code, but the most fun we had was when the teacher assigned us to write an adventure game, in the vein of choose your own adventure. Since textual and graphical adventure games were what we liked to play at the time, it was a real thrill to be able to try to create even a pale imitation of them.
But then things got too complicated. Games got to good so it wasn't really possible to imitate them on a low level. If you learned C or C++ in class, it was really difficult to create games or GUI apps without learning all these other tools and platforms. Programs had to be compiled and took all the immediacy out of trial and error programming.
Years later, when the web came along and everybody was hand-coding or frontpage-ing static HTML pages for their "homepages," I never got into that. I knew that the professionally done sites like yahoo or amazon weren't using static HTML but had server generated pages. When PHP finally came around with the ability to programmatically generate web pages, I felt a thrill just like back in the BASIC adventure game days. I could create media the same way those "in power" created it.
Today's kids are voracious consumers of media, but they like to create it too. Whenever tools come along that let them create media "just like the pros," they jump on it. For example, when CD burners came around, everybody made mix-CD's just like the compilation CDs sold commercially. When sound and video editing came out, kids jumped on that, first using DVD burners and then YouTube.
Following this observation, kids nowdays live on the web. To them, Facebook is professional media. If they could create dynamic sites like Facebook, they would feel the thrill of creative programming and be able to connect with the reason for why people program computers.
For this reason, I think one of the web-oriented languages like PHP or Ruby is a great way to introduce programming to students. They can build pages like what they use and see the results in their web browser immediately without compiling and feel the thrill of creating again.