3 ms·

joining is connected to normalization, not to declarative style declarative style is (essentially) the highly polymorphic use of verbs in programming. You migh

joining is connected to normalization, not to declarative style declarative style is (essentially) the highly polymorphic use of verbs in programming. You might even call it "polymorphic programming" rather than declarative, since that's often what is being prioritized. this level of polymorphism requires the data-operated-on by the verb to be relatively exposed ie., "select" cannot be different for every table OO essentially has "select" redefined every time you want to expose data.

mlthoughts2018 8y ago
> “OO essentially has "select" redefined every time you want to expose data.” I still don’t see how this is different in concept, since you “redefine” selection every time for normalized attributes as well (you must individually hand-specify where to select from). I get what you’re saying about polymorphism, such that things like select or join “just work” on everything. Many OO / functional programming languages have that too, for example with __getitem__ or __getattr__ protocols in Python, so that the same “verb” (e.g foo.x = 3) “just works” automatically without concern of specialized implementations. But in the declarative case you’re just trading off the conplexity of creating and registering specific getter logic per each type against flattening out all the attributes such that all the complexity is embedded into knowing the correct name to ask for the universal verbs (e.g. select) to apply to.
- mjburgess 8y ago
  > against flattening out all the attributes Hence the tension with encapsulation
  - mlthoughts2018 8y ago
    I don’t understand what you mean by “tension.” In an OO setting, you register specialized implementations with some type of interface / protocol / dispatcher. In functional programming you create functions that allow a data type’s specialized implementation to be type matched against a typeclass. In declarative programming you flatten out attributes so that a pre-existing set of polymorphic operators apply, and you translate the complexity of lookups (that match the implementation) into the complexity of specifying everything in a splayed-out form. It’s all the same complexity, just different trade-offs for how it’s represented. I wouldn’t describe this as “tension” because that makes it sound as though declarative programming has some fundamental limitation or missing capability regarding encapsulation, but it doesn’t. It’s just making a different trade-off of the same thing.
    - mjburgess 8y ago
      I guess there's two senses of "encapsulation" in use here. What I think is meant by the article is information-protection rather than information-hiding, or implementation hiding. Encapsulation in the sense of "private string name;".

mlthoughts2018 8y ago

> “OO essentially has "select" redefined every time you want to expose data.” I still don’t see how this is different in concept, since you “redefine” selection every time for normalized attributes as well (you must individually hand-specify where to select from). I get what you’re saying about polymorphism, such that things like select or join “just work” on everything. Many OO / functional programming languages have that too, for example with __getitem__ or __getattr__ protocols in Python, so that the same “verb” (e.g foo.x = 3) “just works” automatically without concern of specialized implementations. But in the declarative case you’re just trading off the conplexity of creating and registering specific getter logic per each type against flattening out all the attributes such that all the complexity is embedded into knowing the correct name to ask for the universal verbs (e.g. select) to apply to.

mjburgess 8y ago
> against flattening out all the attributes Hence the tension with encapsulation
- mlthoughts2018 8y ago
  I don’t understand what you mean by “tension.” In an OO setting, you register specialized implementations with some type of interface / protocol / dispatcher. In functional programming you create functions that allow a data type’s specialized implementation to be type matched against a typeclass. In declarative programming you flatten out attributes so that a pre-existing set of polymorphic operators apply, and you translate the complexity of lookups (that match the implementation) into the complexity of specifying everything in a splayed-out form. It’s all the same complexity, just different trade-offs for how it’s represented. I wouldn’t describe this as “tension” because that makes it sound as though declarative programming has some fundamental limitation or missing capability regarding encapsulation, but it doesn’t. It’s just making a different trade-off of the same thing.
  - mjburgess 8y ago
    I guess there's two senses of "encapsulation" in use here. What I think is meant by the article is information-protection rather than information-hiding, or implementation hiding. Encapsulation in the sense of "private string name;".