4 ms·

In my view, the root of the problem is Object Oriented Programming itself. The older I get the more I like having having separate data and functions. Serializ

In my view, the root of the problem is Object Oriented Programming itself. The older I get the more I like having having separate data and functions. Serialization is easier, network communication is easier, testing is easier. You can put your functions in modules grouped roughly by what kind of data they operate on, but you don't have to be creating "objects".

Spivak 3y ago
> The older I get the more I like having having separate data and functions. Am I missing something or is this just OO but with func(obj) instead of obj.func()? Like the data is your instance but you have to track the types and remember what functions work on what. The coupling is just implicit now.
- jay_kyburz 3y ago
  yes but, when you think some more about that means a lot. There is no such thing as inheritance, you route your data through different functions. There is no such thing as private data, its all public by default. You can still have strict types I guess, to make sure you are passing the right kind of data into the right function. But most of my experience coding this way is js and lua. I only code like this for my home projects, I have no idea what it would be like working in a team of 10 programmers all rushing to jam new features into a giant code base.
  - za3faran 3y ago
    You don't have to use inheritance, but it's there when you need it. Private data are also very useful.
  - lelanthran 3y ago
    > There is no such thing as private data, its all public by default Not in C, put the strict declaration in the h after and the definition in an implementation source file. Callers of the implementation functions can pass the strict around without seeing any of the fields. Only functions in the implementation can access the fields which results in all acce to the fields going through the implementation only. Cleaner and safer than letting the caller see everything while only accessing some things.
- sk0g 3y ago
  Coupling is only implicit if you use a dynamically typed language. Also, in languages with UFCS func(obj, something, else) can be expressed as obj.func(something, else). The calling syntax can thus remain the same even without defining the function within some arbitrary object.
- kaba0 3y ago
  There is an old joke somewhere about some monk and a programmer who is looking for enlightenment and circling through OOP, realizing it has always been FP, which has always been actors, which has always been OOP..
randomNumber7 3y ago
In the rare case where you need runtime polymorphism it is nice. I also think people over use it (hello C#). If you don't need it for polymorphism its only syntactic sugar anyway, and it gets a heck of confusing (imho) when people think it does s.th. else. Like how does it make code cleaner when you put the sinus function into a class? And while this might be an extreme example, you can have a function which operates on two data elements. But because your doing "OO", you arbitrarily put the function into on class. Everything else would be a code smell. I dont think this is what OO was originally about, but it doesnt speak for the average developer what happened there...
- kaba0 3y ago
  If you mean static methods inside classes, I don’t think those are any different than a namespace. They should be thought as such (e.g. java’s Math::sin, not sure how it’s done in C#)
  - randomNumber7 3y ago
    I mean both. Non static non virtual functions are essentially just normal functions where you don't see the "this" pointer. And you call ob.foo() instead foo(ob). Of course it's better syntax and often convienient. But many people think there is more to it ("Im doing object oriented programming"), while it is semantically the same. PS: I get that for namespaces it's not that bad. But still, why not use a namespace? Now you use classes for two completely unrelated things. Congrats Java and C#, your programming language needs one keyword less.
    - kaba0 3y ago
      That’s just the “Turing-equivalency” argument, of course in the end we just jump to different points in the code. That doesn’t make it OOP nonexistent.
shaunxcode 3y ago
It’s been so long I sometimes forget why I left. Thanks for the reminder.

Spivak 3y ago

> The older I get the more I like having having separate data and functions. Am I missing something or is this just OO but with func(obj) instead of obj.func()? Like the data is your instance but you have to track the types and remember what functions work on what. The coupling is just implicit now.

jay_kyburz 3y ago
yes but, when you think some more about that means a lot. There is no such thing as inheritance, you route your data through different functions. There is no such thing as private data, its all public by default. You can still have strict types I guess, to make sure you are passing the right kind of data into the right function. But most of my experience coding this way is js and lua. I only code like this for my home projects, I have no idea what it would be like working in a team of 10 programmers all rushing to jam new features into a giant code base.
- za3faran 3y ago
  You don't have to use inheritance, but it's there when you need it. Private data are also very useful.
- lelanthran 3y ago
  > There is no such thing as private data, its all public by default Not in C, put the strict declaration in the h after and the definition in an implementation source file. Callers of the implementation functions can pass the strict around without seeing any of the fields. Only functions in the implementation can access the fields which results in all acce to the fields going through the implementation only. Cleaner and safer than letting the caller see everything while only accessing some things.
sk0g 3y ago
Coupling is only implicit if you use a dynamically typed language. Also, in languages with UFCS func(obj, something, else) can be expressed as obj.func(something, else). The calling syntax can thus remain the same even without defining the function within some arbitrary object.
kaba0 3y ago
There is an old joke somewhere about some monk and a programmer who is looking for enlightenment and circling through OOP, realizing it has always been FP, which has always been actors, which has always been OOP..

randomNumber7 3y ago

In the rare case where you need runtime polymorphism it is nice. I also think people over use it (hello C#). If you don't need it for polymorphism its only syntactic sugar anyway, and it gets a heck of confusing (imho) when people think it does s.th. else. Like how does it make code cleaner when you put the sinus function into a class? And while this might be an extreme example, you can have a function which operates on two data elements. But because your doing "OO", you arbitrarily put the function into on class. Everything else would be a code smell. I dont think this is what OO was originally about, but it doesnt speak for the average developer what happened there...

kaba0 3y ago
If you mean static methods inside classes, I don’t think those are any different than a namespace. They should be thought as such (e.g. java’s Math::sin, not sure how it’s done in C#)
- randomNumber7 3y ago
  I mean both. Non static non virtual functions are essentially just normal functions where you don't see the "this" pointer. And you call ob.foo() instead foo(ob). Of course it's better syntax and often convienient. But many people think there is more to it ("Im doing object oriented programming"), while it is semantically the same. PS: I get that for namespaces it's not that bad. But still, why not use a namespace? Now you use classes for two completely unrelated things. Congrats Java and C#, your programming language needs one keyword less.
  - kaba0 3y ago
    That’s just the “Turing-equivalency” argument, of course in the end we just jump to different points in the code. That doesn’t make it OOP nonexistent.

shaunxcode 3y ago

It’s been so long I sometimes forget why I left. Thanks for the reminder.