I agree with those who have advised you to just start programming. Pick something that seems interesting and write a program that does it.
I learned C by writing a (heads-up limit hold 'em) poker program. I didn't use any libraries other than <stdio> and <stdlib>, so I had to re-invent the wheel in some cases. It ended up being about 1000 lines (not counting comments and excessive whitespace used for clarity), and it was just a text-based interface that could keep track of the state of a poker hand, allow you to make decisions, have the computer player respond semi-randomly, and determine the winner.
I used the Deitel & Deitel textbook, but I didn't do any of the exercises or try to memorize anything. Memorization and exercises are overrated (unless you are going to be tested on the material). It's better to just read a chapter, come up with your own example that uses the concepts explained in the chapter, and refer to the book as necessary.
After I wrote the rudimentary poker program I wanted to make it smarter, so I wrote a tic-tac-toe program that used a recursive minimax algorithm to search the game tree. I ended up losing interest in the original poker program, but have since become a game programmer.
Don't become a "programmer": become a "web programmer", or a "game programmer", or a "compiler writer". Don't learn how to program just for the sake of knowing how to program--instead, learn how to write a specific type of program that you find interesting. You'll be more motivated and will achieve tangible results sooner.
Comments
I agree with those who have advised you to just start programming. Pick something that seems interesting and write a program that does it.
I learned C by writing a (heads-up limit hold 'em) poker program. I didn't use any libraries other than <stdio> and <stdlib>, so I had to re-invent the wheel in some cases. It ended up being about 1000 lines (not counting comments and excessive whitespace used for clarity), and it was just a text-based interface that could keep track of the state of a poker hand, allow you to make decisions, have the computer player respond semi-randomly, and determine the winner.
I used the Deitel & Deitel textbook, but I didn't do any of the exercises or try to memorize anything. Memorization and exercises are overrated (unless you are going to be tested on the material). It's better to just read a chapter, come up with your own example that uses the concepts explained in the chapter, and refer to the book as necessary.
After I wrote the rudimentary poker program I wanted to make it smarter, so I wrote a tic-tac-toe program that used a recursive minimax algorithm to search the game tree. I ended up losing interest in the original poker program, but have since become a game programmer.
Don't become a "programmer": become a "web programmer", or a "game programmer", or a "compiler writer". Don't learn how to program just for the sake of knowing how to program--instead, learn how to write a specific type of program that you find interesting. You'll be more motivated and will achieve tangible results sooner.