3 ms·

> OOP is entirely about writing GUIs. (Well, the C++ idea of OOP.) Nope. One thing I like to do in C++ is, on an embedded system, wrap an object around a hard

> OOP is entirely about writing GUIs. (Well, the C++ idea of OOP.) Nope. One thing I like to do in C++ is, on an embedded system, wrap an object around a hardware resource. It means that no other code needs to know about the details of talking to that hardware. Also, if there are multithreading concerns, it leaves a very small set of places to worry about mutexes.

marcosdumay 2y ago
Ok, so you like to use OOP to emulate a module system. Yeah, plenty of people like that too. That doesn't make it an application for OOP. The fact that the 90s killed the modular languages is quite a bummer, as neither modern FP nor C++ style OOP have anything nearly as useful.
- AnimalMuppet 2y ago
  Shallow dismissals aside, do you have anything of substance to say? I'd especially like to see your justification for saying "That doesn't make it an application for OOP".
  - marcosdumay 2y ago
    FP languages will give you the exact same abstraction (not that you'd want to use any on a device driver). And before OOP was hyped and pushed everywhere, you could already get the same thing, but better (not on C, of course). The fact that you need objects to get this on your current language is a bug, not a feature. (There is the one version of OOP that most people call "multi-agent systems" that would bring very good abstractions to a driver, but it's not C++'s OOP, and you'd need a heavyweight library to get it there.)
    - DeathArrow 2y ago
      What modular languages with "multi-agent systems" are you talking about? Please give some examples. The only domain where I saw "multi-agent systems" paradigm being used is AI, not programming languages.
      - loup-vaillant 2y ago
        Actors maybe? As in Erlang?
  - loup-vaillant 2y ago
    > One thing I like to do in C++ is, on an embedded system, wrap an object around a hardware resource. It means that no other code needs to know about the details of talking to that hardware. That, my friend, is modular programming. It is not specific to hardware, and not at all exclusive to OOP. In fact, C can do it just as easily as C++: typedef struct { // Private stuff, do not rely on it int bar; float baz; } foo_ctx; int foo_init (foo_ctx *ctx); void foo_cleanup (foo_ctx *ctx); int foo_frobnicate(foo_ctx *ctx, int frobnicator); And if you don't like putting private data in the header file, we can have a pointer to implementation and hide it even better than idiomatic C++ (I don't like this much, because this requires allocations the above avoids): struct foo_ctx; // forward declare typedef struct foo_ctx foo_ctx; foo_ctx *foo_new (); void foo_delete (foo_ctx *ctx); int foo_frobnicate(foo_ctx *ctx, int frobnicator); Some would say I'm just emulating OOP in C. Except I'm not. There's no class in there, just a data structure with opaque data in it, and functions that operate on it. --- I find it especially tiring when people use classes to do modular programming, call it "OOP", and assume it doesn't exist elsewhere, or was an OOP invention. OOP coopted modules, and put light syntax sugar to call it its own. And I can already hear you scream that I'm "emulating OOP in C", though what I'm actually doing is emulating modular programming in C. And if we insisted on making it look like C++, there are indeed 2 missing ingredients. The first one would be overloading on the type of the first argument. With that we would no longer care about name clashing, and could write the module like this: typedef struct { int bar; float baz; } foo; int init (foo *this); void cleanup (foo *this); int frobnicate(foo *this, int frobnicator); The second missing ingredient would be syntax sugar so `f(x, y)` could be written `x.f(y)` instead. That way the calling code could really feel OOP, even though it's little more than a thin layer of syntax sugar. I have even done it myself. Wrote a scripting language for a client who wanted OOP. Instead I gave them function overloading and universal call syntax, and they didn't notice a thing. --- When you think about what OOP really is, there's not much. There's the idea of instantiation, where instead of using global variables you define a data structure and instantiate it under one local name. OOP made this popular, though I'm not sure it's not another cooptation. Any language that have user defined types can do that. Then there's inheritance, which is mostly a mistake (in my experience inheritance is best avoided unless absolutely necessary — and it is almost never necessary). And finally there's subtyping, which is nearly interchangeable with closures. It's a bit more powerful, but it is also a bit more cumbersome, and the added power is rarely needed in my experience. --- Anyway, when one repeats the above often enough, there comes a time where one had enough, and just write a quick dismissal. When it comes don't to it the conclusion is fairly simple: OOP ain't so hot.

marcosdumay 2y ago

Ok, so you like to use OOP to emulate a module system. Yeah, plenty of people like that too. That doesn't make it an application for OOP. The fact that the 90s killed the modular languages is quite a bummer, as neither modern FP nor C++ style OOP have anything nearly as useful.

AnimalMuppet 2y ago
Shallow dismissals aside, do you have anything of substance to say? I'd especially like to see your justification for saying "That doesn't make it an application for OOP".
- marcosdumay 2y ago
  FP languages will give you the exact same abstraction (not that you'd want to use any on a device driver). And before OOP was hyped and pushed everywhere, you could already get the same thing, but better (not on C, of course). The fact that you need objects to get this on your current language is a bug, not a feature. (There is the one version of OOP that most people call "multi-agent systems" that would bring very good abstractions to a driver, but it's not C++'s OOP, and you'd need a heavyweight library to get it there.)
  - DeathArrow 2y ago
    What modular languages with "multi-agent systems" are you talking about? Please give some examples. The only domain where I saw "multi-agent systems" paradigm being used is AI, not programming languages.
    - loup-vaillant 2y ago
      Actors maybe? As in Erlang?
- loup-vaillant 2y ago
  > One thing I like to do in C++ is, on an embedded system, wrap an object around a hardware resource. It means that no other code needs to know about the details of talking to that hardware. That, my friend, is modular programming. It is not specific to hardware, and not at all exclusive to OOP. In fact, C can do it just as easily as C++: typedef struct { // Private stuff, do not rely on it int bar; float baz; } foo_ctx; int foo_init (foo_ctx *ctx); void foo_cleanup (foo_ctx *ctx); int foo_frobnicate(foo_ctx *ctx, int frobnicator); And if you don't like putting private data in the header file, we can have a pointer to implementation and hide it even better than idiomatic C++ (I don't like this much, because this requires allocations the above avoids): struct foo_ctx; // forward declare typedef struct foo_ctx foo_ctx; foo_ctx *foo_new (); void foo_delete (foo_ctx *ctx); int foo_frobnicate(foo_ctx *ctx, int frobnicator); Some would say I'm just emulating OOP in C. Except I'm not. There's no class in there, just a data structure with opaque data in it, and functions that operate on it. --- I find it especially tiring when people use classes to do modular programming, call it "OOP", and assume it doesn't exist elsewhere, or was an OOP invention. OOP coopted modules, and put light syntax sugar to call it its own. And I can already hear you scream that I'm "emulating OOP in C", though what I'm actually doing is emulating modular programming in C. And if we insisted on making it look like C++, there are indeed 2 missing ingredients. The first one would be overloading on the type of the first argument. With that we would no longer care about name clashing, and could write the module like this: typedef struct { int bar; float baz; } foo; int init (foo *this); void cleanup (foo *this); int frobnicate(foo *this, int frobnicator); The second missing ingredient would be syntax sugar so `f(x, y)` could be written `x.f(y)` instead. That way the calling code could really feel OOP, even though it's little more than a thin layer of syntax sugar. I have even done it myself. Wrote a scripting language for a client who wanted OOP. Instead I gave them function overloading and universal call syntax, and they didn't notice a thing. --- When you think about what OOP really is, there's not much. There's the idea of instantiation, where instead of using global variables you define a data structure and instantiate it under one local name. OOP made this popular, though I'm not sure it's not another cooptation. Any language that have user defined types can do that. Then there's inheritance, which is mostly a mistake (in my experience inheritance is best avoided unless absolutely necessary — and it is almost never necessary). And finally there's subtyping, which is nearly interchangeable with closures. It's a bit more powerful, but it is also a bit more cumbersome, and the added power is rarely needed in my experience. --- Anyway, when one repeats the above often enough, there comes a time where one had enough, and just write a quick dismissal. When it comes don't to it the conclusion is fairly simple: OOP ain't so hot.