3 ms·

From my experience, the modern Java-style OOP that I've worked with (some of which I produced myself) through all these years leads to terrible code, and all th

by dpc_pw 6y ago

From my experience, the modern Java-style OOP that I've worked with (some of which I produced myself) through all these years leads to terrible code, and all the data-oriented code I've seen and produced seems much, much better in comparison. Other programming styles are often orthogonal. One can have mostly functional OOP and mostly functional data-oriented software, or imperative OOP vs imperative data-oriented software and so on. I'm mostly focused on OOP vs data-orientation. OOP means a fixation on modeling everything as "a graph of encapsulated objects with associated bits of logic calling each other" while data-orientation means: "pure logic decoupled from data, and a data stored and passed in mostly non-abstract, concrete ways to support required computation". The success of OOP is dubious: mostly judged by it's popularity, which is mostly driven by it being a default methodology tough to people in school. When you look at the actual industry, most of the fundamental, long-lasting software is actually written in some form of data-orientation. From kernels, system tools, things like redis, other databases, etc. Though one could tell that it's because fundamental software is usually system software, and not business-logic software and that's true. I don't have evidence, and it's all just my experience, reasoning and intuition, and I'm intellectually open for debate here, but IMO fundamentally splitting data into small encapsulated chunk that form a graph of native references to each other is just a terrible way to organize any form of computation. I don't want to repeat myself, so please see my reddit post that I linked before for more details.

alquemist 6y ago
The seductive power of OOP has little to do with the technical merits. As you mention data oriented programming leads to better programs. Even when using OOP technology, programs usually tend to become data oriented (hello protos), and 'objects' become glorified pure functions. The big OOP idea is the subject-verb-object interface, confusingly named object-method-arguments. The SVO structure matches the cognitive linguistic bias of the human brain, thus feels obviously right to most humans. Even if better programming alternatives exist. The endless litany of new Verber(args0).verb(args1) is here to stay.
- dpc_pw 6y ago
  Oh. I find subject-verb-object interface another dimension of debate altogether. Usual it's being mentioned by FP devs, since they are usually very aware of that aspect since they don't get to use it. :D It's not only that SVO is more suited from linguistic reasons. Selecting the "object/doer/subject" first is just a better UX in all sorts of human-interfaces (e.g. games). It allows narrowing down the context naturally, improving discoverability (like auto-completion). Big part of the reason why I switched from Vim to Kakoune. Subject serves the purpose of being a mini namespace/module and context for operations. In a way, I blame FP community for being so stubborn in their mathematically-inclined notation, and not experimenting enough with trying to achieve similar human-friendly notation. But maybe I'm just missing all the historical attempts or something. One of the most interesting spins on the topic is "subject-oriented programming" from Hoon (which is native PL for Urbit OS), where every expression is always evaluated in ever-present implicit subject context, and results in a new subject which will be used for the next expression.
  - alquemist 6y ago
    Speculation. The FP community prizes mathematical beauty, for which symmetry is an important factor. It is simply ugly to promote one function argument (which one?) to a privileged role, even if the linguistic side of the brain screams that's the right thing to do. Re autocomplete, there is no technical reason why auto-complete couldn't trim down the search space based on the arguments of the functions, for example by using reverse polish. But reverse polish is unusual, we really like SVO anyways, and modules as subjects are very useful, if only as an autocomplete anchor, in tooling or in one's brain. OOP/SVO is here to stay for the foreseeable future, and embracing pure functions principle makes it rather pleasant to work with. If only we could decouple 'modules as namespaces' useful idea from all the misguided baggage that comes bundled with OOP, of which the 'active data' antipattern deserves special 'please avoid' mention.
tabtab 6y ago
RE: "The success of OOP is dubious: mostly judged by it's popularity, which is mostly driven by it being a default methodology taught to people in school." It's worked fairly well for "isolated" groups of services, such as API's to file systems, network services, etc. Where it fails is domain modelling and any system or sub-system having more than a few entities. OOP doesn't scale when there is a large number of domain nouns and/or attributes involved. For example, OOP worked quite well for early and fairly simple GUI's. But when GUI systems and applications grew larger and more complicated, OOP GUI's turned into spaghetti. I believe something more like an RDBMS is necessary to manage large quantities of nouns and attributes so that one can slice and dice their particular view and grouping as needed for different tasks: query the parts instead of navigate a parts graph. You can navigate graphs like a cave explorer, but you can't easily say "show me all nodes (caves) with such and such...". Perhaps this is the "data orientation" you speak of. (I'm puzzled why in Java Swing the event handling code for a button click has to be fed into a "listener" instead of attached to the button object itself. The second is more logical in terms of thinking in the domain of UI's. Listener is an implementation detail that should be hidden away most of the time.) On a really small scale, trees and nesting work fine. On a medium scale graphs work fine. But on the larger scale, relational or something similar is a better tool. The hard part has been getting RDBMS to manage "blocks of behavior" well (events, snippets, functions, etc.).

by dpc_pw 6y ago

alquemist 6y ago

The seductive power of OOP has little to do with the technical merits. As you mention data oriented programming leads to better programs. Even when using OOP technology, programs usually tend to become data oriented (hello protos), and 'objects' become glorified pure functions. The big OOP idea is the subject-verb-object interface, confusingly named object-method-arguments. The SVO structure matches the cognitive linguistic bias of the human brain, thus feels obviously right to most humans. Even if better programming alternatives exist. The endless litany of new Verber(args0).verb(args1) is here to stay.

dpc_pw 6y ago
Oh. I find subject-verb-object interface another dimension of debate altogether. Usual it's being mentioned by FP devs, since they are usually very aware of that aspect since they don't get to use it. :D It's not only that SVO is more suited from linguistic reasons. Selecting the "object/doer/subject" first is just a better UX in all sorts of human-interfaces (e.g. games). It allows narrowing down the context naturally, improving discoverability (like auto-completion). Big part of the reason why I switched from Vim to Kakoune. Subject serves the purpose of being a mini namespace/module and context for operations. In a way, I blame FP community for being so stubborn in their mathematically-inclined notation, and not experimenting enough with trying to achieve similar human-friendly notation. But maybe I'm just missing all the historical attempts or something. One of the most interesting spins on the topic is "subject-oriented programming" from Hoon (which is native PL for Urbit OS), where every expression is always evaluated in ever-present implicit subject context, and results in a new subject which will be used for the next expression.
- alquemist 6y ago
  Speculation. The FP community prizes mathematical beauty, for which symmetry is an important factor. It is simply ugly to promote one function argument (which one?) to a privileged role, even if the linguistic side of the brain screams that's the right thing to do. Re autocomplete, there is no technical reason why auto-complete couldn't trim down the search space based on the arguments of the functions, for example by using reverse polish. But reverse polish is unusual, we really like SVO anyways, and modules as subjects are very useful, if only as an autocomplete anchor, in tooling or in one's brain. OOP/SVO is here to stay for the foreseeable future, and embracing pure functions principle makes it rather pleasant to work with. If only we could decouple 'modules as namespaces' useful idea from all the misguided baggage that comes bundled with OOP, of which the 'active data' antipattern deserves special 'please avoid' mention.

tabtab 6y ago

RE: "The success of OOP is dubious: mostly judged by it's popularity, which is mostly driven by it being a default methodology taught to people in school." It's worked fairly well for "isolated" groups of services, such as API's to file systems, network services, etc. Where it fails is domain modelling and any system or sub-system having more than a few entities. OOP doesn't scale when there is a large number of domain nouns and/or attributes involved. For example, OOP worked quite well for early and fairly simple GUI's. But when GUI systems and applications grew larger and more complicated, OOP GUI's turned into spaghetti. I believe something more like an RDBMS is necessary to manage large quantities of nouns and attributes so that one can slice and dice their particular view and grouping as needed for different tasks: query the parts instead of navigate a parts graph. You can navigate graphs like a cave explorer, but you can't easily say "show me all nodes (caves) with such and such...". Perhaps this is the "data orientation" you speak of. (I'm puzzled why in Java Swing the event handling code for a button click has to be fed into a "listener" instead of attached to the button object itself. The second is more logical in terms of thinking in the domain of UI's. Listener is an implementation detail that should be hidden away most of the time.) On a really small scale, trees and nesting work fine. On a medium scale graphs work fine. But on the larger scale, relational or something similar is a better tool. The hard part has been getting RDBMS to manage "blocks of behavior" well (events, snippets, functions, etc.).