6 ms·

> Jeff Ullman's claim that encapsulation and declarativity are in tension Can someone provide an elaboration on this, or link to this claim?

by sshine 8y ago

mjburgess 8y ago
SELECT name FROM users; Users.getName(); The above is "encapsulated" meaning that you need to have done the extra work to write "getName". Encapsulation is a bad solution to a worse problem (changing state). If you hide information you have to do extra work to get it out. This "extra work" is in tension with a declarative approach which uses general verbs across domains, requiring therefore, these domains expose their data.
- mlthoughts2018 8y ago
  Why wouldn’t encapsulation be linked more to normalization in a declarative setting? I’d argue that “implementation hiding” in a declarative setting is more about unfolding all data dependency, so that attributes are isolated from each other. Then the extra work to perform more joins to reproduce a cumulative data record seems very analogous to the extra work of getters and setters.
  - mjburgess 8y ago
    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;".
- fnord123 8y ago
  >This "extra work" is in tension with a declarative approach No it isn't. They work complementary to each other. If User is an interface then retrieving the name could be a call to a db, read from a file, read in memory, http GET request, it doesn't matter. The declarative component here does not care how the request is fulfilled as long as the interface is respected.
  - 0815test 8y ago
    The problem is that encapsulation makes it hard to specify reasonable constraints. For example, a "getter" might come with a constraint that "x = myobj.GetX(); myobj.SetX(x);" should not change the observable behavior of myobj. Or that "myobj2.ConstructFromXY(myobj.GetX(), myobj.GetY());" should result in a "myobj2" that's in some ways indistinguishable from "myobj". With a "declarative" approach, these constraints are implied in the system itself.
- cy6erlion 8y ago
  High level languages should be designed for humans to use, Encapsulation gives humans a levels of abstraction.
fnord123 8y ago
From the transcript: > I knew what I wanted my language to talk about, but I had no idea what it looked like, or how you could use it, or what its semantics were. I had six or seven years to screw around with this stuff, so I did. A lot of time passed. I spent my time on Google docs thinking about what the right state primitive should be. How can we talk about data changing? Whatever language I come up with there should be a way to efficiently evaluate it, that's pretty important if you're a systems person. I screwed around more with syntax. I got really upset about this thing that Jeff Ullman said in one of his books, in which he argued that encapsulation, this thing that you really want, you hide an implementation so that you can abstract above it, and declarativity, allowing a programmer to give a precise description of what should happen in a computation but not necessarily how to do it, appear to be very much at odds with each other. > So, declarativity tends to work really well for very small programs, but when we want to build big programs out of small programs, stuff gets fussy. I'm not going to talk much more about this in this talk, but, this is a problem. So anybody in the audience who is interested in declarative programming, I'd love to hear if you have any ideas about how we can do a better job of hiding encapsulation and reuse in query languages. And then, of course, the number one thing that occupied all my attention and kept me up at night, which was how do we, in a reasonable way, talk about uncertainty? How does a language talk about what it can't talk about? That's weird. I don't know which book this refers to or how Ullma supports his claim. And yet, Postgres foreign data wrappers exist providing encapsulation to the declarative SQL interface. shrug. Maybe Ullman is just wrong - or his comments were from a long time ago and the world has moved on since then.
- naasking 8y ago
  > And yet, Postgres foreign data wrappers exist providing encapsulation to the declarative SQL interface. I'm not sure what this means. Do you have a reference? It seems pretty clear that building an efficient query plan depends on having access to the internals of any entities referenced by the query. Encapsulation hides the internal of entities, so the claim seems pretty solid to me.
  - numbsafari 8y ago
    Interesting. Can this be addressed by ensuring the API of the encapsulated subsystem is sufficiently rich to provide what is needed by the declarative query planner? That is, the API allows the encapsulated subsystem to describe its contents in a way that supports query planning (e.g. shape of the contained data, supported operators, and general statistics), without having to reveal its exact implementation (columnar v row store, distributed v centralized storage, exact file format used, etc)? Perhaps the evolving shape of that API as the query planner becomes more capable (and therefore requires more knowledge) is what was meant by “are in tension”. Tension isn’t a bad thing. My favorite art is all about tension. Life is at its most immediate and palpable in the presence of tension.
skybrian 8y ago
It seems to be briefly discussed in "Principles of Database and Knowledge-base Systems" where it's pointed out that object-oriented databases are usually not declarative. https://www.sti-innsbruck.at/sites/default/files/Knowledge-Representation-Search-and-Rules/principles-of-database-and-knowledge-base-systems-volume-1-1.pdf https://www.sti-innsbruck.at/sites/default/files/Knowledge-R...

> Jeff Ullman's claim that encapsulation and declarativity are in tension Can someone provide an elaboration on this, or link to this claim?

by sshine 8y ago

> Jeff Ullman's claim that encapsulation and declarativity are in tension Can someone provide an elaboration on this, or link to this claim?

mjburgess 8y ago

SELECT name FROM users; Users.getName(); The above is "encapsulated" meaning that you need to have done the extra work to write "getName". Encapsulation is a bad solution to a worse problem (changing state). If you hide information you have to do extra work to get it out. This "extra work" is in tension with a declarative approach which uses general verbs across domains, requiring therefore, these domains expose their data.

mlthoughts2018 8y ago
Why wouldn’t encapsulation be linked more to normalization in a declarative setting? I’d argue that “implementation hiding” in a declarative setting is more about unfolding all data dependency, so that attributes are isolated from each other. Then the extra work to perform more joins to reproduce a cumulative data record seems very analogous to the extra work of getters and setters.
- mjburgess 8y ago
  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;".
fnord123 8y ago
>This "extra work" is in tension with a declarative approach No it isn't. They work complementary to each other. If User is an interface then retrieving the name could be a call to a db, read from a file, read in memory, http GET request, it doesn't matter. The declarative component here does not care how the request is fulfilled as long as the interface is respected.
- 0815test 8y ago
  The problem is that encapsulation makes it hard to specify reasonable constraints. For example, a "getter" might come with a constraint that "x = myobj.GetX(); myobj.SetX(x);" should not change the observable behavior of myobj. Or that "myobj2.ConstructFromXY(myobj.GetX(), myobj.GetY());" should result in a "myobj2" that's in some ways indistinguishable from "myobj". With a "declarative" approach, these constraints are implied in the system itself.
cy6erlion 8y ago
High level languages should be designed for humans to use, Encapsulation gives humans a levels of abstraction.

fnord123 8y ago

From the transcript: > I knew what I wanted my language to talk about, but I had no idea what it looked like, or how you could use it, or what its semantics were. I had six or seven years to screw around with this stuff, so I did. A lot of time passed. I spent my time on Google docs thinking about what the right state primitive should be. How can we talk about data changing? Whatever language I come up with there should be a way to efficiently evaluate it, that's pretty important if you're a systems person. I screwed around more with syntax. I got really upset about this thing that Jeff Ullman said in one of his books, in which he argued that encapsulation, this thing that you really want, you hide an implementation so that you can abstract above it, and declarativity, allowing a programmer to give a precise description of what should happen in a computation but not necessarily how to do it, appear to be very much at odds with each other. > So, declarativity tends to work really well for very small programs, but when we want to build big programs out of small programs, stuff gets fussy. I'm not going to talk much more about this in this talk, but, this is a problem. So anybody in the audience who is interested in declarative programming, I'd love to hear if you have any ideas about how we can do a better job of hiding encapsulation and reuse in query languages. And then, of course, the number one thing that occupied all my attention and kept me up at night, which was how do we, in a reasonable way, talk about uncertainty? How does a language talk about what it can't talk about? That's weird. I don't know which book this refers to or how Ullma supports his claim. And yet, Postgres foreign data wrappers exist providing encapsulation to the declarative SQL interface. shrug. Maybe Ullman is just wrong - or his comments were from a long time ago and the world has moved on since then.

naasking 8y ago
> And yet, Postgres foreign data wrappers exist providing encapsulation to the declarative SQL interface. I'm not sure what this means. Do you have a reference? It seems pretty clear that building an efficient query plan depends on having access to the internals of any entities referenced by the query. Encapsulation hides the internal of entities, so the claim seems pretty solid to me.
- numbsafari 8y ago
  Interesting. Can this be addressed by ensuring the API of the encapsulated subsystem is sufficiently rich to provide what is needed by the declarative query planner? That is, the API allows the encapsulated subsystem to describe its contents in a way that supports query planning (e.g. shape of the contained data, supported operators, and general statistics), without having to reveal its exact implementation (columnar v row store, distributed v centralized storage, exact file format used, etc)? Perhaps the evolving shape of that API as the query planner becomes more capable (and therefore requires more knowledge) is what was meant by “are in tension”. Tension isn’t a bad thing. My favorite art is all about tension. Life is at its most immediate and palpable in the presence of tension.

skybrian 8y ago

It seems to be briefly discussed in "Principles of Database and Knowledge-base Systems" where it's pointed out that object-oriented databases are usually not declarative. https://www.sti-innsbruck.at/sites/default/files/Knowledge-Representation-Search-and-Rules/principles-of-database-and-knowledge-base-systems-volume-1-1.pdf https://www.sti-innsbruck.at/sites/default/files/Knowledge-R...