Someone mentioned that I wouldn't learn much C from seven classes. I think he misunderstood. It's not seven classes. It's SEVEN COURSES. Each course has a bunch of lectures and tests with a Final exam in each course.
My basic point it this. At the end of the 7 courses, you will ideally have a solid introduction to the C syntax, its primitive data types, control structures, and memory model.
All of this is very nice.
But that doesn't mean you'll be able to program a computer. You might be able to understand and read code. (And don't take this personal, I don't mean YOU you, or anything like that, I'm talking in general.)
Computer programming is beyond syntax, far beyond syntax.
And, bluntly, you have to apply it, to problems that you care about, that interest you in order for it to stick.
I look back at my father, who lamented the limitations of variable names in BASIC. He used the variable A, then the variable AA, finally the variable AAA and ran in to trouble, because the early BASICs tended to not discriminate beyond the first 2 characters.
Now, anyone of experience would decry that what he wanted to do was Wrong. That he was coding the Wrong Way, and had unreasonable expectations.
His code was awful, but that doesn't mean it was the Wrong Way. As Perl community likes to embrace as a first class concept "There's more than one way to do it". And, IMHO, end user programming should be encouraged. In time, if he stuck with it, wrote more programs, used them for any length of time, I'm sure my Dad would have learned that naming all of your variable A, AA, AAA, B, BB, BBB, would probably end up being a bad idea. But the best way to learn that is by understand what's wrong with it, rather than just parroting some rote principal you heard somewhere. It's one of my quibbles with the whole "Best Practices". Many embrace them without understanding why. And if they did understand, they wouldn't necessarily need lists of Best Practices to follow. And, IMHO, they should understand.
As an anecdote, I was talking to a lady who had written a quite large data processing system, all in a BASIC that supported only 2 letter variable names. She was quite proud that Z9 was used as the global error code in her programs. That was a standard of consistency for her system. No doubt there were others that made best use of the limited variable naming space. Things we obviously take for granted.
Programming is a craft to be practiced. Your courses will tell you about the saw, the hammer, the drill, etc. of the C world. But they won't make you a carpenter. Experience is the only way to get that. Which is why it's important to write code. Writer early, write often, mess things up, "do it Wrong". Results over process.
Which is also why you need to code things the interest you. With my Dad he was either doing engineeering calcs or financial/stock studies. Taking formulas and such from books and trying to apply them. I knew one guy who leased a VAX 11/750 (which was larger than the VAX we had at the office) to do commodities tradiing analysis. He did it all in BASIC, I never saw his code. He was an engineer. But a number of "quality" standards, I imagine his code was "bad", but it gave him the results he wanted, and thats all that mattered.
But I will tell you he dropped it like a hot potato for a PC running Lotus.
So, to learn C, you need to apply C. Start with a blank file, start typing in code, and bumbling your way through things until stuff works for you.
While software is changeable, code has momentum. Early decisions can affect the lifetime of a project. Which is why early on it's important to throw stuff away wholesale and start again, so as to not bring mistakes with you. But don't let that scare you from doing whatever you think will work. You will know when something becomes a problem. Because it then becomes YOUR problem. And those are the best lessons.
I'm a homespun organic coder. Outside of fundamental FORTRAN syntax, and, most importantly, I/O, I can honestly say a class has never taught me much of anything. It's all been book learning in the trenches with no fear of applying stuff and making it work. I tried to learn FORTRAN on my own, we had a copy for the TRS-80, but I couldn't figure I/O out. It was talking I/O channels, and files, and what not, and I just wanted "Hello world" and "Guess the number". Couldn't figure that out when what few books I had were talking about tape drives.
I learned BASIC, then started writing BASIC in FORTRAN, FORTRAN in Pascal, Pascal in C, overlaying my knowledge of the old ways on to the new ways.
So, programming is a craft, the more you do, the better you get. Approach it without fear, you can't hurt anything.
? I mean, really hate putting everything in terms of money. it's just, well, so many things depend on it. Know what I min?
