PDA

View Full Version : Need "awesome" programming problems




jctj
Jun 18, 2013, 12:06 PM
I am going to be teaching an Intro to Computer Programming class next year in High School. I am looking for examples of motivating problems to give the kids. It is easy to come up with something everyone hates, but there seems to be certain problems whose solutions are interesting enough to gain and keep attention, and whose solutions are hard enough (but not impossible) that there is real pride when the solution is found. I am looking for problems that require for their solution learning how to use various programming tools or ideas, from complete beginner (loops, if-then controls, variables, arrays) to beginning OOP.

Can you please tell me of computer problems you had to solve (lol - not bugs, not OS updates....) when learning to program that you really remember as being motivational? Please include which language (BASIC, Pascal, C, C++) or simply what type of language (Spaghetti, Procedural, Object-Oriented).

For example: my "become a geek" moment was in 7th grade when my math teacher challenged the class to figure out 2^64 - EXACTLY. Yes, we all grabbed our calculators (as he knew we would) and got an answer, but we then had a discussion on rounding errors, digits of accuracy, etc. This was back in 1980, so clearly what he was expecting was for us to do the multiplying by hand. Being stubborn and having just learned BASIC on an Apple I or Apple IIe (can't remember which one we had at that time), I was determined to figure it out with a program. It took over 4 hours - multiples of what it would have taken to do it by hand... - but I finally got it perfect so that it showed commas and leading zero's where it needed to. The very first thing I did when I downloaded Chipmunk Basic (Old-style BASIC compiler for Mac - in preparation for my class) was to replicate this program (this time in just 30 minutes, lol). It was amazing to me that, some 33 years later, I could still remember the approach, the problems encountered, and the solutions to those problems. As a teacher, I would call that problem a "significant learning moment" but just because it was significant for me doesn't mean it would be significant for anyone else. So.... I need to know what sort of problems created significant learning moments for all of you, so I can present multiple problems to my class.

Thank you in advance for your help!

James



chown33
Jun 18, 2013, 12:42 PM
What programming language will you be teaching?

I ask because there are some important fundamentals that are frequent hurdles, and they vary somewhat by language. In C, it's pointers, the array/pointer relationship, and structs. I'd also include unions, but that's more advanced than an intro. In any OO language, it's the class/instance dichotomy, inheritance, and overriding.

In any language, there are fundamental structural patterns, such as linked lists. A singly-linked list is a good choice for C, as an exercise in ptrs and structs. Simple example: read an arbitrary number of lines, then put them in sorted order by length. A book worth looking at is "Algorithms" by Sedgwick (there are language-specific versions). It's clearly written and has good diagrams.

kubaw
Jun 18, 2013, 12:46 PM
No awesome issue here, but a little tip: instead of jumping onto OOP focus on pointers and recursion first. For me understanding pointers was a milestone in learning programming as an amateur. Years later I was able to win a micro-contest in my class for a fastest solution to count distinct words in a file. My choice of pure C with binary tree was twice as fast as second program, that was using C++' STL. :cool:

960design
Jun 18, 2013, 12:47 PM
Deitel and Deitel How to Program comes to mind. It had pretty awesome end of chapter question / quizes and some AMAZING programming exercises.

Elevator, Tower of Hanoi, ect.

ArtOfWarfare
Jun 18, 2013, 01:44 PM
I personally hated the tower of Hanoi and I'm pretty sure most students just look up the answer rather than figure it out.

Writing a sodoku solver is pretty challenging but rewarding.

I'd suggest looking through TopCoder's algorithm match archives. They often have interesting problems for a variety of skill levels.

estorstenson
Jun 18, 2013, 02:09 PM
Honestly, I fell in love with computers because I wanted to write games. I was probably 13 or 14 when I got my little Texas Instruments computer and it's extended basic cartridge. I would say within a year, I was animating sprites and had written a little star wars rip-off (remember the old atari star wars game?). They were simple and totally amateur, but I loved it and spent hours reading the reference guide to learn how to use new functions.

You could very easily find a language where the kids build a simple game step by step over the course of the year or semester. Maybe start off learning to position characters on a screen for one assignment (you could have them use for loops to repeat the character, use a 2 dimensioned array to determine positions, etc). Then load in information from a file which is used to position stuff on the screen, etc. All the way until you have a simple pursuer type game with obstacles and goodies to be collected. AI can be super simple, such as a pre-determined path for the "bad guys". You could even provide them the input files for these, leaving it strictly up to them to write the logic for both parts. Key stroke input is pretty easy to learn in any language.

Python and probably lots of other languages have some open source graphical interfaces which you might be able to use to allow them to manipulate simple graphics instead of ascii characters. There are lots of decent looking trees, dragons and stuff available online that you can freely use.

They'll probably make fun of the game they created, but I bet they'll have a lot of fun watching it take shape.

ChristianJapan
Jun 18, 2013, 03:24 PM
Writing a sodoku solver is pretty challenging but rewarding.

Agree on that one; did it once in JS. Was really fun and something I always wanted to do.


Another one: Game of Life;with an interesting start screen like moving across the screen or some "violent battle"

jctj
Jun 18, 2013, 03:47 PM
What programming language will you be teaching?

I ask because there are some important fundamentals that are frequent hurdles, and they vary somewhat by language. In C, it's pointers, the array/pointer relationship, and structs. I'd also include unions, but that's more advanced than an intro. In any OO language, it's the class/instance dichotomy, inheritance, and overriding.

It is an Intro class designed to prep kids for AP Programming the following year. Some teachers simply go straight to Java even for the Intro class, figuring there is no need to use out-dated languages. As someone who grew up with all those changes, I would like to have kids have a (granted - small) understanding of how we got where we are now. I don't teach how to use a slide rule, so at some point there really needs to be a cut-off, but here is my very basic outline:

Option 1:
BASIC: input-output, program control (If-Then, switch (case), etc.); loops (For-While-Do), variables (types, representation), and arrays. I will introduce subroutines (goto and then gosub) as a segway into a procedural language.

Procedural: using functions/procedures to clear up the confusion of spaghetti code from BASIC. Not sure which language to use. C is the obvious choice, but I fear for an intro class this would be too involved - all I really want to get at are procedures and pointers. Linked lists are fundamental, but I am nervous about how long that will take kids to work through - the concept is easy, but getting kids to really develop the ability to work with linked lists (and the dreaded sorting routines...) seems to be a major hurdle and may eat up all my time. This could literally be a 1 or 2 class lecture where I just tell them about it, but we do not actually use any procedural language.

Java: Since the AP Programming is all Java, the sooner I introduce this, the better. Here is where I would address the notion of why we ended up with OOP and its pro's/con's. This is the language/syntax/formatting I want them to really remember moving on. They will be well informed that if they choose Computer Science in college, they MUST learn C, C+, and then C++ as the basis for all other modern languages.

Option 2: Start with BASIC (as above), then ignore Java, and just go C => C+ => C++. That way once they are done with BASIC (with its, what, 20 commands?!?) all they need to memorize for a language, syntax, formatting, etc., is just C. If they learned C, C+, and C++ picking up Java the next year should be a snap.

Thoughts?

ghellquist
Jun 18, 2013, 04:06 PM
Things that move...

We did an elevator in Lego with three stops and buttons to summon th cage at each level.

What really got me hooked was programming a xy-plotter to write text.

Gunnar

jctj
Jun 18, 2013, 04:19 PM
So far, plans are:
(1) 2^64 question as in OP
(2) Towers of Hanoi ("just look up the answer" concern noted...)
(3) Soduku
(4) Bubble Sort (not going into all the sorting options, but great for linked lists)
(5) Game of Life


Areas to Research:
(1) Deitel and Deitel How to Program
(2) TopCoder's algorithm match archives

The "Main Event" I am planning is BattleShip. To the extent practical, I would like to introduce this as early as possible (in BASIC) and then continue to re-visit the game with procedural (if done) and OO versions. The general concept is that I write the interface and each student or team of students writes their own AI for both placing the pieces and making shots on the opponent. Then we can play AI vs. AI - best of 1001 games. Done properly, we could even have the final battle of the top two AI's done in front of the school at Assembly on a projector screen (school of only 300, so yeah, we can do things like that here...) - with the winner(s) getting guarantee A's for the semester.

I haven't written all of these programs myself yet because I am still working on which programs to teach, etc. Some of this may be a bit over-ambitious, but Battleship is a game that can be programmed very simply (hard-wire placement of ships, shoot every-other square until you win or lose, shooting every adjacent square when you hit something until it is sunk) or very complexly (shooting pattern based on finding largest ship first, then smaller ships, analyzing previous ship locations, analyzing opponent's shooting patterns to influence ship placement, etc.). This one game allows students of all levels of ability or motivation to at least have something to show at the end of the class.

I love all the comments, folks. Even the "hated Towers" comment because it hadn't occurred to me that this had become *such* a standby that kids would simply find the solution on line instead of figuring it out. I loved the Towers problem because I could play the game with a real (physical) set, and *see* how the recursion worked and then translate that understanding to what the recursive procedure was doing.

James

----------

Things that move...

We did an elevator in Lego with three stops and buttons to summon th cage at each level.

What really got me hooked was programming a xy-plotter to write text.

Gunnar

Ooohhhh. I haven't played with it yet (yet....) but the school just got a Maker Bot, and I wonder if there is a way to incorporate that into the course. These days you just upload 3-d files to the maker bot rather than control it directly, but I will have to think about that....

Also, on "Things that move" I remember - can't remember what it was called - a program in 1978 that had you placed in a room with a number of killer robots and some obstacles. You took a move (using the numeric keypad) and then each robot took one step directly towards you. You won by moving in such a way as to cause the robots to run into obstacles and then die/explode/vaporize/whatever. The computer had *no* screen - it just re-printed the entire room after each move on paper - back when we had continuous reams of paper with the holes on the side.... Man, am I old?!?

gnasher729
Jun 18, 2013, 04:23 PM
So far, plans are:
(1) 2^64 question as in OP
(2) Towers of Hanoi ("just look up the answer" concern noted...)
(3) Soduku
(4) Bubble Sort (not going into all the sorting options, but great for linked lists)
(5) Game of Life

Remove "Bubble Sort" and let the kids figure out how to sort an array by themselves. Bubble Sort is quite confusing and unintuitive. I'd think they would divide up 50% using direct insertion, and 50% using direct selection.

Then you can let them measure how long it takes to sort 10, 100, 1000, 10000, 100,000 and a million random numbers. That should be _very_ educational.

And then you can figure out together how you can sort a million random numbers thousand times quicker.

balamw
Jun 18, 2013, 04:27 PM
Remove "Bubble Sort" and let the kids figure out how to sort an array by themselves.

This.

Sort, and shuffle operations are both really interesting problems that have real world tangibility.

Shuffle can be applied to a simple blackjack or poker game.

B

dukebound85
Jun 18, 2013, 04:33 PM
I think it would be alot of fun coding up something and then interfacing it with say a raspberry pi, or a basic pic and circuit board and seeing how your code can actually mechanically interface with things!

Perhaps programming a chip to interface with an LCD screen outputting ambient air temp? or a sensor that detects if a cup is there where a pump will activate and fill?

jctj
Jun 18, 2013, 04:51 PM
Remove "Bubble Sort" and let the kids figure out how to sort an array by themselves. Bubble Sort is quite confusing and unintuitive. I'd think they would divide up 50% using direct insertion, and 50% using direct selection.

Then you can let them measure how long it takes to sort 10, 100, 1000, 10000, 100,000 and a million random numbers. That should be _very_ educational.

And then you can figure out together how you can sort a million random numbers thousand times quicker.

I like this idea - this could easily be turned into a competition between student groups. One of the tasks I am trying to teach them is how to look up information themselves and they will learn more by using Wikipedia (or this forum...) and figuring out what is the best sorting method, etc., than the could ever learn from listening to me lecturing.

----------

I think it would be alot of fun coding up something and then interfacing it with say a raspberry pi, or a basic pic and circuit board and seeing how your code can actually mechanically interface with things!

Perhaps programming a chip to interface with an LCD screen outputting ambient air temp? or a sensor that detects if a cup is there where a pump will activate and fill?

My school also has a robotic's team/class. I know the instructor well so we should be able to figure out some coordination there and have my students work on the software part of their robots. I agree that what you program makes more sense or "comes alive" when you can see the results of your logic (or lack thereof) in terms of things moving around.

ArtOfWarfare
Jun 18, 2013, 05:01 PM
Were I to teach OOP, I would make them work on something that is trivial in OOP BEFORE teaching OOP - let them fail at it completely before you come to the rescue with OOP.

Too many students don't understand why OOP is great until they've experienced first hand the pain of doing it wrong.

Also, don't touch #define, teach const.

You might use the same "do it wrong first" with goto when functions are what is needed. Goto has a single proper use that I know of in C: breaking out two loops in a row (IE, breaking all the way to the outside when control is in a loop in another loop.)

technowar
Jun 18, 2013, 05:07 PM
Arrays? No?

subsonix
Jun 18, 2013, 05:21 PM
Personally I think problems connected to real world applications are the most motivating. Perhaps a search problem, binary search is pretty simple in concept and also reveals the importance of algorithms when compared to linear search. Parallels could be drawn to something everyone is familiar with, like web search engines, although Google use map reduce which is a big ass hash table. :)

For languages I think Python or Ruby are better than basic, because both of them is actually used and they are simple. Eventhough both of them are larger than basic (especially including their libraries) you could restrict your use to a small subset to introduce concepts like, conditionals, loops and so on.

Another interesting language is Processing, which gives instant gratification by creating graphics, and at the same time still have the same basic constructs, loops, conditionals etc. When you get the Processing IDE everything is set up so that you can see the results immediately in the environment. There are lots of examples available at processing.org and since there is also a JS library available you can see it in the browser here.

http://processing.org/examples

ArtOfWarfare
Jun 18, 2013, 09:54 PM
Personally I think problems connected to real world applications are the most motivating. Perhaps a search problem, binary search is pretty simple in concept and also reveals the importance of algorithms when compared to linear search. Parallels could be drawn to something everyone is familiar with, like web search engines, although Google use map reduce which is a big ass hash table. :)

Oh yes, binary search is excellent.

It's also great to compare exhaustive on NP-Hard problems vs. greedy and various other things you can try to do to approximate an answer (although perhaps branch and bound would just go over their heads...)

At the same time though, it's important to teach the dangers of premature optimization. Always write the most legible code possible, first. Only reduce legibility in the event that you can definitively say that the particular spot is utilizing unacceptably large amounts of resources and that another method will do better, and in that case, comment it heavily.

PatrickCocoa
Jun 18, 2013, 10:12 PM
Stay far, far away from object oriented programming.

Stay far, far away from pointers.

Both of those require a level of abstraction that can kill dead any interest in programming before they experience the joy of creating new worlds. Both of my daughters took Java in high school and ran away screaming. One of them later graduated college with a math degree and the other is currently majoring in chemistry, so they're not science/math/complexity adverse.

Stay far, far away from anything that gets in the way of immediate gratification.

What they need to learn is variables, program flow, and simple input/output. This will give them a taste of creating new worlds and the excitement of programming.

----------

My suggestions:
- a guess the random number between 1 and 10 game. The user inputs a guess, the program returns High, Low, or Match! That will take a couple of days. Then have someone else write a program to do the guessing (have them run the programs on separate computers and manually type the guesses in). Someone will stumble on binary search!

- a program that computes the average speed in MPH given the time it takes Usain Bolt to run 100 meters (9.58 seconds) and 200 meters (19.19 seconds). This is a simple input a number, crunch it though a formula, and output it, but that's a building block skill that will be much needed later in their programming career.

- a program that adds up the integers between 1 and an input less than 1000. Then if you want you can casually mention Gauss's solution 250 years ago.

- a space attack game where you shoot either phasers or photon torpedoes, the enemy randomly picks shields or evasive manuvers (each of which have a different effectiveness against the two types of attacks). Or any game where there are two attacks and two defenses.

pianojoe
Jun 18, 2013, 10:47 PM
Another thumbs’ up for Robert Sedgewick’s "Algorithms in C" book. I'd focus on


sorting, because it’s thrilling to hunt down even better algorithms, and you can explain by creating simple yet instructive animations

trees, because they're elegant and magic

Duncan C
Jun 18, 2013, 10:53 PM
I am going to be teaching an Intro to Computer Programming class next year in High School. I am looking for examples of motivating problems to give the kids. It is easy to come up with something everyone hates, but there seems to be certain problems whose solutions are interesting enough to gain and keep attention, and whose solutions are hard enough (but not impossible) that there is real pride when the solution is found. I am looking for problems that require for their solution learning how to use various programming tools or ideas, from complete beginner (loops, if-then controls, variables, arrays) to beginning OOP.

Can you please tell me of computer problems you had to solve (lol - not bugs, not OS updates....) when learning to program that you really remember as being motivational? Please include which language (BASIC, Pascal, C, C++) or simply what type of language (Spaghetti, Procedural, Object-Oriented).

For example: my "become a geek" moment was in 7th grade when my math teacher challenged the class to figure out 2^64 - EXACTLY. Yes, we all grabbed our calculators (as he knew we would) and got an answer, but we then had a discussion on rounding errors, digits of accuracy, etc. This was back in 1980, so clearly what he was expecting was for us to do the multiplying by hand. Being stubborn and having just learned BASIC on an Apple I or Apple IIe (can't remember which one we had at that time), I was determined to figure it out with a program. It took over 4 hours - multiples of what it would have taken to do it by hand... - but I finally got it perfect so that it showed commas and leading zero's where it needed to. The very first thing I did when I downloaded Chipmunk Basic (Old-style BASIC compiler for Mac - in preparation for my class) was to replicate this program (this time in just 30 minutes, lol). It was amazing to me that, some 33 years later, I could still remember the approach, the problems encountered, and the solutions to those problems. As a teacher, I would call that problem a "significant learning moment" but just because it was significant for me doesn't mean it would be significant for anyone else. So.... I need to know what sort of problems created significant learning moments for all of you, so I can present multiple problems to my class.

Thank you in advance for your help!

James

I agree with some of the others that getting to hairy too soon would be a mistake.


My first "Real" program was a simple game for the Apple 2 called Blockade, written in Integer Basic. It was like snake for 2 people, where you tried to box in the other person with your snake, who's tail got ever longer. That would be too much first first program however.

Games are good though.

How about a hangman game, developed as a team?

Simon (memory game, remembering increasing sequences of random notes/colored lights flashing)

A recursive routine for calculating factorials? Easy to write, fairly simple to understand once you get the idea of recursion.

I've also written a prime number generator that used a fixed-sized C array of integers to save the primes it found. It tested each candidate number against all previous primes. It seeded the array with 2 and then only looked at odd numbers.

I then fine-tuned it to try dividing each candidate against all previous primes up to an arbitrary value, and then beyond that value, calculate the square root of the prime and stop checking for prime divisors once I reached the square root.

You can calculate a million primes pretty fast with this algorithm. You could then talk about faster algorithms, and how large primes are useful in cryptography.

You could walk the class through the steps of creating a very naive generator, then talk about possible enhancements (first dividing by all numbers less than the candidate, then only checking against the previous primes, stopping at the square root, only calculating the square root once/candidate, etc.) Measure performance all along the way to illustrate optimizing code.

I've also used a large word list to pick 2 random words as a password generator. With a word list of 100,000 words you get very random passwords that are easy to remember. This has the advantage of being dirt-simple to do and real-world useful. The passwords are often funny.

I also wrote a polar equation graphing program in my trig class in high school and demonstrated it to the class. You had to modify the code to add a new equation, which was fine for teaching (an equation parser is way beyond an intro class.) Requires an understanding of trig.

ianray
Jun 19, 2013, 01:25 AM
The motivation for the original question reminded me of this:

http://worrydream.com/LearnableProgramming/

Fascinating concepts :)

960design
Jun 19, 2013, 06:54 AM
I just picked up a Romo from romotive.com. I have no idea how practical it will be for the app programming club, but I thought it was cute and would look into the API and see what it could do.

I highly recommend greenfoot.org as a way to teach programming to students. It helps students visualize OOP and they will be publishing 'scenarios' within days.

I imagine it could be used as a step off to bluejay and then eclipse their senior year.

hhas
Jun 19, 2013, 03:43 PM
Motivation is easy: every kid wants to make their own games. Those games might be shooters, they might be world builders, they might be social; that'll vary according to individual tastes. Lots of interesting CS-y problems there, like graphics, physics, path finding/AI, network comms, etc. that are considered 'hard' in themselves but these days have extensive library support.

The real challenge isn't teaching students mechanistic details like loops, conditionals, values and variables, nor even how to assemble larger programs using prebuilt libraries, it's teaching them structured thinking, independent learning and analytical problem-solving skills. The most important concept in all of computer science is abstraction (to quote Guy Steele), so anything else you have to introduce before abstraction that is just diverting them from that, filling their minds with distractions and trivia instead of instituting a clear framework for thinking.

Unfortunately, popular languages today (C, Java, Python, Ruby, JavaScript, etc) with their love of special forms draw far too much attention to mechanistic trivia like variables and flow control, encouraging novices to believe that these hardcoded, low-level features are central and unique concepts in programming. That in turn draws their attention away from what's really important, which is the tools and techniques for extending the basic language by adding your own more specific features on top of the general ones already there. (Or, to put it another way: sorry Algolers, but the Lispers were right after all.)

Basically, if you really want to understand the problems with CS pedagogy today, you need to go right back to Papert's work on LOGO and look at how he approached it. Bear in mind that Papert was successfully teaching abstraction to 8 year olds. Of course, he wasn't teaching programming specifically; he was teaching structured thinking and problem solving, and the LOGO language and environment was just a good platform for that.

The original turtle system gets a lot of snark now for being so 'primitive' and 'limited' in features, but that was the point. When the only predefined drawing operations are 'forward', 'left turn', 'pen down' and 'pen up', they are quick and easy to learn and are a direct representation of atomic physical operations so contain no abstract mysteries of their own. Naturally, once users master these commands they want to perform more sophisticated operations, like drawing complex shapes such as a 'house', a 'person' and so on. The obvious way to construct complex shapes, of course, is to arrange the existing forward/turn/up/down words into longer and longer sequences until they produce the required shapes - and in a language like BASIC this is all you would learn to do; thus BASIC creates the impression of empowering users, but really all it does is create unthinking menial drones, like Charlie Bucket's dad screwing the caps on toothpaste tubes eight hours a day.

With LOGO, a student will easily fall into this behavior too as part of their independent learning process, but this is where the educator would step in, introducing the student to the mind-blowing concept that they can in fact expand the existing, limited vocabulary with much more powerful and expressive words of their own. Thus the student is introduced to LOGO's 'procedure' feature, and shown how they can define new words like 'rectangle', 'triangle', and 'circle' as compositions of existing words, so that instead of writing 'fd 100 lt 120 fd 100 lt 120 fd 100' every time they want to draw a triangle they can just say 'triangle' and a triangle is drawn for them. And then they can be shown how to parameterize their own words, so that they can write 'triangle 50', 'triangle 100', etc. to create any size of triangle using the same word. And once they've got the basic principles of word composition then they can create even more powerful task-specific words that do exactly what they want. For example, a 'house' word is simply a composite of 'rectangle' (the front wall) and 'triangle' (the roof above it), and since that's a bit more complicated to get right they can be shown how how to learn by making mistakes, then troubleshooting and correcting them (i.e. debugging).

Along the way, of course, students can be introduced to other useful words like 'if' and 'repeat' which they might find useful. While they are certainly useful, they are not initially essential so can be completely ignored while teaching the far more important concept of word composition, And because the are just ordinary words, not special forms with their own unique and important-looking syntax and behavior rules, once they are introduced to them the user is not deceived into thinking that these built-in words are more important than, or any different to, their own words. Which is exactly as their mental priorities should be: after all, what's of most importance to the student themselves: 'if' and 'repeat', or 'house' and 'tree'?

By the time these learners are drawing elaborate landscapes full of highly detailed buildings of various shapes and sizes, their thinking is much more sophisticated than that of the modern BASIC/JavaScript/Processing/whatever student, who is simply handed a much more powerful 'helpful' language pre-packed with special keywords and syntaxes and libraries full of complex black-box abstractions like 'rectangle(x0, y0, x1, y1)' and taught to plug in numbers.

Basically, it's the difference between teaching a student how to use an existing tool, and teaching them how to make their own tools; and it's a priceless educational insight that's unfortunately been swamped by great waves of cheap but shiny trinkets that offer superficial rewards and the illusion of control while mostly just taking it away.

I posted some comments to similar discussions on a couple months back if you want to read more:

http://www.osnews.com/thread?559172

http://arstechnica.com/civis/viewtopic.php?f=20&t=1202483

You should also get yourself a copy of Papert's Mindstorms and read it cover to cover until these concepts 'click' in your own head:

http://www.amazon.com/Mindstorms-Children-Computers-Powerful-Ideas/dp/0465046746

As to how you fuse those lofty principles with the ugly realities of today's popular toolsets, I wish I could offer some solid advice. But having previously educated myself and others on a 'mainstream' end-user language my eventual conclusion was to go away and design my own end-user language from scratch - which is a project I'm still working on.

mslide
Jun 19, 2013, 03:47 PM
Games. Having students do things like bubble sort and all the typical boring programming problems is a great way to bore them.

My high school programming class was BASIC and we did all sorts of graphical and gaming related things. It was a lot of fun.

jctj
Jun 20, 2013, 02:53 PM
Folks - AWESOME input. It will take me a while to go over them all. It is clear you all put some real thought into your responses and I want give them the consideration they deserve - and some of you gave me a good bit of reading to do....

Knee jerk reaction: Can't argue that games are more fun than hokey problems to solve. The trick then, is to figure out what games require the same knowledge in order to solve them as the hokey problems (which are hokey because they are designed to require very limited areas of knowledge). The problems (or games) are vehicles that get the kids to place I want them (understanding certain concepts) so I can't forsake the destination because the vehicle was "so cool". But, then again, this is just an "Intro" class, so I do have more wiggle room than normal.

Knee jerk reaction 2: Agree 100% that higher-level thinking is the most critical thing to get at. Even a skill such as "Break the big problem into a lot of little problems, then solve the little problems and build up the final answer" is a critical skill/paradigm for programming (and math in general). Math teachers deal with this ALL the time. The debate is sort of a chicken-egg problem: which comes first, the higher level thinking or the language that makes the high level thinking possible? Most of the math we teach in high school is really just grammer, so can we effectively give kids a "high level" understanding of 4,000 years of math development in 4 years without grammar? Or do we need to "speed learn" some grammar and then ask them to really think with it? Grammar is boring AND complex (at times), and that is where kids learn to hate math. If we teach to the high level thinking before the grammar, it goes MUCH slower (though kids enjoy it more) and teachers get accused of "not teaching anything!" If we teach all grammar, parents are happy ("Wow, my 7th grader is already in Algebra II!") and some kids love it, but many are firmly bored and/or lost at sea, thus learning to hate math altogether. Finding a path in the middle seems best, but even that is much easier to say than to do. There are complex issues on both sides of the debate - you can loose kids too by not moving through material fast enough just like you can by moving too fast.

My worst curse of the grammar-first method is that many kids get the skills down great because they have learned the ability to parrot my moves and can memorize procedures well (the classic "A" student). But then we move to "applications" and they freak out: word problems! ZOMG! In my calculus classes even I will have kids getting A's, and then nearly fail the entire course because they just cannot learn to translate the word problem into the language of math before using all their neat math skills. And they would rather shave their heads and run around the school naked than go through the mental process of figuring it out....

However - that said, most of today's parents do not have a clue about programming, so they have no idea if their student is learning a "lot" or a "little", so the pressure is off there. That is the beauty of teaching a class that is not in everyone's historic experience.... (and why I am coming to you all for thoughts...)

I'll post some thoughts after I've had a chance to read about the posts!

Thank you all,

James

hhas
Jun 21, 2013, 02:58 AM
My worst curse of the grammar-first method is that many kids get the skills down great because they have learned the ability to parrot my moves and can memorize procedures well (the classic "A" student).

Reminds me of Richard Feynman's encounter with the Brazilian education system (http://v.cx/2010/04/feynman-brazil-education.html) (from Surely You're Joking, Mr Feynman!). Plus ça change...

MeFromHere
Jun 21, 2013, 08:01 AM
It is an Intro class designed to prep kids for AP Programming the following year. Some teachers simply go straight to Java even for the Intro class, figuring there is no need to use out-dated languages. As someone who grew up with all those changes, I would like to have kids have a (granted - small) understanding of how we got where we are now. I don't teach how to use a slide rule, so at some point there really needs to be a cut-off, but here is my very basic outline:

Option 1:
BASIC: input-output, program control (If-Then, switch (case), etc.); loops (For-While-Do), variables (types, representation), and arrays. I will introduce subroutines (goto and then gosub) as a segway into a procedural language.

...

Thoughts?

If this is really an introductory course for high school students who have never programmed before, I think you've lost 30-50% of them by the time you finish the portion I quoted above.

Is this course a semester or a whole school year?

At first exposure, almost any of the common programming languages are GIBBERISH. The student's intuition is all wrong; they've seen the fantastic stuff software does on their phone, but they're not prepared for how much code is required to do simple stuff. They struggle (literally) to generate 15 lines of code on their own, and are disappointed by the mundane result.

For students starting from scratch:

language syntax is HARD
loops are HARD
arrays are HARD
functions and subprograms are HARD
recursion is HARD^2
anything related to indirection is HARD^2
anything related to aliasing is HARD^2
etc.


Here's the usual way I've seen it evolve for high school students in my family:
They don't get it. They solve the homework problems via google, or maybe google plus trial and error. They don't really understand WHY it "works" when they're done, and they have trouble applying the same concept to a slightly different problem the next day. The misunderstanding accumulates from week to week. They end up hating the whole idea of programming. And these are mostly very bright student who want to do math, science, or engineering.

It was similar when I was a college student. The wash-out rate was nearly 50% by the end of the second semester. The next course (data structures) took out about 1/3 of the remainder -- they simply couldn't cope with "simple" things like singly-linked lists. By the time we took the data structures class, these were (wanna-be) CS majors.

I think the challenge in teaching beginning students is to keep it simple while making it interesting. You can't do that well with "bare" C, Java, etc. If it's simple enough to understand, it's too boring to hold their interest.

You probably need to provide canned code to do most of the work for the problem, at least at first. Limit the early problems to ONE concept each for the students to grasp; you provide everything else as "magic" function calls that they don't even attempt to understand until much later. It will take 2-4 different problems on the same concept before most of the student will "get" it -- that's for "simple" stuff.

----------

Another thumbs’ up for Robert Sedgewick’s "Algorithms in C" book. I'd focus on


sorting, because it’s thrilling to hunt down even better algorithms, and you can explain by creating simple yet instructive animations

trees, because they're elegant and magic


Sedgewick is good. But almost all of it is way too advanced for a first course in programming.

PatrickCocoa
Jun 21, 2013, 09:39 AM
I agree with everything MeFromHere says.

My first program was:
10 PRINT "Patrick is great"

My second program was:
10 PRINT "Patrick is great"
20 GOTO 10

That took about 1/2 hour about 40 years ago. The raw power evident in the second program started me on a path that I've followed ever since.

If I would have had to learn to login to the system, fire up an IDE, create a new project, find where to put my code, think about variables (not to mention arrays, loops, recursion, bubble sorts, etc.) I would have run away screaming.

notjustjay
Jun 21, 2013, 10:50 AM
I agree with everything MeFromHere says.

My first program was:
10 PRINT "Patrick is great"

My second program was:
10 PRINT "Patrick is great"
20 GOTO 10

That took about 1/2 hour about 40 years ago. The raw power evident in the second program started me on a path that I've followed ever since.


Patrick,

I was about to quote your other post earlier in this thread and agree with everything you said (about making a simple number-guessing game, etc.)

Now I see this post and it seems you and I had very similar paths growing up!

My first program was EXACTLY this! Then I added a PRINT CHR$(7) into the mix which, on an Apple ][, caused it to beep endlessly while in the loop. I distinctly remember my third grade teacher wandering over, seeing what was on the screen, and saying "Yes, I can see that. Now please make it stop."

Sadly, she didn't seem to see beyond the annoying sound -- that this kid had broken out of the assignment he was supposed to be doing (LOGO?) and had done something of his own creation. I think she should have been more proud of me. ;)

But I completely agree with the points made in this thread. If this is a class for everybody, for kids who have never seen programming before, then it has to be easy to grasp AND have some kind of immediate gratification. A simple text-based game like "guess the number" (and then the turnaround version, where YOU pick a number and the computer does the guessing) are great starting points. As is LOGO, or LEGO Mindstorms, or anything else where programming leads to a real-world object doing something cool.

OP, I wish you best of luck, please keep us in the loop! I am well down my career as a software engineer at this point but I definitely did consider teaching as a career option, and I think it would be fun to teach a high school programming class.

Aside: Too many schools botch this (like another poster mentioned above); my sister went through some kind of mandatory Java class in her high school, she basically drowned in all the OOP material and will never touch programming again because she's convinced it's super hard.

wrldwzrd89
Jun 21, 2013, 02:17 PM
I have written a TON of games / utilities in various versions of Java SE, all of which are open-source (yes, even the ones that have been discontinued by me). If this heap of source code would help your efforts at all, say for some insights into Java, I'm more than willing to share.

ArtOfWarfare
Jun 21, 2013, 03:05 PM
You probably need to provide canned code to do most of the work for the problem, at least at first. Limit the early problems to ONE concept each for the students to grasp; you provide everything else as "magic" function calls that they don't even attempt to understand until much later.

I like this idea. Provide them a library of functions with API headers, and then as you progress through the course make them revisit earlier projects and have them pull back the curtains on the "magic" function calls by having them write those libraries themselves, possibly adding in additional features to the library in the process.

PatrickCocoa
Jun 21, 2013, 04:04 PM
Patrick,

I was about to quote your other post earlier in this thread and agree with everything you said (about making a simple number-guessing game, etc.)



I agree that people should agree with me :)

Again, the programming assignment has to be easy and provide immediate feedback. You have maybe 10 or 15 minutes to get someone's attention.


Aside: Too many schools botch this (like another poster mentioned above); my sister went through some kind of mandatory Java class in her high school, she basically drowned in all the OOP material and will never touch programming again because she's convinced it's super hard.

Both of my daughters took Java in high school and ran away screaming. Both ended up with math/engineering degrees in college. My conclusion was that Java is just too heavy as in introduction to computers or programming. "Heavy" means too many concepts too quickly.

MeFromHere
Jun 21, 2013, 04:40 PM
More suggestions for the OP...

Read through the threads in this forum that have been started by brand-new students of programming. You'll get an idea of

The kinds of projects they are interested in, and
the sort of questions they ask at first.


One more point. The world is full of people who teach poor programming habits. Don't be one of them! Students learn by example. Every single example you show them should be an illustration of good practices. Never, ever show them "quick and dirty", "throwaway" code that "works" but is poorly constructed.

Choose a reasonable coding style and use it consistently.
Use good names in your programs. Good names use words. Whole words. With vowels. Good names are easier to read and understand than they are to type. "NumberOfPawns" might be a good name. "npwns" is not a good name.
Comment your code well, avoiding jargon. Spelling, grammar, and punctuation are important.
Your code should be well organized so it is easy for studentss to understand (once they have some proficiency in the language). The language is hard enough for them, don't make it worse by using clever coding tricks.
Good code doesn't need many comments.


DON'T try to teach beginners these good habits -- they'll lose interest. But if all your examples are well-written, they'll absorb some good habits as a side effect. The habits will serve them well later if they keep programming.

Two excellent books (for programming teachers, not beginning students):
"Clean Code: A Handbook of Agile Software Craftsmanship" by Robert C. Martin. The ideas in this book apply regardless of programming language or methodology.

"The Elements of Programming Style" by Kernigan and Plauger. This short distillation of wisdom is very old (1978), out of print, and might be hard to find. It's written around published examples of very bad code, which are used to illustrate principles of good programming. All of the examples are in FORTRAN or PL/I -- which doesn't matter at all. It's easy to find all the same bad habits in today's code written in modern languages. The tools and technology have improved a lot since 1978, but I don't think we've made much progress in programming craftsmanship.

estorstenson
Jun 21, 2013, 05:25 PM
My conclusion was that Java is just too heavy as in introduction to computers or programming. "Heavy" means too many concepts too quickly.

I agree with this. Use Python or some similar scripting language for the first one.

Also, I just noticed you mention teaching them to use the GOTO statement. I don't think that there is ever need to use a goto these days in good procedural code. At least not in non-fortran style languages. Probably not even in fortran these days. You can use functions if you need to repeat code, and conditionals to avoid executing code that isn't appropriate for certain conditions.

Sometimes, there are good reasons for people to say certain practices are bad. Not always...but sometimes:)

ArtOfWarfare
Jun 22, 2013, 12:34 AM
DON'T try to teach beginners these good habits -- they'll lose interest. But if all your examples are well-written, they'll absorb some good habits as a side effect. The habits will serve them well later if they keep programming.

IDK, I like the idea of having them learn first hand the pain of having code that was poorly written.

OH, ONE OTHER THING YOU MUST MUST DO:

CODE REVIEW!

Make them look at each other's code! Have them hack each other's code! Have them demonstrate vulnerabilities in each other's code (IE, "if I pass argument X into function F, it crashes.")

All code should be written so that it can be written only once and reused indefinitely. If it ever causes crashes, it sucks (which is why I think it was completely wrong to add exceptions to C++, and every other language where they exist. In my experience, there are always better ways to handle issues than to throw exceptions. Java's libraries are full of crappy methods that throw exceptions for dumb reasons, which requires adding a butt ton of catches to your code.)

hhas
Jun 22, 2013, 05:37 AM
For students starting from scratch:

...
functions and subprograms are HARD
...



Seymour Papert taught abstraction to eight year-olds. Basically:


This is a Word.
This is how you perform a Word.
This is how you add your own Words.


If you're having trouble teaching it to anyone older than that, it's probably because the language you're using has obfuscated it under great quantities of syntax, special forms, rules, exceptions to the rules, exceptions to the exceptions, and so on. Our languages influence our learning and our thinking, and languages that elevate low-level concrete mechanistic trivia to high status while ignoring, obfuscating or scarifying high-level abstract thinking and philosophy are bound to produce users who are masters of endless OCD micromanagement but couldn't recognize a big picture if it fell on them.


My first end-user language I designed and trained to graphic designers as part of a template-driven artwork generation system. Since this audience's concern was producing artworks faster and more accurately than a manual worker could, not learning to program for its own sake, the language had to be extremely simple yet highly flexible and extensible. Thus its primary design influences were Scheme and Bash rather than the usual Algol-y suspects (C, Python, Ruby, JavaScript, etc), giving it a slightly better than usual start. Even so, two things I didn't expect in user training really surprised me:


Even a really basic, regular, unambiguous grammar will give new users frequent gyp. Punctuation in particular is a constant source of frustration. They would often forget to parenthesize the arguments to a command, or they'd remember the parentheses but then forget to type a comma after the closing parens to separate it from the next command.
A good percentage of new users asked to be shown how to define their own commands, even though I'd relegated this subject to the final 'expert users only' chapter and explicitly told them to ignore it, having blindly assumed novice and intermediate users would never 'get' such a 'hard' subject themselves.


IOW, motivated users want to learn; it's for the preconceptions and prejudices of the languages and teachers to beat all that openness and enthusiasm out of them by making them wade through seas of frustrating worthless crap instead.

#1 is mostly an implementation problem. I provided a standalone syntax checker, but since that had to be run separately from the editing process the errors it flagged were too far removed in time and space from the code they had written, so they'd often forget to do it until after their templates had been submitted and their artwork jobs failed. An interactive language-aware code editor that provides instant syntax hints and vocab assistance and highlights typos as soon as they're made rather than waiting until compile- or run-time then throwing it back in their face would go a long way to minimizing new users' frustrations. (It's one of many TODOs for the system I'm writing now.)

As for #2, that's pure magic in a bottle for any educator can reliably capture it. Unfortunately, while this was LOGO's greatest gift, it was also universally missed by adult observers who simply applied their own lazy preconceptions and prejudices in assessing its worth. Even self-proclaimed "LOGO successors" like MIT's Scratch utterly fail to "get it", instead presenting the same great swamp of micromanaging mechanistic trivia - types, variables, operators, flow control statements, etc, etc - as if those are the central tenets of CS, not abstraction.

IMO, one thing that helps is if the language or environment imposes some sort of evolutionary pressure that encourages/forces new users to up their skills and thinking faster than users who are served everything on a plate. In LOGO's case, it was its intentional lack of complex drawing commands as standard: any user trying to produce complex images using built-in words alone would quickly feel the pain as their word sequences grew crazy long and complicated and horrible to test and debug. In my case, it was a hard 99-character limit imposed by the Adobe app that forced users to make even their most complex tags really concise. In both cases, the solution was for users to repackage sequences of commands as new atomic commands of their own devising; once they got that principle, they could be shown how to parameterize their commands for greater control and reuse, and off they go.


This is why I'm increasingly convinced that the mechanical 'batteries included' approach of Codecademy, Processing and other programmer-led platforms is thoroughly toxic to good CS pedagogy, since it encourages students to learn rote unthinking complex tool use instead of abstract-thinking complex tool creation. It's a classic case of Dunning Kruger-ism in action: just because you are an expert programmer does not qualify you for teaching programming to anyone else.

Teach a man to use a fishing rod and he may not go hungry today or tomorrow, but teach him the principles of boatbuilding and in a few decades' time he'll be running his own billion-dollar fishing fleet out of the comfort of his luxury mansion.

MeFromHere
Jun 22, 2013, 01:24 PM
IDK, I like the idea of having them learn first hand the pain of having code that was poorly written.


They'll make plenty of bad code themselves. :) No need for the teacher to supply bad code.


OH, ONE OTHER THING YOU MUST MUST DO:

CODE REVIEW!

Make them look at each other's code! Have them hack each other's code! Have them demonstrate vulnerabilities in each other's code (IE, "if I pass argument X into function F, it crashes.")



I agree, but that goes a bit beyond what beginners need at first.


All code should be written so that it can be written only once and reused indefinitely. If it ever causes crashes, it sucks (which is why I think it was completely wrong to add exceptions to C++, and every other language where they exist. In my experience, there are always better ways to handle issues than to throw exceptions. Java's libraries are full of crappy methods that throw exceptions for dumb reasons, which requires adding a butt ton of catches to your code.)

Exceptions aren't only for "crashes". They are certainly one of the more mis-used features these days, but they do have their place.

Exceptions aren't just for "errors" or "unexpected" events in a program. Sometimes they are a good way to deal with conditions that you KNOW you have to deal with, but you'd rather not deal with them at the place you detect them. They let you detect a condition at one place and deal with it in a different place, which may be far away. All the intervening code connecting those places for "normal" flow can remain unaware of the "abnormal" details. Sometimes intermixing the normal and abnormal behavior ends up completely obscuring both.

daimos
Jun 22, 2013, 10:22 PM
- do long division, step by step
- if you are given a map represented in a 2 dimensional array, and with
the height above sea water in each , trace the water flow (like a flood) if you
are given a starting point.
- create your own text editor, with CTRL commands to copy, paste, save, etc
- given the speed of the planets that go around the sun, calculate when 2 planets align
- given 2 objects at a given distance, let user input angle and velocity
so that they can hit each other with a given weight of a stone (think angry birds)
- given a text file, use encrypt/decrypt algorithms and let user input pin codes to solve hidden messages.

ogaramfa
Jun 23, 2013, 09:24 PM
There are a number of resources pertaining to teaching programming to students of all ages here:

http://www.code.org/teach

Furthermore, you might be interested in this research, which indicates that the ability to program is innate. The authors present a test which predicts with high accuracy whether a student will be able to successfully learn programming, before they are ever exposed to any of the concepts:

http://www.eis.mdx.ac.uk/research/PhDArea/saeed/

jctj
Jun 28, 2013, 12:14 PM
Folks,

I've done my reading assignments (thank you...)! Here are my various responses:

@MeFromHere - I am not going to say you are wrong (we will see in a few short months!) but I will be really depressed if I lose 30%-50% of my high school students just getting through input-output, If-Then, Loops, Variables and arrays, and goto/gosub. I've been shocked before (ugh. Pre-Calc where the first HALF of the year was all review of Alg. II...), but I am really, really, hoping I am right and you are wrong!

I agree 100% that syntax is hard, but loops, arrays and functions are easy. This is clearly arrogance, but I think I can teach those effectively and make them clear - especially if I have a "problem" that is at the right level of complexity that requires these tools to solve. Recursion at the simple level is easy (Towers of Hanoi), but knowing it well enough to see when to use it, how/why it works, why the computer doesn't blow itself up doing it so often, etc. - those are very hard (HARD^2) concepts. Indirection, aliasing, Big O and Little O - yes, those are way too difficult for an intro class and are still hard even on an advanced class. Pointers I would add as a "moderately hard" concept where I think it is easy to "see" what is happening, but a complete $^&$%$ making it actually work. I like the idea of having students create all their own linked list tools (adding/ subtracting/moving/sorting/searching/etc) but fear such an effort is (1) too far above where we could hope to get in an intro class and (2) too bogged down in the minutia of the syntax. It is so easy to draw on a white board with arrows, so hard to make the code do what the whiteboard is showing.... These are not professional programmers yet. Don't even get me started on memory management.... In short, you have an extremely valid point that I am absolutely taking to heart, but I am really, really hoping I can do much better with my students than you are suggesting. Man I hope I am not wrong on this....

@ MeFromHere, PatrickCocoa/notjustjay - Like above, I am desperately hoping I can have the kids understanding your (and mine, and everyone's) first program of two lines in less than 30 minutes. Let's hope this isn't hubris speaking.... I agree 100% that it is better to keep it simple and not get bogged down too far in the minutia of the IDE, etc. I originally thought of using XCode as the IDE since it will work for any language they want, has a powerful debugger, and we are an all-Mac campus, but gave that up right away as I went through a practice program (Hello World Baby!) and realized how much time/how many clicks it was taking *just* to get to the point where I could start to write "printf".... Chipmunk Basic solves this problem and Eclipse is at least manageable. I am also taking to heart what a number of people said about their own kids taking a Java class and running away screaming.

@wrldwzrd89 - Thank you for the offer! I greatly appreciate it, but it looks like Java to any real depth is out of the question for an intro class. If I "graduate" to AP Comp. Sci., I very well may be coming back to you.

@ArtofWarfare (and MeFromHere indirectly) - I am nervous about trying to limit programming to "one concept at a time" and having "magic functions" do everything else. See my earlier post about grammar vs. Higher Order Thinking. At some point, it is trivial to understand a single Lego piece (and very boring - remember your old math classes?) - the magic is in figuring out how the pieces can all be snapped together, and then thinking of what things you could make by snapping various pieces together in a certain order. I cannot pretend to know where the magic line is, but this sounds like putting the line too far to the "grammar" side of things.

@MeFromHere - love your comment about "set the example" but don't put a lot of time "telling" students how to write clean, neat, annotated code. A sneaky thing to do would be getting them used to seeing my beautiful examples and then having them decipher a really bad example, and (without stating the obvious) letting them gain first-hand experience knowing the good from the bad.

@estorstenson - I think you are on to something here. I would start with Basic (for many reasons) and then move to a simple scripting language. Man do I wish Hypercard was still working! Also, I will teach GOTO in order to show them why that seemed like a great and obvious thing to do (when we were just learning how to talk to computers) but caused chaos when we wanted to do more, and THEN we came up with procedural languages to solve that problem, and THEN we came up with OO languages to solve newer problems. It is becoming clear to me that we will probably (most certainly?) not get to any real OO issues, but I would love to teach them Viewer-Controller-Model and explain why THAT is the current idiom in use.

@ArtOfWarfare - 100% with you on Code Review. Absolute must. This teaches them debugging (much less frustrating when you are debugging someone else's code rather than your own...) and gets to the "clean code" issue MeFromHere brought up.

@hhas - You are a deep thinker.... I agree with your #1, but do not have a solution for it. XCode does a great job helping with this, but (as above) there is no way I am going down that path.... At some point, and I think this relates strongly to teaching kids how to think logically, the kids just have to realize that the computer does EXACTLY what they tell it. This is both in terms of syntax (the computer doesn't "get" what you are saying - it reads every character in your program and then applies the correct Lego block. If it can't tell EXACTLY which Lego block you want, it will crash) and in terms of logic (Yep - if you tell it to loop forever, it will loop forever. It will never tell you "this is silly" and suddenly stop doing it, a la Wargames (old movie).) Hypercard would have solved most of this problem but even then, we will not for the foreseeable future have a computer that can read our mind and figure out what we *really* want to do even if what we are telling it to do is gibberish.

@MeFromHere - The kids *will* write plenty of bad code, but showing them someone else's bad code avoids the emotional component of learning ("if your work is bad, you must be a bad person" is the message frequently received) and lets them focus on what the mistake is, not who made it. Seeing poorly written code also reinforces the value of taking those few extra minutes to format neatly, add annotations, etc. I have found that nothing short of a loaded pistol or fully-charged cattle prod will make kids do this properly. Either they take the idea on board, or they don't (and pistols and cattle prods are, these days, frowned upon in most classrooms...). Lastly, if the bad code was inherent in language itself (i.e. BASIC) then seeing that makes apparent why we went to something else (Pascal) and then to something else yet again (C/C+/C++). This is perhaps overly ambitious, but I want the kids to see why we are where we are, not just "this is the way we do it! Shut up and sit down!"

@diamos - brilliant ideas! The last one (encryption) could be a wonderful segue into the idea of private and person encryption keys, a topic I happen to love. Another idea I got from a student is to have a casino, where each student has to make their own game of chance - dice, cards, etc.

@ogaramfa - As it happens, I am also the AP Statistics teacher and reading the research shows that they are (now) only stating that there is a correlation between their tests results and end results in a class. Students who are bad on the test still pass the class and students who are good at the test still fail the class. Yes, there does appear to be important, effective thinking patterns that kids have to different degrees before starting a programming class, and the strength of these patterns impacts their performance in the class, but the notion of an "inherent ability" that separates the "programming sheep" from the "programming goats" was false, as one of the three authors admits in the final paper. More interesting was that the patterns of thinking were MORE significant to performance in class (measured by passing or failing the class - though that was also called into question since one class pass 96% of the students) than wether or not the student had already taken a programming course!

Thank you all for your responses! You have been awesome! Even if I ended up disagreeing with your ideas, your ideas got me thinking along the lines of your concerns, and that has been a tremendous help. Many of your comments brought up issues I would never, never have thought about!

You guys are 'da bomb!

James

notjustjay
Jun 28, 2013, 12:26 PM
Yes, there does appear to be important, effective thinking patterns that kids have to different degrees before starting a programming class, and the strength of these patterns impacts their performance in the class, but the notion of an "inherent ability" that separates the "programming sheep" from the "programming goats" was false, as one of the three authors admits in the final paper.

Absolutely. Programming is like math (almost literally). Logical thinking and problem solving is what it is all about. Like math, some kids get it faster than others. But we don't ever classify kids as "those who can do math" and "those who can't". Everyone can learn math.

However, try to teach the kids calculus before you show them arithmetic, and only the genius-level math kids will follow, catch on, and/or stay interested.

Anyway, sounds like you have a good handle on this, I hope it goes well and I wish you best of luck!

Perhaps in a parallel universe I could have been a high school computer teacher. I hit that crossroads about 10 years ago and decided to stay down the path of being a computer engineer. Sometimes I wonder if I'd be having more fun teaching than I am in the corporate workplace...

estorstenson
Jun 28, 2013, 02:33 PM
@estorstenson - I think you are on to something here. I would start with Basic (for many reasons) and then move to a simple scripting language. Man do I wish Hypercard was still working! Also, I will teach GOTO in order to show them why that seemed like a great and obvious thing to do (when we were just learning how to talk to computers) but caused chaos when we wanted to do more, and THEN we came up with procedural languages to solve that problem, and THEN we came up with OO languages to solve newer problems. It is becoming clear to me that we will probably (most certainly?) not get to any real OO issues, but I would love to teach them Viewer-Controller-Model and explain why THAT is the current idiom in use.


I think changing syntax mid-course is a bad idea. Choose a language and stick to it to avoid confusing them over the subtle differences between the various syntax, which are meaningless for the overall intention of the course (at least, what I would guess it would be).

Also, do consider using Python instead of Basic. Python is probably no harder to learn from, has a decent OO model but can be used in a purely structural way and the kids can then move directly into more useful stuff without having to learn another language.

Once they learn basic, they'll have the understanding to apply their knowledge to do stuff outside of class, but they'll have to learn a new language to use that knowledge. It's not hard to learn, but it might be tedious enough to discourage them from doing so. But, with python, they might discover PyGame to write games with, numpy to help do statistics and math stuff, and it's a language that they can carry with them to college or even earn some money with (an adventurous kid could learn django and throw together a decent web application).

I'd be interested in your reasoning for using basic.

iSee
Jun 28, 2013, 08:33 PM
@jctj: I've found this thread very interesting -- a lot of great & different ideas...

I know your last post was your "last" in this thread, but I hope you'll come back after the term and let us know how it went. E.g., what the kids responded to, what they loved or hated and were inspired by or bored by.

jctj
Jun 29, 2013, 01:16 AM
BASIC is, well, really basic. It is a great place to start with a very natural and limited syntax. It has like 8 commands (load, run, save, new, clear, exit, and my favorite: renum), 15 or so statements (I count if-then-else-endif as a single statement), and it uses numbered lines for reference. While it ended up being a bad idea, when first learning how a computer thinks, it is really nice to be able to say "goto 40" and instantly know what the computer is going to do. As others mentioned, their first program was:

10 print "Roger is awesome!"
20 goto 10

And this is something the kids can very quickly understand in terms of (1) how does the computer "think" and (2) The computer doesn't think at all - it just does what it is told. The kids can quickly see that this is going to be an infinite loop by thinking "10, goto 10, 10, goto 10, 10, goto 10, 10, goto 10..." Input and output is a snap. They can see a small example of "user friendliness" being added by the difference of reading a single character (user does not need to hit "return") and reading whatever is typed until a return. They will deal with the notion that the computer program freezes completely while waiting for the user to type something in - and then we can talk about having a program keep running until input from a user changes what the computer does (messages).

So the kids learn both explicit notions such as if-then-else-endif and for-to-step-next type controls AND they learn the underlying nature of the computer and why we needed/desired going to an entirely different paradigm for more user-friendly programs. I, for one, would argue that the amazing part of modern programs is completely lost unless you knew what computer programs used to be like. For this generation in high school, they have never known anything BUT highly polished internet browsers (anyone else remember the change from FTP/Gopher to Mosaic?!?) and full fledged modern applications that react to user input when it comes (sorry - its late and I can't remember the technical term for the modern type of application compared to the old "run myProgram" and give it input when it asks for it). To them, Word/Excel/iTunes/Google Chrome are just natural - they have no idea that this is actually a ruse and that the computer in reality is mindlessly following linear sequences of commands behind the scenes.

I agree with the issues of changing syntax (but hey, they tend to forget everything over Christmas break anyway...) and as it happens, Chipmunk Basic appears to also have some OOP options anyway, so maybe I would just stay with Chipmunk Basic the entire year. The problem with this is that while I love aspects of BASIC, it is a dead language and there are reasons it is a dead language. Getting them into Python, for example, at least gets them into something they can recognize as a modern, currently used language that will have more chance of practical application. I mentioned earlier that my school just got a MakerBot Replicator 2 (3D Printer) and it turns out you can use Ruby to control the printer directly, rather than just using the 3D Software. With Basic, while they will learn more with less confusion, there is less enthusiasm or motivation to learn it since everyone knows it is a relic (kind of like learning Latin. Cool, but useless really).

James

chown33
Jun 29, 2013, 11:25 AM
For this generation in high school, they have never known anything BUT highly polished internet browsers (anyone else remember the change from FTP/Gopher to Mosaic?!?) and full fledged modern applications that react to user input when it comes (sorry - its late and I can't remember the technical term for the modern type of application compared to the old "run myProgram" and give it input when it asks for it).

http://en.wikipedia.org/wiki/Event-driven_programming

I agree with the issues of changing syntax (but hey, they tend to forget everything over Christmas break anyway...) and as it happens, Chipmunk Basic appears to also have some OOP options anyway, so maybe I would just stay with Chipmunk Basic the entire year.

You could use the Christmas break as the opportunity to break from Chipmunk Basic and switch to Python. If the students have a good grasp of fundamentals, the switch won't take long.

I mentioned earlier that my school just got a MakerBot Replicator 2 (3D Printer) and it turns out you can use Ruby to control the printer directly, rather than just using the 3D Software.
This suggests that teaching Ruby would be a good idea. Or figure out if there are Python modules that can drive the MakerBot.