> feel that you greatly misunderstand why theory is important. It is not just something to be memorized to aid in implementation. It is useful and interesting in its own rite. CS Theory is Mathematics and like mathematics can be pursued simply with the goal of better understanding.
I don't think you understand what I mean. I don't mean the theory isn't important. Nor do I feel that the only thing important is the theory.
What I do feel is this:
- If you're teaching someone something they don't care about yet and wont remember, it's useless
- If you're learning theory before running into WHY you need that theory then you by definition don't care
Our field should be about hiding the unimportant abstraction for the time being and it shouldn't be able shoving it in your face and saying "you'll need this in 3 years when we get to graphs".
No one will remember that. I have a hard time remembering every single "important algorithm". 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. Most of the time using the built in language sorting function is ok. If I need to write one I choose based on the language I'm using and task by sitting down, thinking through my past experiances and what I used them (like not using a radix for floats/strings and instead using a merged quicksort). After I find one that'll work like it has in the past I google for that and reimplement the algorithm.
There are hundreds and thousands of ideas that I need to keep in my head when programming of which sorting is one of the least important ones.
> 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 and like every good task you take one too many cakes from a stranger and fall into a rabit hole of other problems. You can go from
- I need a script to manage this deamon
- Now I want logs parsing and a way to run analytics on them
- Ok now I want to run realtime events triggered by these log lines
- One of those needs to be a SMS service, let me go write that
And that goes on and on and on and on until you run into every problem in the book a software developer runs into.
Feature creep, undocumented code, bad styles, slow performance due to features, breaking changes, why a dev enviroment is important.
Programming is a small part of being a programmer.
> Much of the theory of CS is not particularly hard to work out yourself if you are given the right hints
That's exactly how I feel.
> Personally, it was not a great start for me (I started with C; not exactly the lowest level, but lower than most CS courses nowadays).
C has many problems that are not present in far lower levels in the stack. In assembly you can do anything any way. You don't need to care. You have a magical way to save the contents of a register and get it bad, to go to a subroutine, and a massive set of "pre-defined functions" (instructions).
On older, simpler, systems this was even less of a problem. For instance a Z80 machine has huge advantages one such being the amazing instruction set and extremely simple features.
> I would have preferred to learn more theory earlier in my learning, and that is not easy to do when you are focused only on the code and not on the ideas behind the code that are universal
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.