Abstract Learning and Our Minds, A Conversation

This is one of the most fascinating conversations I have ever had. The conversation has been edited for content in order to keep it as on-topic as possible without losing the flow.

SYNOPSIS

Postulate 1: All learning is abstraction based. You become good at a specific discipline by developing a progressively more advanced abstract "language" for that discipline.

Postulate 2: All skills are technique-based. Likewise, all skills are hierarchical sets of distinct "techniques" that build on one another. This is most obvious in math, but applies to all skills across all disciplines.

Theorem 1: There are two ways of learning: Brute-force, and technique-based. The former can basically be summed up in the artistic creed of "Draw, draw, and draw some more." The latter can be represented by Math, which is essentially 20 years of various techniques being taught to you, each one building upon the one before it.

Theorem 2: A more efficient method of learning may exist as "Top-down" learning. Given a single technique, say, the ability to solve an algebraic problem, one can disassociate this technique into a tree of progressively simpler sub-techniques, all the way down to the basic concept of adding two things together.

Interesting.

And while many artists associate skill with just drawing tons, I can't help but note that the best artists I follow are the ones who get one or two things out a month, if that. At some point quantity stops leading to quality, and the artist in question figures out that having patience on one piece at a time is generally more rewarding than spewing out 20 quickies a day.

Beyond that, mass quantity drawing has mainly just helped me refine my ability to draw a line that behaves with a bit less of a shake or skew in direction to it over time. You get a bit better of an eye for things, yes, but nothing has ever topped actually being taught proper methods in a real, college-level art class. Figure drawing probably could have helped me a lot but I don't think I'd get away with drawing nudes while living with my mother.

The top-down thing sounds really interesting, but does it have to be limited to math? I can see it being the most obvious implementation, but wonder if it couldn't be used for thigns like drawing and music, as well. Hell, we kinda do that every time you try to help me figure out EQ and such, we just don't set out iwth that purpose in mind.

Math was used only as an example. The entire hypothesis applies to every single skill imaginable.

I don't think that the top-down method would work too well for programming, though I could see it work very well for things like math or art.

One argument is that math and the arts are sciences that humanity has explored for a long long time, while programming and the likes is relatively new.

Actually, I think I can narrow it down a bit, while top-down could work well in graphic based programming I don't see it working in logic based programming.

When writing a class to do certain things, you can't start by writing the class and then focusing on the individual components, at least I can't. I find you have to start by focusing on each component, learning what it needs to work, and then building it into other parts of the class.

But then again right now my view on the world is limited to what you learn in high school, which is more of a sterile sandbox environment.


I just had a thought, could to define top-down learning as simply learning in the other direction? As I understand it, in math, you can start with a process, and then learn how and why each part of it works; or, you can start with a condition and something to prove and then go through a lot of work actually building the process to prove it. The example the comes to mind are proofs of relations in geometry.

And on what you said with art this seams to work well as well. You were, correct me if I'm wrong, discussing how artists can get better at art by learning about different techniques and the effects that they have. Yet I know a guy who when he starts drawing, I've seen him do this, he will draw little things in random places at it doesn't become apparent what he is doing until the near the very end. So that makes me assume that he can already see the complete picture in his head of what he is drawing before he touches the paper. Which would be the opposite of using techniques to build up a picture.

*epic wall of text*

I'll read this sometime when I'm not half drunk and about to fall asleep.

Please read the full conversation. I address this in explaining that artists are artists because they do not build things out of successive techniques, but rather take a complete idea and turn it into reality by using whatever techniques work best.

The Top-Down method must be done in a very specific way, wherein we identify the Ultimate Goal, and then work our way down the tree until we reach a concept that must be clarified. As each concept is clarified, it is explained how the new knowledge can be applied to the technique above it, and is then repeated until you reach the Ultimate Goal, at which point you move to the next branch, and then the next, until the entire tree is "solved." This form works for anything, no matter the discipline or context. In some cases (I.E. learning how to walk) it is impractical not because it isn't applicable but rather because we already have complex abstract languages preprogrammed into our neural structures.

The only time I've ever learned jack has been, really, when I have an ultimate goal to apply it to. This is especially true in programming, wherein I won't even look into doing something until I know what it is I'm trying to accomplish, because otherwise all the rest of the process of learning a language is just lost to me. Thus, C++ I can't retain for the life of me, but GML I can grasp with relative ease; while I understand the need to know the basics of programming, the ability to know what you want to do, look up how to do the steps you believe to be the process, and try to apply them is why I've stuck with Game Maker despite its relative constrictions. It's also why for me MSDN is borderline useless, because if you don't know how to do something in the first place, that stupid thing isn't going to help you figure it out.

So in some sense top-down is how I've taught myself what little programming I actually use. I did it with GML and was after the same thing with XNA when I was tinkering with that, and it's never led me wrong. Give a goal to aim for, break it into parts, and keep breaking it down until you have the basic concepts you need to assemble to make it all work. How basic of concepts you need to break it down to kinda rolls with your base knowledge of the subject to begin with - a person who's never touched programming before would need to start from the assorted variable types as opposed to someone with a little practice just hopping in to assorted functions and such - but all in all I'd say Erik's method stands.

I did, I thought your point of view switched again before the end of it, I'll reread and re-reread everything again, just not now, but I will.

Ironically Fittingly the way you have explained programming as a "tree" is a more abstract definition of programming than I have been exposed to. Personally, I find the bottom-up method, learning techniques and then using those to expand, to work better for me in math and programming but I won't dispute that the top-down method will work too.

Nvm it looked more interesting when I was drunk.