Slashdot Mirror
Ideas for High School Computer Projects?
rcmpcbf asks: "HELP A TEACHER OUT! My Computer Science students often get bored doing stuff that the AP Curriculum or School Board asks us to teach. I would really appreciate the input of Slashdot members on interesting Computer Science projects for high school students. You would be helping other students, just like yourselves, not me." What kinds of computer projects do you feel would be stimulating for the high school age group?
Oh, so that's where they recruited the Mozilla team.
*DUCK*
As a slightly more complicated to implement chaotic system, simulating a rocket in the vicinity of Earth is also good. This is more complicated because of the need to take the earth's atmosphere into account. Very good for generating interest in aerodynamics.
BTW, I've done both (from a book, "Programming for Scientists and Engineers" iirc). I learnt a lot from that book, including just how a cross product and works :)
Bill - aka taniwha
--
Leave others their otherness. -- Aratak
One of the failings (that I see at least) of high school level CS classes is that they don't pay any attention to the real low-level hardware bits, down at the level of individual logic gates.
A lot - and I mean A LOT - of basic understanding of "why computers are built the way they are" comes from wiring up really basic componants, flipping some switches, and watching LEDs flash on and off.
For instance, I remember doing a project where I wired up 2 shift registers and an ALU chip to a rack of switches and 8 LEDs. By flipping the switches, one could input a pair of binary numbers into the shift registers, and then another switch (wired up as the clock) would trigger the ALU, and the resultant sum would show up on the LEDs.
After doing something like this, you gain understanding of such things as: Why do computers work in binary? How do instruction sets work? How do data busses work? What is the signifigance of the clock? And so on.
The only downside to projects like this is that you need some hardware - breadboards, power supplies, a selection of cheap ICs, a bunch of wire, and LEDs. But tinkering with this crap is just soooooo worth it - and it's fun!
Want to learn about race cars? Read my Book
I was very fortunate to have an excellent AP CS teacher in high school. We moved fairly quickly, and by the end of the year we had studied all the common sorting algorithms, and most of the common data structures. We looked at bubblesort, quicksort, merge sort, stacks, queues, linked lists, doubly linked lists, binary trees, etc. On top of all that we did some GUI projects for kicks, like a calculator, and an application of our choice. I didn't bring away much from the projects, but all the basics- that helped me more than anything.
By the time I hit data structures in college, it was a breeze- I had already learned the stuff a couple years back. The best advice I can give is to nail all of those topics before doing any projects. It was fairly interesting, but I didn't realize the full benefit of the stuff until much later.
But also the writting a functional specification on their own is a very good expierience for anyone going into any form of technical field.
Ofcourse you can then assign them something more complex and interesting.
The Cure of the ills of Democracy is more Democracy.
Erlang Developer and podcaster
I'm sure many of you have heard of the Iditarod -- the dog race from Anchorage, Alaska to Nome, Alaska over 1100 miles.
High school students in Nome were given an awesome project by their high school CS teacher -- we wrote the program that was used to keep track of the mushers during the race.
This was pre-internet explosion -- I'm talking mid- to late 80's here -- and we wrote the program in BASIC on our trusty Apple IIe's. It was a simple database; the users would enter a musher number, checkpoint number, time entering or leaving, and number of active dogs on the team. Once an hour we had to print off a report that was given out to the media reps sitting in Nome.
The ultimate perk was, once the race actually started, students could sign up for 8-hour shifts manning the computers at the Iditarod HQ in Nome. (Yes, even during school hours, but you had to sign up for 2 non-school shifts for every one school shift.)
About the time I graduated from school, Alascom (Alaska's big telephone corp) was using the data from our program to do the updates on their 800-number voice-messaging number. ("The current leader is Libby Riddles; her last checkpoint was in Ruby" and all that.)
Granted, we re-wrote the program from scratch every year -- not the best model if you want to teach code re-use and modularity (but then again, it was the mid- to late 80's). I suppose it's likely that, should a class totally screw off for the semester, that they'd pull an old copy off of the shelf to use. But it was a project that stimulated the creative drive of the students. Even the ones who weren't in the class; kids also helped out with feeding and caring for the dogs when they got into town. It was a real community effort.
I suspect that, since the Iditarod has become more "professional" a la the Olypmics, that this project isn't being done anymore. It's a pity.
Jay (=
So that year, the AP CompSci test was just ridiculously easy. My entire class got 5's on it (the highest possible score) and a lot of them hadn't used a computer before in their life and couldn't do a lot of the assignments.
For good assignment choices, I would look at some of those programming contests that are all over the web, and definately give the kids the option of coming up with their own project if they have a good idea for one. I asked my teacher if I could skip the regular assignments because I already knew C++ and work on a program that would play Connect 4 against a human instead, and I had a great time of it and came up with a cool program.
"What a waste it is to lose one's mind. Or not to have a mind is being very wasteful. How true that is"
Vidi, Vici, Veni
10. How to install Linux/*BSD /. and teach them to hit reload every 2.5 minutes.
9. Show them the proper methods of beard grooming
8. How to dress appropriately for any occassion with only jeans and a t-shirt.
7. Teach them to drink coffee - lots of it.
6. It's never too early to turn them on to cigarettes.
5. Give them a web connection to
4. Get them turned on to Linux and teach them to make inane comments about how much KDE sucks if they like Gnome, and vise versa.
3. Make sure they never get to bed before midnight and make them get up at some ungodly hour.
2. Give all of them pagers and call them every few hours in the middle of the night and say "My computer has a message on it that says 'Press any key to continue.' What do I do now?"
1. Teach them how to be a BOFH!
I've had a problem with that in our computer science course. Everybody could choose either a game or some library book database, the majority vote would be the project for everyone. I was the only one against the game and one of maybe three persons with advanced programming skills.
The project was a complete disaster -- nobody knew what the heck they were doing or where to start, the teacher couldn't coordinate the thing, I ended writing most of the code with one other guy.
I think it's best if the teacher already does the modulization (so classes in Java, units in Pascal) etc. and simply gives away the tasks. Everything else will probably fail due to inexperience in software engineering.
Prove or disprove: P = NP
Good luck!
IT
Power corrupts. PowerPoint corrupts absolutely.
So why not do something simpler, yet still interesting. Let them design a web application. Something like a dynamic generated website.
The following things should be considered:
You can make this as simple or complicated as you want. Both good programmers and the clueless can work on this and learn (basicly because most talented high school programmers learn nothing about testing,documentation,interface and interaction design, while these are 60-70% of the struggle).
I never learned you should make a testplan before writing software(and yes I'd rather just start coding, but for industrial strenght applications knowing what to test for is better because it shouldn't depend on your design!), I won't even talk about documentation and interaction design. All because (appart from taking every CS course our university had on offer (we didn't have a CS degree course, so there are not that many and deep)) most is self taught or from courses my employer send me to.
Don't just teach them how to code
This would let the students gravitate to the area they may be most interested in (coders, builders, whatever) and will also allow you to share ideas between more than one class (if you have one, or if the other teachers are into it).
As the actual building requires a lot of creative writing, you may want to see if some of the English teachers / students want to participate as well.
I can't speak for eveyone, but this is the sort of thing my freidns and I were doing in our spare time during highschool anyways, so why not comhine the 2?
Just don't make it too much like work =)
--sugarman--
Even if they are contributing small amounts of code or insight or peer review or documentation, they are still benefitting themselves AND lots of others in the process.
There is such a wide variety of projects out there - just look at SourceForge and the like - that would allow students to make significant contributions to real-world projects while utilizing the principles and practice of good computer science. You would probably have to be the one enforcing that last part, but I can't emphasize enough the value of real-world experience as a complement to the AP/IEEE curriculum.
You would also have the advantage of having lots of infrastructure already set up - no need to worry about establishing project workspaces, titles, task assignments, etc...many projects will already have these in place.
First, I'm a certified, certifiable cryptogeek, so I'm probably biased here. That being said:
:)
:)
Crypto.
The first rule for teaching (or maybe the second, right after "No matter how much they're the spawn of Lucifer, love the kid anyway") is that you don't have to teach a subject; if you can make the subject something the kid wants to learn, the kid will tear into it with the kind of unholy abandon that only teenagers can muster.
Think about the virtues of crypto, and how you can make your students enjoy it. Make it a point to teach the real stuff, not something watered-down. Emphasize that this is "military-grade" stuff [*], and that nobody--not the NSA, not the CIA, not anyone--can break these ciphers [**].
Tell the kids this, and they'll figure out pretty quickly that there are a lot of things they can do with crypto. Some of them will undoubtedly give your principal gray hair, but hey, that's the price of education. Not as if some of those Satanspawn don't already give him more salt than pepper.
There are a lot of ciphers which are fairly simple to sketch out on the whiteboard. I'd suggest Blowfish or RC4; both of them are exquisitely simple in theory, and straightforward in practice. There exists a lot of source code for Blowfish, at least a dozen different implementations in the public domain or Free Software, and RC4 (also sometimes called "arcfour") is almost as widespread.
You'll wind up teaching them about number theory, groups/sets, Boolean logic, the whole nine yards. You could easily spend most of a quarter writing this, and each day in class you'd cover a different aspect of computer science, along with a surprising amount of mathematics.
Crypto is a surprisingly comprehensive discipline. Good crypto libraries require that the programmer have a master-level knowledge of software engineering principles, advanced knowledge of their programming language, and sophistication in how they think about problems.
And when the kids start sending each other PGP-encrypted email over the school network, plotting the violent overthrow of the school and how to best string up their most-hated teachers from trees, you can sit there with a beatific, immensely satisfied smile and say--"Those are my kids."
If you want to know more about crypto and the classroom, feel free to drop me an email. I've got a C++ library for Blowfish which I wrote to teach some younger friends good software engineering principles--it's well-designed, with a boatload of documentation.
[*] Gloss over the fact that there is no accepted definition for "military grade".
[**] Gloss over the fact that there are easier ways to attack ciphers than by cryptanalysis.
I can remember in High School I became incredibly bored with Computer Science, being I already had advanced knowledge of computers, and took it just to get an "easy grade".
One thing that I had trouble with was keeping busy - the Teacher I had was bright, but not very skillful in computers. He knew I could run the class and that scared him.
I would suggest is asking your students *what* they want to learn - some might want to learn networking, some might want to program, others repair computers. Give them research time to browse the HOWTOs and other more in-depth information.
I got into alot of trouble in my CS class and ended up dropping out because I was at the point of losing my sanity.
If the subject is programming, don't tell them what kind of program to write - just tell them to make one! This is what motivated me. My friend and I spent all of our time writing a instant-messenger over IPX (it was a Novell LAN) while everyone else was writing "exercise programs". We didn't get a grade for it, even though our program was much more advanced than the others'.
Secondly, I would put your IT department to a test. Put $50 on the table and tell them the first one to hack the school's server will get it. This is not only beneficial to your security, it will keep the kids motivated. Make them share how they did it with the class and make a "lesson" out of it. Also, keep the kids busy by having them do computer work in the school. In my school most teachers would have a downtime of over a week before their terminal was fixed. It's free help for the school, and very educational for the student(s). Pair up the smarter kids with some of the not-so-smart-but-able-to-learn kids.
Have a "LAN party" day when everyone who has a computer brings it in and setup a game of "Worms Armageddon" (in this "post-columbine world" as JonKatz would say) Doom or Quake would not be acceptable if you are worried about your job. Have them setup the network and get all the clients configured and have them go at it.
Hope these help... I wish I had these to do in High School...
- Slash
Hopefully, somebody will see this even though it is rather late to get mod'ed up.
When I was in computer science, my friend and I were rather experienced in programming so we were able to design our own project. After looking through books and other projects we decided to go for a simple poker game with AI. I know that the project was simple, but it taught us alot about programming teams and modulizing code. Learning to work with other programmers on projects, is a skill that a book can't teach. We learned to divide projects and work with strengths of certain programmers. The concept is applied all over, but for some reasons school systems seem to neglect the fact that people always work with other people on projects.
Hopefully I have been of some help, and realize that there are so many skills that books can't teach, so focus in on those and let the students learn how they want to learn.
Please forgive the lack of structure...writing is not one of my strong points.
See if any of them are interested in neural networks. It's not a beginning project, but some students are likely to have some experience with programming and AP math should be enough to get started. Here's some reasons:
Just some ideas. I don't think it's beyond the scope of some bright high school students.
..don't panic
My teacher had plans to have our class work on a program as a team. It never got past the planning stage, which was limited to exactly what I just told you, so I can't really give you details. But I can give you my ideas.
First you need to come up with an idea for the program. It should be fun or interesting (or both) so you'll keep their attention. You should probably write main() yourself, but:
Have the students write -- individually or in small groups -- the functions that actually make the program work. Each team/individual should only be given information necessary to writing their part of the program, probably limited to what inputs they need to take, and outputs they need to give. You'll probably need to write test programs for each of these functions, too.
The idea is to have everyone work on an independant part of the program, and then watch and see how their part helps out all the rest, even though they weren't involved in those parts, and probably don't even know what they're doing.
It's a great way to show how teamwork in programming can pay off.
--
--
"I personal[ly] think Unix is "superior" because on LSD it tastes like Blue." -- jbarnett
This past year I was in a CS class in which we didn't concentrate on the AP exam (we have a separate AP class for that, which I took the year before). For about half of the semester we undertook a simple (relatively) project that consisted of making the game "Battleship" for the computer, making it Multiplayer, and putting it on the Internet for people to play. We only had 7 people in the class, and of those 7 only 3 or so were really interested in the project. The difficulty in the project centered around the fact that 6 of the 7 people were learning java, the language we were coding it in, at the same time. At the end of the project, which was aborted by the teacher since we were wasting too much time, we had a semi-functional server and a workable UI design on top of a fully functional client. This was also the first year the class was taught, so everyone was sort of testing the waters. What stopped us the most (outside of apathy on the part of some students) was that the specifications were changing quite frequently. Primarily because the people programming the server couldn't figure out how to do something, and our instructor would help them, but didn't (understandably) want to do all the coding for them. This lead to the requirements becoming constantly less and less complex.
To sum my experience up; whatever project you decide to do there are a few things that _must_ be done ahead of time. A working knowledge of the language the project is being coded in, a formal specification of the project that is rather difficult to change (unless absolutely necessary) and interest in the project are all very important to the success of the project.
---- Yay! I have a sig!
The problem with High School, and even now college is that they assume those who are taking the course don't know a thing about computers. Most of the time this is nt the case at all. Especially in high school.
(College tends to be a place of re-learning for those who come into different trades, I know, but that does not mean the rest of us have to suffer.)
I just pasted my first year of Computer Systems Technology, before that I took the first year of Computer Science. It was boring as hell. It was like being back in Grade 11 again, because everyone else had to catch up. They should really design 2 different programs.
Keeping that in mind. One of the things we barely touched on was actually how video is displayed, and how to manipulate it from the most basic levels.
And what about the hardware aspect? (Using Parallel and Serial ports). Why not create a computer controlled robotic arm from scratch? Or some other device.
Show them how computers recognize hardware from the basic levels. Get some bread boards and dip switches, make some devices the computers can recognize that they exist as a hardware component (they don't actally have to do anything however).
I think more teachers should ask the students what they would like to accomplish from the course. My electronics teacher did that this year, but he had to give everyone the same, fair chance. Originally the last project was to build a device that recognized keyboard outputs and display them on a breadboard on a few led bars or numeric display. But instead the last project was a 10 base binary counter, because most people couldn't get there timers to function correctly or kept blowing the components.
I am not saying we should leave people in the dust if they don't know as much, but the course should and can be designed around the individual student, if you plan it right.
"Imagination is the only weapon in the war against reality." -Jules de Gautier
My favorite beginner's CS assignment was from an intro class in college (might work for high school students too, I don't know what their ability level is). It was a simple program that read in /usr/dict/words and then was supposed to enter a loop in which it would take two 5-letter words from input and produce as output the smallest list of words that were each one letter apart from each other that went from the first input word to the second input word. So, for example:
Input
Word 1: slash
Word 2: troll
Output
slash
flash
flask
flank
blank
bland
blend
bleed
breed
bread
tread
triad
trial
trill
troll
One of the requirements was that it had to be somewhat efficient, so we had to compute the one-letter permutations of a word at most once and preferably not at all (in the case that program never needs to know).
It was a terribly fun project: it was possible for me even when I didn't have much programming experience but it made me stretch my brain a bit, and it was a whole lot of fun to play with.
--
-jacob
-jacob
I hope you use these suggestion
-------------
HAL 7000, fewer features than the HAL 9000, but just as homicidal!
You know, part of doing such a project is to limit it in scope to be manageable in the time allotted. My college software engineering course did basically what you mention except we had teams of 5-6 who bid on projects then had to actually deliver (part of the grade). Part of our job was to figure out which project(s) we were best suited and also to define exactly what we were going to do for the project. Almost always this was less than the original grand plan. We had to estimate the resorces we had, the time allotted, the difficulty of the material, our knowledge level, add in a dose of reality (unforseen delays) and come up with a neat project (usually for elementary students).
Now maybe it's not such a big deal in HS but it seems like somebody needs to notice that you guys never got anything done. That means the scope of the project must be scaled down (a real world skill) and project management has to be more efficient. Being a CS course and not a management course it seems to me that it should have focussed more on programming than managment. This *especially* in light of the huge numbers of people applying to colleges when they are not even remotely capable programmers. (In fact most colleges expect you to be a competent programmer by the time you arrive on campus)
I'm not trying to knock the class but as you progress into college and the real world not completing projects means no passing grade or no food on your plate. Granted it is decent practice for *management* activities but you won't usually be doing that for several years. Seems like your teacher was simulating the 'below average' programming project year after year. I hope (s)he pointed out how much programmers underestimate the time it takes to do a project.
Fsck cluebie moderators. I'll say what I want, offtopic or not. And fsck having to qualify every bloody statement just
BTW: If you pick programming contest do *not* choose timed contests. While they are exciting (I participated in quite a few) they don't really _teach_ you anything useful. Pick a contest that has a meaningful goal in mind like creating the neatest shell features, or smallest byte code, or fastest ray-tracer, coolest fractal algorithms, etc. (ingenuity, size optimization, loop optimization, creativity) but don't do the kind of crud like "write a minimal number of coins algorithm given the amount in cents" where the quickest correct ansmwer wins.
Speed programming turns into typing contests when the programmers are good. They learn shortcuts in proramming which is gerenally a bad habit. They also learn not to plan and think things through, etc. I think you get the picture.
Fsck cluebie moderators. I'll say what I want, offtopic or not. And fsck having to qualify every bloody statement just
Maybe some modeling of physical systems would be interesting?
There are many systems in biology and physics that are not too difficult to describe using a computer program.
Put them through the things they'll see later in life:
MONDAY: Assign some vague requirements for the project (say a sort program) and make the project due on Friday.
TUESDAY: Answer their questions about the requirements and tell them it's now due on Thursday.
WEDNESDAY: Change the requirements completely.
THURSDAY: Collect the assignments and critique them in front of everyone.
FRIDAY: Make each student add some minor enhancement to the project, but they must modify the code from the person on their left, NOT their own code.
Have each student's grade determined by the student who had to "enhance" the code, not by the teacher, and not even by whether the code worked or not.
The web site has links to previous projects to give you some ideas about the kind of work that some of the teams have done, but overall I will say that the work is of remarkably high quality. This is a school-year-long event, so many of the projects will need to be shortened for semester-long use. They may also need to be made more simple.
As a side note, I should mention that although all of the projects can benefit from supercomputer time, the Challenge is over 10 years old as a program now. As a result, most of the projects run find on mid-range desktops (but are, neverthless, computationally intensive tasks).
Start a company
Syllabus: 1] Write code that does nothing - but has buzzwords like "B2B" or "Sharing" in it. 2] Be written up in Slashdot. 3] Get VC funding. 4] Be written up in Slashdot again, with nearly identical commentary to the first. 5] Make the cover of a half dozen clueless magazines. 6] Be ignored by Slashdot. 7] Count stock options worth several billion dollars. 8] Get sued by some equally clueless industry group afraid their fat cash cow is going away. 9] Be written up in Slashdot, with more redundant commentary. 10] Pursue the lawsuit in front of some absurdly clueless judge who slaps a restraining order on the idea of "programming" because it could violate some businesses ability somewhere to make money. 11] Did I mention being written up in Slashdot? 12] Go out of business, because after all, the code did nothing.
I find the best way is to pick a big, over-reaching project. Then teach by sections. You don't even need to tell the kids that they're doing little bits of a big picture.
One example that I've used, is, and I've seen it below, a physics-accurate space ship modeler. Start out with simple programming techniques. First, hardcode a distance, and a mass, and prints them out. Then it runs them through an acceleration formula, and prints the results. This shows basic flow, variables, and printf. Next, get distance and mass from the keyboard. This teaches, scanf, and equivalents. Next, get distance and mass, and use a loop structure to display velocity at every interval. Go from there. Eventually, you can add all sorts of neat things, until you manage to get what is basically a fairly accurate working simulation of the solar system, and a basic navigation system for ships. Then you add in the networking protocols, ship statistics, and combat models.... The important thing is, though, not to teach concepts. Write programs. From programming, learn concepts.Vintage computer games and RPG books available. Email me if you're interested.
Wound up trimming it down to joysticks and what is a natural way for users to use them (i.e. - expected controls models and such).
With all the talk that hits the /. boards about interfaces and the good/bad points about them maybe that's something for your students to look at.
A fresh set of eyes on a old problem.
Malk-a-mite
"The axiom 'An honest man has nothing to fear from the police'
Why is it that the proponents of "one nation under God" are so eager to get rid of "liberty and justice for all"?
1) Try something they can do for pure hack value, i.e., just something that they can impress other Comp. Sci. people in college with. .02.
2) Go to www.sourceforge.net and let them pick out a project to watch/join in. Nothing is more exhilarating than to know that code your writting is going to real use (even if the project justs rejects it as not good enough - but you as the teacher should help them), not just text-book examples on loops and theory.
Just my
You are more than the sum of what you consume.
You are more than the sum of what you consume.
Desire is not an occupation.
At the beginning of the year, everyone picked a project -- two misguided students teamed up to write an OS, I picked a chess-playing program, someone did a database, someone did a simple BBS, someone did a symbolic math package, and so on. There were few restrictions on what you could pick, although you were encouraged to pick a year-sized chunk of work that was reasonably useful from a real-world perspective. We worked on these out of class for the year; she tried devoting class to status reports, but that was mostly useless -- who wants to hear the status of someone else's project? So she started devoting class to random CS tidbits, in chunks of a week or two. The only tidbits that really stick in my mind are a couple weeks' worth of Lisp (with most of the class being us solving in-class Lisp problems, on paper or in the computer lab) and a basic introduction to hashing. The in-class stuff was basically killing time, though; almost all the grades were from the projects. I think there was the occasional class devoted entirely to question-and-answer, also, although the saintly Ms. Bunn handled most project problems outside of class.
As I said, this was the most amazingly cool CS education I've ever gotten. In the course of finishing a project, you were guaranteed to pick up a whole lot of useful crap, but you also had the sense that you were doing something important (as opposed to the "Todaay, wee willl bee learnning aabout graaph algoorithmms..." style of education), and it was cool as hell once the projects got to the point that they were actually functioning programs ("Holy shit, it's really playing chess!") Most of the projects were structured so that there was no real stopping-place, so there was no risk of running out of work -- when I announced that my chess engine was as good as I could make it, Ms. Bunn smiled and gave me a book that described alpha-beta search, which kept me busy for the next several days continuously until it worked, and then until the end of the year trying to make it better. For the BBS or the symbolic math package, you could just keep adding features. The OS, of course, was barely begun at the end of the year, but what had been written appeared pretty sound, so I think the kids escaped without too bad a grade. I think a couple of people actually managed to "finish;" Ms. Bunn just let them slack for the rest of the year, but I could see you handling this differently.
Anyway, my advice to you is to try to separate the kids who want to take a class on CS from the kids who want to learn about CS, and then do something akin to the above for the ones who want to learn -- some of them will stun you with how much they produce when you let them produce whatever they want. Keep the class pretty small so you can keep track of each student's progress pretty regularly, make sure the students aren't afraid to switch projects if the one they're on is too hard, easy, or unrewarding, and throw good, informative books & websites at them like Mardi Gras beads -- if a student hasn't done any work for a week, it's probably because he doesn't know a certain syscall or file format.
A few more project ideas, somewhat modernized from when I was in HS: An mp3 player ("You're done? Okay, now write the encoder."), a side-scrolling one-player game, a simple web server, a corewars simulator, a packet sniffer (they'll love that), a file compression utility. None of these are completely beyond the reach of a talented HS student with a school year to throw at the problem, but they're all "real" programs, such that when people do start getting them working, they'll feel like gods. They'll also have long since forgotten that they're learning.
I don't know how acceptable this would be in the high schools, but the applications that taught me the most programming theory were casino games.
I managed to pull off Keno and Blackjack. They were a lot harder than they seemed. Keno required a graphical interface with the ncurses library that was probably harder than most menu interfaces you'd see, like pine or capt. Blackjack was a little easier, except programming in things like split, double down, and insurance, which was a headache.
My friend pretty much catapulted himself from novice programmer to experienced programmer in two weeks with Deuces Wild. Now that one was a nightmare. Not only did he become obsessed with randomizing and shuffling the deck, but the algorithm for determining the final hand was incredibly complicated. To make matters worse, he insisted on testing the thing on a 4 megahertz machine from about 1986.
Anyway, I've written a lot of worthless software, but nothing has been as useful later as casino games.
"Beware he who would deny you access to information, for in his heart he deems himself your master."
In my first CS class (back in 7th grade), we used the "most prevalant" system of the day - the Apple II. By the time I graduated HS, they were long gone.
For introducing the basics, I recomend UNIX (or Linux or whatever flavor you like) because the i/o and file system are very transparant and easy to teach. Even this is a small advantage, and not worth starting Holy Wars over.
Beyond that criteria, which OS you use in a high school classroom is utterly meaningless.
Information wants to be anthropomorphized.
It seems to me there are a few basic concepts that I would want a student to come with after his/her first computer class:
1. The basics of computer hardware, and file systems. A *n?x box of some kind seems to be the best choice for this, but you can teach the same concepts with a Windows PC or a Mac if you have no choice.
2. Programming. For an intro class, you can get by with Basic, Pascal, or even shell scripting... the point is to get the concepts of loops, conditions, and so on intot he kids' heads. For more advanced students, move on to an object based language. Don't chew your nails over the platform choice... whatever they use will be obsolete by the time they are out of college anyway. Just get them started.
3. Relational Databases. The school guidance counselor is probably telling your kids that database knowledge is a boarding pass for the Gravey Train. They should be, anyway. Again, don't worry about which platform you teach from. The concepts are very portable, and nobody really knows which database company will be the "it girl" of 2004.
4. Networking. Programming plaforms change, OS platforms change, database platforms change (I'm starting to sound like Avrey Brooks), but networking is the past, present, and future of the digital revolution. Make sure your kids understand TCP/IP, everything from the basics of sub-net masks to IP spoofing. Get down to the nitty-gritty of network file systems. Talk at length about client/server, thin clients, fat clients, terminal apps, web applets, ftp, http, ppp, and lots of other acronyms ending in "p". Give them an introduction to IPv6, the Common Language the whole world will be speaking in a few years. Bring Cisco geeks in as guest speakers. Then, once your kids are network guru's, have them promise when they get older they will remember to send you a photo of their yacts from their summer homes in New Zealand, and let you be a guest at their Florida country club once in a while.
5. Project Management. Once your kids have all the basic skills covered, it is time to let them use a little creativity to come up with their own projects and strut their stuff. If they want to design a game, fine... have them form a design team and get started. Applied knowledge is where the real learning begins.
Information wants to be anthropomorphized.
If you have any measure of electronics skills and a good crop of kids in the classroom (which they probably are, if they're bored), try building something neat with them.
When I was in high school, one of the things I built was a small computer.
Nothing fancy, all you need is an empty piece of Veroboard or some other prototyping bits (even Radio Shack has it), a Z80 processor, some RAM chips, and an EPROM programmer.
The part of the class that is good with their hands can assemble the computer and get the hardware done. (A few chips, none with more than 40 pins, it will take them a few classes, but not too long.) The rest of the class can punch in an assembly language program that you can provide on paper (find it on the 'net, or write something quickly), assemble it, then burn it to an EPROM.
From there, you can plop the EPROM into the hardware department's product, turn it on, and either have it work, or not. <grin>
And then there's other stuff...
When I was in high school, I built a small robot arm. It was controlled by my old TI-99/4A, which used to write information to the parallel port. I used the 4 MSB (most significant bits) of the parallel port's 8 bit byte to select a given motor on the arm, and the 4 LSB (least significant bits) selected the operation: Hold, forward one step, backwards one step.
Of course, used in this manner, I could have controlled a lot more motors, but my technology at that time was primitive!
Feedback to the computer on arm position was done by using the keyboard. When the arm reached one limit or another, a switch was triggered, and that switch was in parallel with a key on the keyboard.
All the programming was in TI-BASIC, loaded into the machine from a cassette. I could make the arm do certain movement by "printing" a character to the parallel port. When the arm reached a limit of motion, the TI-BASIC "CALL KEY" instruction, which would test for key presses, detected it. A loop of printing instructions and then checking the values returned by CALL KEY gave it full feedback and allowed the robot arm to pick up objects without crushing tem, move them precisely, put them down, and even return to pick them up from the same place as it put them down.
Of course, there was no practical use to this setup, but it was cheap and easy to build: a few surplus stepper motors from old printers, a power supply, a homebuilt stepper motor controller. The arm itself was a drawer rail (allowing for in and out movement on one axis) with a piece of picture hanging wire on the shaft of a motor to turn the rail in and out. The gripper was made with Mechano and operated on another stepper motor. And there were pivots for the gripper, the base of the arm and the angle of the arm, all built with junk and stepper motors.
It was fun, and it was thoroughly useless. But it was something that my friends liked to play with when they were at my place, so I think a classroom might enjoy it. I wrote routines for it that would put pepper onto dinner, or ketchup onto a hot dog, even put a battery into a radio. Of course, all those things have to be in exactly the positions where the robot thinks they are, before it can manipulate them.
Of course, today, you could use an XT as a controller; you wouldn't need to worry about waiting for cassette-based programs to load.
Fire and Meat. Yummy.
My OAC Computer Science course (OAC=Ontario's Grade 13) consisted of, among other things, a term-long project for the entire class, which was learning about how to, and creating, a full-blown application.
At the start of the term, everyone in the class applied to "jobs", with resumes and everything. According to what you applied for, and how you presented yourself (not necessarily your skillset), you got certain jobs. One person was chosen as the "VP" (the Pres was the prof), and had to manage a lot of stuff, as well as do some work. We had three departments: Coding, UI, and QA (whose job it was to make the coders and the UIs co-operate). There were department leaders, and then inside the deparments, if there were special task forces, they had team leaders, and so on. Basically, our prof tried to make it as much like a company as possible. It was a lot of fun. No class (to my knowledge) has actually completed the project, but it's the process that's important.
For me, it was really helpful to learn how to work well in teams, and how the real world operates. It was a lot of fun, and I think you learn more than doing games, or anything like that.
"Free beer tends to lead to free speech"
If your students are learning easy languages like Visual Basic or delphi, writing an instant messenger would be interesting for them. This is software that they use, but probably regard as being difficult to make. When all they have to do is set a few properties, they will be pleasantly suprised. And considering that they will be programming for the internet in any case ..... -John.
- Rackham
"You can't protect anyone.... You can only love them."
I don't know about other schools out there, but my HS only taught Pascal, and later added a rudimentary C course. I would vote for teaching something like Perl or Java as well.
#include <sig.h>