My team works extensively close to the hardware, including writing device drivers under both RTOS and Linux (and others), and we're also finding that new graduates (from prestigious universities) lack practical computer architecture knowledge (address bus, address space, interrupts, user vs kernel)... With the exception of students who purposefully selected certain study units.
I believe this is a consequence of computer science being such a broad subject and especially with the modern focus on client-server and web technologies.
I used to think that this lack of knowledge is a damn shame, but in fact students who are interested in operating systems or embedded systems will find their way to it, whilst those interested in search, data analytics, distributed systems, graphics, parallel completing, AI, web front-end, servers, languages, etc, etc will follow a different path.
These kids are smart... And they pick things up.

It's a fair point - in a large field you can't know everything. I'm not sure what the basic common ground should be - and indeed, some CS degrees are very vocational and some are more academic.

This is what bothers me. Windows and their components as well as real life objects which can be categorized are ideal candidates for OOP. However, to expect programmers to view every aspect of programming as a collection of objects only serves to detract from the value of OOP languages in general since it is implied that a procedural approach is impossible.

Wrapping variables inside a struct or class does not automatically make something an object. For example, in database records, a struct is simply a convenient way of organizing the information contained in that datase. It doesn't make the record resemble some physical object. And in a class like java.lang.Math, would anybody seriously call that an object instead of a collection of maths functions?

Once it is realized that one can still adopt a procedural approach and use objects where naturally convenient, the value of using an OO language becomes more apparent.


The OP was discussing ways to implement jump tables and indirect pointers to functions on the 65816. This of course is necessary if you want "polymorphism" (where a pointer to one type of object is made to point to a descendant of that object) since you may not know until run time what type of object the pointer will end up pointing to.

Me? I still like pushing the destination address on the return stack and executing RTS. It works a treat on the '02 but there may be better ways on the 65618 with its 16 bit index registers and relocatable Z-page.

This discussion shows that OOP has some slowdown factor because you can't make direct function calls from an object. That may be a consideration in a system where timing is critical. The C code equivalent that I posted above still allows direct function calls. You could probably still implement polymorphism in C (with a similar degradation in performance).