> >In my dealings with universities in late 80s and again in >mid-90s, pseudo-code was *so* alive and well, that one prof >was on a campaign to "formalize" his particular dialect. So, >the CS100 students got to learn: (a) programming techniques, >(b) newest wizz-bang "formal" pseudocode language, and finally >(c) Pascal syntax, all at the same time. > >But that stuff about data structures/etc you mention is just >details. The "real" meat is the structured, top-down, stuff. >Learn that, so the theory goes, and you got time for a >capuccino in the afternoon. The rest is gravy. > ..... and of course small microcontrollers are one time where 'bottom-up' can _sometimes_ be the most appropriate approach, especially when you need to squeeze every last drop of preformance out of a chip. There are times when you just need to write some small but critical part of the code to see if something can be done at all, and then figure out how you can fit the rest of the application around it. > >I've often wondered whether CS perfessors ever actually write >any code themselves, or just think about writing code. If I >knew the answer to this, I might understand the educational >system better. > No college course is ever going to teach you how to squeeze that last byte out of a routine so it fits a smaller chip.... or use spare hardware register bits when you run out of RAM... or arrange i/o pins so you can RLF serial data in from them.... or write self-modifying interrupt code...8-) > >But you are entirely correct - "learning to learn" is really >what it's all about. Absolutely. I don't think I've ever done a project where I haven't learnt something new & useful, or thought of a trick I could have used in a previous project. >The rest is just what it takes to get a >diploma. Good tools help too. But the ability to figure out how to manage without can also be pretty useful too, like when you fry your ICE at 7PM on a Friday night! >Whatever actually works best >for you is what you want to use. >