5 ms·

Three Things I Wish I Knew When I Started Designing Languages

158 points by matt_d 8y ago

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
  - 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...
asplake 8y ago
“He summarises by saying the only good reason to design a programming language (I assume he means a radically novel language) is to shape your understanding of the problem. No regrets of being the only user of his first language, Datalist, because the point is that it shaped all his later thought in his research.” I don’t design languages but I speak and write (iterating between different forms) for much the same reason. Thoughts made concrete in some way are much easier to manipulate. Programming can be much the same.
- eequah9L 8y ago
  For every new project idea, I open a file and start writing everything that comes to mind. A design document if you will. Writing stuff down like this makes things obvious and tangible, easy to juxtapose, as you say, easy to manipulate. I can't count how often that document is the last thing that I do on a project, because I just can't make it work even on the paper, where ideas are cheap to sketch out.
- Klathmon 8y ago
  This is also why I'll often not ask important questions in meetings and will instead ask them in a chat message or email. Not only does the act of writing it out make me ask a better question (and there are times I answer the question myself before sending it!), but the answers are often much better when written down. (Not to mention the additional benefits like easier searchability)
  - lugg 8y ago
    Discussion is cheap. If it is on topic, saying something stupid quickly and then rolling back the conversation is a far more efficient use of your time. You do need to pick your audience. Some people really struggle with this style of conversation. The rapid depreciation/substitution of facts can be a tad tiring. But for those that can take it, this is essentially the same as writing things down but it's faster and has the added benefit of at least one other person "checking your math" as you go.
    - 8y ago
jfengel 8y ago
The semantics of negation is like security: there's an urge to ignore it at the beginning because it's not the use case you have in mind, but it turns out that it's absolutely fundamental to everything. You have to build it in from the beginning; you can't layer it on afterwards. Different negation semantics put you in different computability classes. And there's a tension: you want more powerful semantics, but they take longer to run. Full first-order logic is great, but it's also exponential time to evaluate. (Also, the semantics of negation for FOL are easy to explain but not actually very similar to what you expect negation to mean in real life, leading to unexpected semantics.)
dang 8y ago
Url changed from http://lambda-the-ultimate.org/node/5569 http://lambda-the-ultimate.org/node/5569, which points to this.
- chalst 8y ago
  The virtue of the LtU link is that it gave a brief outline of the talk.
deleted 8y ago
[deleted]

158 points by matt_d 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
- 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...

asplake 8y ago

“He summarises by saying the only good reason to design a programming language (I assume he means a radically novel language) is to shape your understanding of the problem. No regrets of being the only user of his first language, Datalist, because the point is that it shaped all his later thought in his research.” I don’t design languages but I speak and write (iterating between different forms) for much the same reason. Thoughts made concrete in some way are much easier to manipulate. Programming can be much the same.

eequah9L 8y ago
For every new project idea, I open a file and start writing everything that comes to mind. A design document if you will. Writing stuff down like this makes things obvious and tangible, easy to juxtapose, as you say, easy to manipulate. I can't count how often that document is the last thing that I do on a project, because I just can't make it work even on the paper, where ideas are cheap to sketch out.
Klathmon 8y ago
This is also why I'll often not ask important questions in meetings and will instead ask them in a chat message or email. Not only does the act of writing it out make me ask a better question (and there are times I answer the question myself before sending it!), but the answers are often much better when written down. (Not to mention the additional benefits like easier searchability)
- lugg 8y ago
  Discussion is cheap. If it is on topic, saying something stupid quickly and then rolling back the conversation is a far more efficient use of your time. You do need to pick your audience. Some people really struggle with this style of conversation. The rapid depreciation/substitution of facts can be a tad tiring. But for those that can take it, this is essentially the same as writing things down but it's faster and has the added benefit of at least one other person "checking your math" as you go.
  - 8y ago

jfengel 8y ago

The semantics of negation is like security: there's an urge to ignore it at the beginning because it's not the use case you have in mind, but it turns out that it's absolutely fundamental to everything. You have to build it in from the beginning; you can't layer it on afterwards. Different negation semantics put you in different computability classes. And there's a tension: you want more powerful semantics, but they take longer to run. Full first-order logic is great, but it's also exponential time to evaluate. (Also, the semantics of negation for FOL are easy to explain but not actually very similar to what you expect negation to mean in real life, leading to unexpected semantics.)

dang 8y ago

Url changed from http://lambda-the-ultimate.org/node/5569 http://lambda-the-ultimate.org/node/5569, which points to this.

chalst 8y ago
The virtue of the LtU link is that it gave a brief outline of the talk.

deleted 8y ago

[deleted]