4 ms·

Interesting observations; although by definition glue code is amorphous and hard to pin down, I would like to see more concrete examples of the problem discusse

Interesting observations; although by definition glue code is amorphous and hard to pin down, I would like to see more concrete examples of the problem discussed here. Is this a general problem related to how we build interfaces for our implementations? Or is this more a problem with particular kinds of module systems? (Or both)

dgb23 5y ago
I think it’s interfaces and protocols at a granular level. If every interface is bespoke while also being explicitly described top down, then we end up with this quadratic complexity. Uniform, extensible interfaces and generic data structures are the solutions to this, as well as shifting complexity to data and away from code. Several modern languages, techniques and protocols address this in varying degrees and from different angles. An old language that does this very well is SQL.
- kaycebasques 5y ago
  > Several modern languages, techniques and protocols address this in varying degrees and from different angles. Examples? (Asking as a curious beginner who doesn't know where to start.)
  - dgb23 5y ago
    Go‘s implicit interfaces, Rust‘s traits, Clojure‘s sequences, transducers, multimethods and spec, Julia‘s multiple dispatch, HTTP REST, JSON and json-schema. These are all attempts to enable generic, simple code over complex data structures, while respecting and incorporating extensibility and change. It’s an old idea but I think more importance is given to it in more recent years.
ryanackley 5y ago
I get frustrated with the layers between relational data and data structures you pass around in code. So for example, if you want a build a simple REST api for your data model, you have glue code to read/write the data and transfer it to/from DAO's (Data access objects). Then you have glue code to transfer the data into to/from object model you expose via the API. This feels like 90% of server side CRUD app programming these days. It's not quite boilerplate because it's a mix of ORM optimizations for your data model and data massaging to make it more digestable to end users of your API.
sdenton4 5y ago
It's all about compartmentalized code... Glue happens whenever compartments interact with one another. Examples, thinking of an app I used to work on: a) App frontend (UI logic) is compartmentalized from the app backend. Communication is handled by an async messaging system, requiring bundling up messages in both directions. b) The app backend talks to a few different servers, each with their on expected message set. glue glue glue. c) The app backend talks to the app database, inserting/altering info, and extracting database rows into objects which can be passed around. d) (We also had peer-to-peer communication over local wifi, which required its own massive pile of communication code...) e) Even different objects/methods in the backend code end up requiring small amounts of glue code to arrange+prepare argument sets to call one another. So, every time we create a division between two pieces of code, we introduce boundaries, which introduces glue. --- One way to mitigate the complexity is by making the passed messages first class. In our app, there was some 'AppThing' object which represented an instance of the fundamental thing the app was about. You then stuff that object with every piece of info about AppThings you could ever want, and pass it around freely between components. Invariably it gets kinda bloated and fractures, when someone doesn't want to bother building up the WHOLE thing with the necessary DB and server calls to ensure the data is all accurately filled in, when you just want to pass one or two fields to a neighboring UI element. And then you find yourself with lots of logic checking that certain fields are present amongst the million fields in your universal object... Another approach is to aggressively prune the graph of possible component interactions. Functionality should be well-encapsulated, with absolutely minimal APIs for external interactions. Actually draw the 'cell membranes' between different parts of the app, map out the interactions between cells, and find ways to cut it back.

dgb23 5y ago

I think it’s interfaces and protocols at a granular level. If every interface is bespoke while also being explicitly described top down, then we end up with this quadratic complexity. Uniform, extensible interfaces and generic data structures are the solutions to this, as well as shifting complexity to data and away from code. Several modern languages, techniques and protocols address this in varying degrees and from different angles. An old language that does this very well is SQL.

kaycebasques 5y ago
> Several modern languages, techniques and protocols address this in varying degrees and from different angles. Examples? (Asking as a curious beginner who doesn't know where to start.)
- dgb23 5y ago
  Go‘s implicit interfaces, Rust‘s traits, Clojure‘s sequences, transducers, multimethods and spec, Julia‘s multiple dispatch, HTTP REST, JSON and json-schema. These are all attempts to enable generic, simple code over complex data structures, while respecting and incorporating extensibility and change. It’s an old idea but I think more importance is given to it in more recent years.

ryanackley 5y ago

I get frustrated with the layers between relational data and data structures you pass around in code. So for example, if you want a build a simple REST api for your data model, you have glue code to read/write the data and transfer it to/from DAO's (Data access objects). Then you have glue code to transfer the data into to/from object model you expose via the API. This feels like 90% of server side CRUD app programming these days. It's not quite boilerplate because it's a mix of ORM optimizations for your data model and data massaging to make it more digestable to end users of your API.

sdenton4 5y ago

It's all about compartmentalized code... Glue happens whenever compartments interact with one another. Examples, thinking of an app I used to work on: a) App frontend (UI logic) is compartmentalized from the app backend. Communication is handled by an async messaging system, requiring bundling up messages in both directions. b) The app backend talks to a few different servers, each with their on expected message set. glue glue glue. c) The app backend talks to the app database, inserting/altering info, and extracting database rows into objects which can be passed around. d) (We also had peer-to-peer communication over local wifi, which required its own massive pile of communication code...) e) Even different objects/methods in the backend code end up requiring small amounts of glue code to arrange+prepare argument sets to call one another. So, every time we create a division between two pieces of code, we introduce boundaries, which introduces glue. --- One way to mitigate the complexity is by making the passed messages first class. In our app, there was some 'AppThing' object which represented an instance of the fundamental thing the app was about. You then stuff that object with every piece of info about AppThings you could ever want, and pass it around freely between components. Invariably it gets kinda bloated and fractures, when someone doesn't want to bother building up the WHOLE thing with the necessary DB and server calls to ensure the data is all accurately filled in, when you just want to pass one or two fields to a neighboring UI element. And then you find yourself with lots of logic checking that certain fields are present amongst the million fields in your universal object... Another approach is to aggressively prune the graph of possible component interactions. Functionality should be well-encapsulated, with absolutely minimal APIs for external interactions. Actually draw the 'cell membranes' between different parts of the app, map out the interactions between cells, and find ways to cut it back.