> If you're learning theory before running into WHY you need that theory then you by definition don't care
My point is that there does not need to be a need for the theory. Learning for the sake of knowledge is enough. If you don't care about that reason though, learning much of theory will be hard unless you have a more concrete reason (a need for the theory in practice).
> Do you think I could write a radix sort off the top of my head with no prep time? What about something easier like a merge sort? No. I don't care because my job isn't writing sorts.
I think pretty much all programmers should be able to write a merge sort off the top of their heads. At its core mergesort is really just `merge(mergesort(leftside),mergesort(rightside))` which should not be hard to remember and writing the splitting of the list and merge is something any decent programmer should be able to do.
I will give a pass on radix sort though, it is a little more complicated and not at widely known. (I would also excuse not knowing how to implement heapsort).
> > The same could be said for teaching implementation. Thoughtless memorization is rarely useful in any field. You can instead have them discover the theory like they would discover an understanding of implementation you advise.
> The entier point of my post is to say we shouldn't do that. We should give them a task that they will want to acomplish
I am not sure I understand your response. Would you not have people naturally discover theory with strategically minded hints to help make sure they don't get stuck for a long time?
> The theory should come as you get stuck, not before. The act of getting stuck and then pulled out of the hole is what teaches you when something is meant to come in handy.
> One such example is when your car battery dies. You probably don't have one of those self-jumping battery packs in your car but they come in handy. You only ever see why after your battery goes flat and you cant find anyone to give you a jump.
Oftentimes you need to know the applicable theory before you get into a problem that necessitates it because you would never know that the theory even existed unless you had studied something related. For most practical people, a decent taste of some of the big theoretical ideas should be learned simply to facilitate later on-demand looking up of theory.
For example, big O is a powerful concept, but you may not have ever heard of it unless you looked into theory of algorithms. Despite that you may start writing some brute force (exponential time complexity) algorithm and not realize that is a problem while working on AI pathfinding for a game. Despite there being many polynomial time complexity algorithms out there.
More seriously though, knowing a number of NP-complete problems may help you realize that a problem you are working on is NP-hard and thus you should stop looking for a polynomial algorithm for it (unless you think you can break NP =? P).
Following your analogy, what if you never knew that even jumper cables existed and instead got your car towed to a mechanic every time your battery died. You may learn about jumper cables after doing that once, but it would have been much better if you knew they existed beforehand.