[coldtea]

>> A large majority of the code running on our planet today is OOP.

> Good example code base?

It would be easier to give examples of non-OOP crucial programs, for they are far less.

OOP codebases: -- Almost all major AAA games.

-- Almost all GUI systems.

-- All major browsers.

-- Almost all video editors (NLE),

-- Almost all audio DAWs

-- All of Adobe's Suite

-- Almost all 3D and CAD tools

-- All office suites (MS Office, OpenOffice, iWork),

-- All major IDEs (Visual Studio, IntelliJ, XCode, Eclipse)

-- Most of Windows and OSX standard libraries

-- Clang (and GCC now that they went to C++? Not sure if they use OOP)

-- the JVM

need we go on?

[jstimpfle]

> OOP codebases: -- Almost all major AAA games.

Nah. As far as I hear, most of them moved away from OOP a long time ago. "Component systems" have been hot for more than five years.

> Almost all GUI systems

Come on, what a GUI does vs a non-GUI "realtime" app is pretty trivial. A bit of layouting, routing a few input events. I'm not saying that e.g. building a scene graph or box model would be the wrong thing (there are other ways as well), but yeah... I certainly don't think that inheritance makes GUIs easier. Interfaces/Function pointers/dynamic dispatch? Yes, you might want that for decoupling a few containers of heterogeneous data/behaviour. But that's hardly a monopoly of "OOP", and also you don't need that in most places.

The other projects, don't know them. Again, I'm not against abstractions per se (the Stream abstraction is one I regular use, although it does require unwrapping for proper error handling. And I have a constant number of "objects" in each of my programs, namely modules with global data). But OOP culture, especially objects-first mentality and fine-grained data encapsulation, gluing implementation to pristine data - I believe it does only harm and leads to plain wrong program structure and overcomplicated code to jump into all these boxes. I prefer gliding through arrays :-)

[coldtea]

>Nah. As far as I hear, most of them moved away from OOP a long time ago. "Component systems" have been hot for more than five years.

Nope, that's just hype. Good ole C++ still rules the day, except for specialized (and smaller in scope and speed needs) games.

>Come on, what a GUI does vs a non-GUI "realtime" app is pretty trivial.

You'd be surprised. A guy is not just "call x program with some flags" as you might believe.

Something like a NLE editor for example or even an IDE can have GUI needs that go far beyond hundreds of thousands of LOC...

(Not to mention that I was referring to GUI libraries themselves, complex beasts on their own, not GUI code as used by applications to build their GUIs).

[jstimpfle]

> Nope, that's just hype. Good ole C++ still rules the day, except for specialized (and smaller in scope and speed needs) games.

Sure, it's C++, and in my perception much C-style C++. And C++ != OOP.

> (Not to mention that I was referring to GUI libraries themselves, complex beasts on their own, not GUI code as used by applications to build their GUIs).

I will admit I haven't written a NLE program, but integrating complex logic with a complex and hard to understand GUI framework like Qt, meaning there are a lot of states to synchronize, is a lot of inessential complexity. I'm pretty sure it's much easier when you only use GUI primitives and do most of the coding on your own. E.g. a standard box layouting and event bubbling algorithm can't be that much work, and it's MUCH MUCH easier to do it on your own and choose the appropriate structure, instead of writing many helper classes trying to bend the rigid framework.

Taking the example of a NLE program - it has lots of domain-specific state which you must absolutely understand if you want to write such a program. And you absolutely must have a vision how this state should be reflected on the screen. Choosing how to do it is a lot of work. Actually drawing it should be the smaller amount of work, by far. Just separate the state from the GUI library. If you scatter it over thousands of objects, inheriting implementations that you don't own and don't understand - well, of course! that's really hard.

[coldtea]

>Taking the example of a NLE program - it has lots of domain-specific state which you must absolutely understand if you want to write such a program. And you absolutely must have a vision how this state should be reflected on the screen. Choosing how to do it is a lot of work. Actually drawing it should be the smaller amount of work, by far. Just separate the state from the GUI library. If you scatter it over thousands of objects, inheriting implementations that you don't own and don't understand - well, of course! that's really hard.

My point was rather than just the essential GUI functionality and interactions for such a program can be very complex.

In other words, when to show this or that, how to structure code to show it fast, how to present it best, etc is also essential logic (not some afterthought on top of the domain logic), and it can also be super-hard to code (depending on the kind of program).

[jstimpfle]

> how to structure code to show it fast

It's pretty trivial, at least not any sort of GUI-specific hard problem. There is only a low number of objects on any given screen. Don't raster pixel-by-pixel on the CPU, of course.

[coldtea]

It's only pretty trivial if you're doing an app that has some forms and does some CRUD and so on.

For anything above that, it can hairy real fast.

[coldtea]

>> Nope, that's just hype. Good ole C++ still rules the day, except for specialized (and smaller in scope and speed needs) games. Sure, it's C++, and in my perception much C-style C++. And C++ != OOP.

Sorry, meant to write "good old OOP still rules the day".