Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

OOP should be something you only get into after you have written some practical programs

I'd modify that to "practical programs that are nontrivial enough to benefit from OOP", just like how I advocate not teaching about functions until they become useful. IMHO the CS curriculum should start with the low-level basics and work up from there in a natural progression:

    - Representation and interpretation of binary data.
    - Basic straight-line computation (more like calculation), concept of instruction execution
    - Flow control: decisions, loops
    - Functions/procedures/subroutines
    - Grouping data together: Arrays/structures/records/etc.
    - Basic OOP, grouping data and code together: Objects, composition, inheritance
    - Advanced OOP: virtual functions/polymorphism/etc.
I have worked with some of that type of Java-student you mention, and it is astounding how many can create huge object-oriented monstrosities (including design patterns), the bulk of which are object creation and method calls, while not understanding arrays or even basics like why datatypes have a finite range. Their code has more object creation and method calls than branches, loops, or simple computational statements. Given that sort of inverted knowledge they have, that they fail fizzbuzz is not surprising at all. It also explains a lot of the inefficiency and bloat in most software. It's somewhat like teaching calculus to students who don't know arithmetic.


Would it make sense to not jump to only OOP after 'grouping data together', but to provide FP approaches in parallel?




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: