Don't distract new programmers with OOP
Provocative.<p>The suggestion is that thinking in OO terms makes you think about architectures instead of programs, and the result is to move you away from thinking about the problem and the solution and towards thinking about the program's organization. This is always assumed to be a good thing, especially when accompanied by the usual examples of writing programs for teams of programmers with varying levels of skill.<p>But if we grant that non-OO is better for someone learning to program, why wouldn't it be better for someone reading a program for the first time?<p>EDIT:<p>Thinking further about this, I am not against the idea of design considerations that should be kept from the beginning programmer. But OO isn't really a design consideration, it's a <i>metaphor</i>.<p>If it really "worked," then new programmers would be looking all confused trying to write a Towers of Hanoi program, and you would explain, "Think of each tower as its own thing. What can it do? What does it have?" And slowly you could tease out a program by designing objects from the ground up.<p>But if it actually doesn't work to teach programming using objects, if you teach programming without objects and introduce them as an 'advanced' subject, then at some level you have to wonder if the metaphor is fundamentally broken. If the purpose of OO is design and organization rather than a fundamental way to think about programs, then really we shouldn't say things like "Everything's an object."<p>We should ask what we need to do to design well-factored programs that are cohesive without being coupled and then design language features that directly address those organization requirements rather than thinking that there is this obvious "metaphor" that naturally leads to well-organized programs.