macOS Need "awesome" programming problems

jctj · Jun 20, 2013

Delay in responses

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

jctj said:
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 (from Surely You're Joking, Mr Feynman!). Plus ça change...

MeFromHere · Jun 21, 2013

jctj said:
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.

----------

pianojoe said:
Another thumbs up for Robert Sedgewicks "Algorithms in C" book. I'd focus on

sorting, because its 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

From little acorns . . .

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

PatrickCocoa said:
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

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

MeFromHere said:
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

notjustjay said:
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.

notjustjay said:
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

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

PatrickCocoa said:
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 21, 2013

MeFromHere said:
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

MeFromHere said:
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

ArtOfWarfare said:
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.

ArtOfWarfare said:
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.

ArtOfWarfare said:
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

- 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

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

Last reply

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

jctj said:
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

jctj said:
@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

@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 28, 2013

Why Basic

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

jctj said:
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.

macOS Need "awesome" programming problems

macrumors newbie

macrumors regular

macrumors 6502

macrumors 6502a

macrumors 603

macrumors G5

macrumors G3

macrumors 6502a

macrumors 6502

macrumors member

macrumors G3

macrumors regular

macrumors 6502

macrumors regular

macrumors newbie

macrumors newbie

macrumors 603

macrumors member

macrumors 68040

macrumors newbie

Moderator

Our Staff