Procedural vs OOP: power, memory size, etc

[El Mano]

I just found this:
http://users.uom.gr/~achat/papers/relsoft.pdf

It's not really surprising but still it's good to see some numbers on this.
IMHO OOP is good only for fast and cheap coding. It produces un-optimized code and innecesarily large programs that consume too much resources.

[W1zzard]

interesting paper, but it fails to mention the better maintanability and higher productivity from going OO. the author also talks about embedded systems, not desktop class machines

the examples chosen seem to be math intensive routines, not simple glue code which most of the actual programming is.

the correct paradigm for software development is to use the most efficient (in terms of your time and your bosses $), simple, readable, debuggable method to achieve your goal, then optimize code sections that a lot of time is spent in.

[desnudopenguino]

The major selling point with OOP is it's re-usability. If you build up a nice "tool box" of classes early on in your career, you are able to pull them out and reuse them all the time. I didn't find anything really that surprising from the paper. From what I've seen, procedural programming is rather specific, and if you are working on hardware like an arm processor, you might want code to be tight and specific. It would be interesting if they took more different languages though. This paper only focused on C-style, I'm assuming procedural C, and C++. I'm sure that if you wrote code in assembly, it would be more efficient than C for example. I'm not a computer scientist, just a web and light application programmer, and I see where both styles of programming can have pros and cons. The programming language and the style of programming should all be thought out ahead of time and planned for in the application specifications or design document, depending on the strengths of a language in the realm of the project. And this project was done with an emulator... I would think that an experiment would be performed using the actual hardware being tested to remove some of possible confusion and false information coming form an emulated system. Just my opinion, being an academic who reads papers like this all the time. And anyway, having a 6-18% hit on performance on average to save the rewriting of possibly thousands of lines of code on a daily basis doesn't sound that terrible, especially with the hardware we now have. True it may lead to lazy programmers, and unoptimized code. And the power differences in many of those are almost miniscule at < 1mJ. Sorry if my rambling is somewhat incoherent, it's getting early here. Memory is another thing, and out of the range of my experience (like I said, I'm a web and light app developer). Anyway, thanks for stimulating my mind this late (or early)!

[TeslaNick]

What is an unnecessarily large program?

W1zzard connects nail with hammer: For non-trivial applications, procedural programming cannot sufficiently manage complexity. While low-level and performance-sensitive parts of an application should be as close to the metal as is feasible, the core of the application should be written to an appropriate level of abstraction. In the most common use case, this means adopting object-oriented programming, although I find AOP to be a far more interesting and expressive superset of OOP.

OOP also lends itself well to hygenic development practices: comprehensible documentation, unit testing, separation of concerns, and loose coupling.

[Section8]

What is an unnecessarily large program?

W1zzard connects nail with hammer: For non-trivial applications, procedural programming cannot sufficiently manage complexity. While low-level and performance-sensitive parts of an application should be as close to the metal as is feasible, the core of the application should be written to an appropriate level of abstraction. In the most common use case, this means adopting object-oriented programming, although I find AOP to be a far more interesting and expressive superset of OOP.

OOP also lends itself well to hygenic development practices: comprehensible documentation, unit testing, separation of concerns, and loose coupling.


My first language was procedural based and I think a great way to get into programming and a good way to learn the basics. Now I could never imagine going back to it. The reasons you list for OOP are excellent and exactly why OOP is now the norm.