Jump to content
  • Advertisement
Sign in to follow this  

Bottom-Up Learning: Is it possible to learn quicker this way?

This topic is 2351 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

Quoted from an O'Reilly published programming-related technical book excerpt:


A top-down learner prefers to read or skim documentation, getting a large overview of how the system works; only then does she actually start using the soft-ware. A bottom-up learner is a “learn by doing” person—someone who just wants to dive into the software and figure it out as she goes, referring to book sections when necessary.
[/quote]

I'm more of a bottom-up learner when it comes to programming, but I'm a top-down learner when I must learn new things, like Git, Subversion, any math, etc. However, I can't say I'm exactly 100% correct for those two assumptions.

And it dawned on me a thought. Would it be possible that someone more experienced than me had came across one or two books that teaches programming bottom-up? I have only seen a few books, and they are written for top-down learners, so I really can't answer that question right off the bat, but it made me to reason why there wasn't an obvious programming book teaching OpenGL, DirectX, or something similiar from bottom-up, and that they also have the probability of appearing on bookshelves out there, and should probably be showing up in my hands.

And the more I think of it, the more clearer the whole thought process becomes. Why am I not a bottom-up learner? Do you suppose that you learn quicker if you had done programming from bottom-up? Thus the topic of this thread was born. I can't express myself how happy I came up with this reasoning, and how it wasn't asked right here in GameDev Forums. Of course, I know about the article mentioning about game design, top-down vs. bottom-up, when you do a quick search in Google. But here, I'm asking about the approach.

So, what's your opinion? :)

Share this post


Link to post
Share on other sites
Advertisement

And it dawned on me a thought. Would it be possible that someone more experienced than me had came across one or two books that teaches programming bottom-up? I have only seen a few books, and they are written for top-down learners, so I really can't answer that question right off the bat, but it made me to reason why there wasn't an obvious programming book teaching OpenGL, DirectX, or something similiar from bottom-up, and that they also have the probability of appearing on bookshelves out there, and should probably be showing up in my hands.

I'm not sure I have ever seen a truly top-down programming text. There are some theoretical computer science textbooks like that, but I am not sure it is even feasible to teach most languages/APIs in a top-down fashion.

Take your average OpenGL text: it starts with creating an OpenGL context, moves to drawing a triangle, then a textured triangle, etc. Eventually moving onto a discussion of the shader pipeline and GPU architechture as it applies to OpenGL programming.

A top-down book would spend at least half it's pages discussing matrix math, colour theory, the architecture of modern GPU pipelines, and the ins-and-outs of the shader pipeline, all before you got to a single line of code. That type of book is (justifiably) very hard for the beginner to follow - so very few books are written in that fashion.

Share this post


Link to post
Share on other sites
People learn best in different ways.

There are pros and cons to both the "RTFM" crowd and the "baptism by fire" crowd.

Those who learn primarily by reading the manual and never actually touching code will tend to learn the theory of how things are supposed to work, but may put focus on the wrong topics and may miss critical differences between design and implementation that would have been picked up by examining live code.

Those who learn primarily by jumping in and copying what already exists will tend to learn how things are done, but may unwittingly copy the worst practices while ignoring the best, or may introduce severe and subtle issues by overlooking nuance that could have been picked up by the manuals.



You will need both skills in the workforce.

You will be expected to understand systems simply from design documents with no code associated. You will also be expected to understand and infer meaning from systems that are completely undocumented. Most often you will have both documentation and live code, but you must be prepared to occasionally work with the extreme cases.

Share this post


Link to post
Share on other sites

Take your average OpenGL text: it starts with creating an OpenGL context, moves to drawing a triangle, then a textured triangle, etc. Eventually moving onto a discussion of the shader pipeline and GPU architechture as it applies to OpenGL programming.

A top-down book would spend at least half it's pages discussing matrix math, colour theory, the architecture of modern GPU pipelines, and the ins-and-outs of the shader pipeline, all before you got to a single line of code. That type of book is (justifiably) very hard for the beginner to follow - so very few books are written in that fashion.


Few programming books are written in that fashion of math first and application second, but a few are.

Most mathematics books in linear algebra are exactly as you describe placing the math first and the application of the math in graphics later; few describe application before theory.


Both approaches are appropriate, but for different audience. Graphics programming is applied mathematics. If you are approaching from the numeric theory side, do that first. If you are approaching from an applied trade side, do that first instead. Neither is inherently better except through context.

Share this post


Link to post
Share on other sites
I find that I need both approaches. I like to get the overview and see where and how things fit in to the bigger picture, but I also make use of more detailed targetted documentation, and I tend to not really get a concept without both.

Share this post


Link to post
Share on other sites

Do you suppose that you learn quicker if you had done programming from bottom-up?

I suppose everyone learns best by staying within his or her comfort zone.
A bottom-up learner can’t learn via top-down, and vice-versa.

If you lean naturally one way or the other then that is just how you need to learn. Rubbing against the grain won’t make you more efficient, even if it does work for some others.


L. Spiro

Share this post


Link to post
Share on other sites
My advice would be to not be obsessed with learning quicker. The only real way to learn "quicker" is to put in more time per day, with the realisation that one can only learn so much in one day of course.

It is said that it takes 10000 hours to become "great" at something. It makes no difference what that thing is. There are no shortcuts.

top-down, bottom-up, doesn't matter. You need to learn to do both anyway.

Share this post


Link to post
Share on other sites
Well, when I first started learning, I just watched/read tutorials, and did exactly what they did, and learned nothing from it.

When I actually come up with a program I really needed, and tried to make it, I not only re-learned (it had been awhile) what the tutorials taught me, but also about 500x more within just a couple days. For me learning by doing was definitely the best method. That said, I had already read a lot in tuorials, so I started top-down, got a general feel for it, and then went to bottom-up. So, perhaps both might be best.

Share this post


Link to post
Share on other sites
Sign in to follow this  

  • Advertisement
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

Participate in the game development conversation and more when you create an account on GameDev.net!

Sign me up!