   A fundamentally different approach...
  Here is my big beef with most of the C/C++ tutorials I have seen, they throw a bunch of code at the user and explain it chunk by chunk at the end. Almost all of them start with the same stupid "Hello World" program. I have been coding for several years now, and I think it is time to write a new tutorial for beginners that starts with the fundamentals, then moves on to the standard library. Here is a basic layout.1. Thinking in C (C funtions from algebreic functions)2. Speaking in C (syntax (){}[], and 3. Memeory in C (how C uses memory, varaible declarations, and a brief intro to pointers)4. branching and looping (if [else], for, and while)5. the preprocessor (#include and #define)Up to this point, the reader would be exposed to no real code, but no errors should be generated. The next 5 or 6 would cover the standard library.What do you think?   ____________________________________________________________
  But people would get boared without seeing any code.The 5 min "Hello World!" project is classic.  Sometimes the person will figure out how to make it say "Goodbye World!" and think there preaty neat stuff.  These our the future programmers.   Although some get held back by the joy of making that display semingly infinit messages and never want to learn anything else. Serious now:Thats how my HS programming book did it.  Started with concepts of the language before showing code.  First code I saw was psudo (whatever) code.  I knew a little already though, so it was kind of a drag, maybe a little less than for the rest of the class who wanted a "easy computer course," because I was interested in it. ;  What I meant by not seeing any real code right away is that no output would be performed until later. If I had the fundamentals down right away, then I wouldn''t have spent so much time flip-floping between C and Basic. ;  I''d take the opposite approach. I''d show a reasonably high-level program (with a familiar, accessible objective - no payroll applications, thankyouverymuch!) The top level would make calls to functions at lower levels, so it would read easily. This would highlight program structure and allow meaningful changes to be made early as well as introduce modularity and functions.I''d then delve into the next layer down (and so on), explaining what was going on and what should be noted. The entire application would need to be fairly compact so that all the code can be covered in a few lessons. The rest of the course would then focus on extending the application, giving proper context for introducing more esoteric language features and showing their application (no stupid Mammal -> Cat -> Siamese inheritance hierarchies). ;  Oluseyi:I like the idea of working with a functional program in which you add features as you learn them, but certainly you can see the wisdom of teaching the fundamentals before moving on to the standard library.Using printf() would be a lot more usefull if I knew I was calling a function.   ___________________________________________;  Oluseyi:That''s how my Programming I class actually worked.  Our semester long project was to make Othello, and we had to do it in four phases.  For the first phase, the professor gave us a library to work with that did a ton of stuff, and we just put it together.  In the next phase, the library didn''t do as much high level stuff.  By the fourth phase, we had to do it all ourselves.Of course, I have no idea how effective it was.  The people who already knew how to program had no problems, the people who didn''t know how to program had big problems, and there was no one in between.  And that''s how it almost always seems to go.  Some people think like programmers, and usually already are, and others don''t know how to think like programmers, and thus never become programmers.  Unless they''re really really determined. ;  When we were learning HTML at school, my classmate looked at the textbook and said "It''s easy! Just memorize all those commands, and you''ll be web-page programmer". We all know, that this is the worst approach ever - the begginers, that know nothing about programming need to be learnt, that there''s nothing wrong with looking into documentation every five minutes, and they should learn HOW to program, not whole the MSDN by heart...Oxyd   ---Unreadable code is code written on a piece of paper, but not the one, in which its programmer is using a space in place you don''t.  