I'm doing this tutorial after a programmer friend gave me the link (he also sent me here. http://directxtutorial.com
Alright so My main concern/worry is the following.... I've been reading up on it and I find all that code(C++ window codes) to memorize rather hard and painful and what not... So to those of you who work in the industry or hell you hobbiers.... How much code do you have memorized? Or is it like you copy and pase some generic code and then alter it? Do you always start from scratch? Does it get easier? Overall I feel a bit overwhelemed... I mean I could program something like that with enough book's or resources but not all by myself. From memory.... This reminds of of my data structures class. My professor said that Data Structures are something that you don't memorize. you memorize how it works and then use resources to create them again if you need them. Or use older ones and alter it to your needs.... So yeah is it like that?
Um.. Feeling a bit overwhelemed I have a question for vets...
No no. You don't have to learn all by heart. You have books, online references. That's why they are there. Use them. Yes, lots of code can be reused (copy pasted).
Start small, small programs, games etc. As your experience grows, you'll find that your question is um... whatever
Start small, small programs, games etc. As your experience grows, you'll find that your question is um... whatever
Author
Quote:Original post by szecs
No no. You don't have to learn all by heart. You have books, online references. That's why they are there. Use them. Yes, lots of code can be reused (copy pasted).
Start small, small programs, games etc. As your experience grows, you'll find that your question is um... whatever
So esentially you learn by repitition? And even in the work force you'll still need to use books once in a while?
What you learn, mostly, are algorithms you can apply to different situations. It's all good and well to know that "this block of code" is used to display the player's character on-screen but it's even more meaningful if you know why "this block of code" does what it does.
You will have to memorize the instructions and special quirks of your language. That's no different than memorizing words and grammatical constructs in another language (non-programming; english-kind language I mean). What you don't need to memorize are each and every library function, class, etc. made available to you. There probably isn't a single developer who can tell you every function in the Windows API without having to look it up.
Again, like with learning a new language, learning a new programming language doesn't happen overnight (particularly if it's your first). You start remembering things easier over time as you encounter the same concepts over and over again in varying forms.
You will have to memorize the instructions and special quirks of your language. That's no different than memorizing words and grammatical constructs in another language (non-programming; english-kind language I mean). What you don't need to memorize are each and every library function, class, etc. made available to you. There probably isn't a single developer who can tell you every function in the Windows API without having to look it up.
Again, like with learning a new language, learning a new programming language doesn't happen overnight (particularly if it's your first). You start remembering things easier over time as you encounter the same concepts over and over again in varying forms.
Quote:So esentially you learn by repitition? And even in the work force you'll still need to use books once in a while?
Pretty much. A lot of things I've done often enough now that I never need to look them up, but that ability has been a few years in the making.
What I found that I actually really needed to remember was that you could do something in your chosen language or with your chosen library. You don't necessarily need to remember how to do it, just remember that it can be done. The same thing applies to various algorithms, just focus on remembering what they solve for now rather than remembering exactly how to implement them. Of course finding out those things even exist takes time and research, followed by more time to use it often enough to remember and understand how to do it without looking it up.
For example, I use OpenGL for all my graphics code. However, off the top of my head I couldn't tell you the exact functions you have to call to be able to fill a VBO with custom data and then draw that buffer. Or how to check whether a shader compiled correctly and print out the compilation error if not. But I know I can do it (I've done them both several times before) and I know where to find the OpenGL reference to tell me the exact functions to call. So it's all fine.
Author
Quote:Original post by RuneLancer
What you learn, mostly, are algorithms you can apply to different situations. It's all good and well to know that "this block of code" is used to display the player's character on-screen but it's even more meaningful if you know why "this block of code" does what it does.
You will have to memorize the instructions and special quirks of your language. That's no different than memorizing words and grammatical constructs in another language (non-programming; english-kind language I mean). What you don't need to memorize are each and every library function, class, etc. made available to you. There probably isn't a single developer who can tell you every function in the Windows API without having to look it up.
Again, like with learning a new language, learning a new programming language doesn't happen overnight (particularly if it's your first). You start remembering things easier over time as you encounter the same concepts over and over again in varying forms.
Oh... Well I know C++ well and know the basic stuff.... like Classes and Inheritances So yeah... So essentially I have to take this like my Data Structures class Learn why the stuff does what it does. Everything else will come naturally with dominance of the language correct?
This is going to sound a little "zen" or something, so bear with me.
If you are at a stage of becoming a developer where you regard a lot of things as just those things to be "memorized", you are pretty early on.
That's fine.
If that is the case, then you don't "know" C++ well. You know "of" a lot of C++ language features, and perhaps even trivial ways in which to apply them.
What you don't know (because it cannot be taught, or at least I don't know how to teach it) is how to engineer a solution.
There are a number of pieces of code in my personal repository that I've accumulated over the years. Various sorts of "boilerplates" that I can use to quickly start up a particular type of game or application. I also have a number of reusable classes/modules that have been genericized to the point where I can easily move them over into whatever project I am using.
I don't start anything from scratch. I wouldn't recommend starting anything from scratch. I actually think starting things from scratch (other than in an academic pursuit of understanding how something works under the hood, as in your Data Structures class) is foolish.
I do not believe that you have to understand every single line of code that you make use of in order to use it, either. If you found a nice boilerplate from directxtutorial, then great. Go make games. After you've worked with it enough, you'll likely understand the boilerplate pretty well.
However, I don't really use books anymore. I use online references and .CHM files and PDF files and so on, which amounts to the same thing.
Keep practicing your computer science fundamentals, and study and learn good engineering practices.
If you are at a stage of becoming a developer where you regard a lot of things as just those things to be "memorized", you are pretty early on.
That's fine.
If that is the case, then you don't "know" C++ well. You know "of" a lot of C++ language features, and perhaps even trivial ways in which to apply them.
What you don't know (because it cannot be taught, or at least I don't know how to teach it) is how to engineer a solution.
There are a number of pieces of code in my personal repository that I've accumulated over the years. Various sorts of "boilerplates" that I can use to quickly start up a particular type of game or application. I also have a number of reusable classes/modules that have been genericized to the point where I can easily move them over into whatever project I am using.
I don't start anything from scratch. I wouldn't recommend starting anything from scratch. I actually think starting things from scratch (other than in an academic pursuit of understanding how something works under the hood, as in your Data Structures class) is foolish.
I do not believe that you have to understand every single line of code that you make use of in order to use it, either. If you found a nice boilerplate from directxtutorial, then great. Go make games. After you've worked with it enough, you'll likely understand the boilerplate pretty well.
However, I don't really use books anymore. I use online references and .CHM files and PDF files and so on, which amounts to the same thing.
Keep practicing your computer science fundamentals, and study and learn good engineering practices.
No, one doesn't learn by repetition, although one does tend to remember things they repeated a lot. Let me add to what TANSTAAFL said. I agree with his point about knowing how to engineer a solution.
Experienced programmers do two things very effectively. They can recognize patterns. From language idioms to design patterns. They can also abstract out things. Looking at the forest instead of the trees, if you will. Both of these require experience.
Beginner programmers suffer from both. This is compounded by lack of fluency in the language. As pointed out, you probably recognize features of the language in isolation, but don't recognize the various idioms and patterns that rely on these features. The end result is that you can only see the massive and impenetrable wall of code.
A second point worth noting is that tutorials don't instruct you in the development process. They don't teach you to think. What they do is illustrate various patterns or idioms. API tutorials should illustrate the idioms in using that API. Looking at a tutorial helps you to organize how you look at documentation, and construct what you need.
Tutorials are a straight line path. A recipe to making something very specific, but illustrating concepts that can be used generally. Figuring out the general concepts is your responsibility as a programmer. That's why trying to understand how to program from a tutorial is a doomed endeavour.
Experienced programmers do two things very effectively. They can recognize patterns. From language idioms to design patterns. They can also abstract out things. Looking at the forest instead of the trees, if you will. Both of these require experience.
Beginner programmers suffer from both. This is compounded by lack of fluency in the language. As pointed out, you probably recognize features of the language in isolation, but don't recognize the various idioms and patterns that rely on these features. The end result is that you can only see the massive and impenetrable wall of code.
A second point worth noting is that tutorials don't instruct you in the development process. They don't teach you to think. What they do is illustrate various patterns or idioms. API tutorials should illustrate the idioms in using that API. Looking at a tutorial helps you to organize how you look at documentation, and construct what you need.
Tutorials are a straight line path. A recipe to making something very specific, but illustrating concepts that can be used generally. Figuring out the general concepts is your responsibility as a programmer. That's why trying to understand how to program from a tutorial is a doomed endeavour.
Author
Alright that makes sense I guess... BUt yeah... if I can't learn from a tutorial then where do you learn? I've learned many things from tutorials in my life.... So it's a good way to learn for me because I try to understand how it all works. Ya know? I don't take it for face value.
Suppose I ask someone who's just started their first ever programming course, how to get the time since the last loop. Their minds will likely blank, trying to figure out something they have no context for.
Except of course they do. All you need is a stopwatch, the last time you checked the stopwatch and the current time on the stopwatch.
The greatest barrier to comprehension is lack of context. But, that feeling of lack of context is generally a liar. Classes are just types, like a rock is a type. Objects are just actual examples, like an actual rock. Functions are just things you do with something, like ThrowRock().
Granted, it's best to grasp it in the context of programming, but don't confuse yourself needlessly. :)
Except of course they do. All you need is a stopwatch, the last time you checked the stopwatch and the current time on the stopwatch.
System.Diagnostics.Stopwatch stopwatch;double lastSecond;public GetSecondsSinceLast(){ double r = lastSecond; lastSecond = stopwatch.Elapsed.TotalSeconds; return lastSecond - r;}The greatest barrier to comprehension is lack of context. But, that feeling of lack of context is generally a liar. Classes are just types, like a rock is a type. Objects are just actual examples, like an actual rock. Functions are just things you do with something, like ThrowRock().
Granted, it's best to grasp it in the context of programming, but don't confuse yourself needlessly. :)
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
