3 ms·

private data, convenience Which can be easily achieved without OOP.

by jqpabc123 4mo ago

pitched 4mo ago
That upfront convenience here leads to a long tail of job security when it inevitably goes spaghetti. Win-win!
- gf000 4mo ago
  Spaghetti ~ complexity ~ entropy. That's the natural order of things that many people work in, I doubt any "general loosely defined paradigm" can be absent from the inevitable.
pjmlp 4mo ago
In fact, to a certain point of view, OOP is a way to have modules bind to variables, and being extensible.
- jqpabc123 4mo ago
  And the price for this is constrained flexibility and utility. Data has value and utility on it's own --- as much as if not more than code that manipulates it. It is often not possible to foresee all the ways it can and will need to be used. So why bind anything to it? Relational databases were invented to provide flexibility with regard to data. OOP tries to encumber it --- often referred to as an "impedance mismatch".
  - pjmlp 4mo ago
    Proper designed modules also don't expose more than the essentially necessary on their public interface. Failure to understand this is what leads many into microservice hell, as they try to impose a OS process wall as solution to having failed to properly design a modular architecture. So what could perfectly be a module with direct calls, ends up being a process talking over IPC mechanisms and much higher latency, with the added fun of distributed systems. Ironically pretty much OOP without any of the language support.
Blikkentrekker 4mo ago
It's really not clear whether Rust does it or not and it just sidesteps the issues by calling them “structs” and “enums” but fields can be private of course. Scheme Structs are rather interesting, when you define a struct the language by default also exports getter and setter functions with a predictable name though you can override the default name to give them any name, privacy is simply created by choosing to not export these getter and setter functions from the module. Privacy on the module level rather than on the class level is a far better pattern to be honest. As in other classes defined in the same module can still have access to them.

private data, convenience Which can be easily achieved without OOP.

pitched 4mo ago

That upfront convenience here leads to a long tail of job security when it inevitably goes spaghetti. Win-win!

gf000 4mo ago
Spaghetti ~ complexity ~ entropy. That's the natural order of things that many people work in, I doubt any "general loosely defined paradigm" can be absent from the inevitable.

pjmlp 4mo ago

In fact, to a certain point of view, OOP is a way to have modules bind to variables, and being extensible.

jqpabc123 4mo ago
And the price for this is constrained flexibility and utility. Data has value and utility on it's own --- as much as if not more than code that manipulates it. It is often not possible to foresee all the ways it can and will need to be used. So why bind anything to it? Relational databases were invented to provide flexibility with regard to data. OOP tries to encumber it --- often referred to as an "impedance mismatch".
- pjmlp 4mo ago
  Proper designed modules also don't expose more than the essentially necessary on their public interface. Failure to understand this is what leads many into microservice hell, as they try to impose a OS process wall as solution to having failed to properly design a modular architecture. So what could perfectly be a module with direct calls, ends up being a process talking over IPC mechanisms and much higher latency, with the added fun of distributed systems. Ironically pretty much OOP without any of the language support.

Blikkentrekker 4mo ago

It's really not clear whether Rust does it or not and it just sidesteps the issues by calling them “structs” and “enums” but fields can be private of course. Scheme Structs are rather interesting, when you define a struct the language by default also exports getter and setter functions with a predictable name though you can override the default name to give them any name, privacy is simply created by choosing to not export these getter and setter functions from the module. Privacy on the module level rather than on the class level is a far better pattern to be honest. As in other classes defined in the same module can still have access to them.