https://futureofcoding.org/ logo
Join Slack
Powered by
There is a thread on HN: "<How should we build the...
# linking-together
a
There is a thread on HN: "How should we build the APIs of tomorrow?" I left a comment with a few ideas: 1. Emphasize synchronization over imperative API calls. Imperative APIs encourage data silos. They are the underlying technical part of the problem that Zapier and ITTT try to solve. See [0] and [1] for some ideas. 2. Allow users to submit "agents" rather than "requests." An agent is a small program given extremely limited resources (limited process/memory/runtime budget) that you can safely run on your server. It is a possible answer to many of the standards/protocols that wouldn't exist if frontends were running on the same machines as backends. [2] 3. Emphasize composition over integration. Functions compose (nest, recurse). Event emitters don't. As long as APIs are built to be integrated rather than composed, making them work together is a full-time or full-company job (eg. Zapier). 4. Make things immutable. Immutability allows APIs to "play" with one another without fear of setting off the nukes (ie. side effects). It's possible that this approach would make it so that integrating two APIs becomes a job for ML/AI rather than humans. This is from my limited understanding of some of the ideas in FOC. What did I miss/misinterpret? [0] https://github.com/braid-work/braid-spec [1] https://writings.quilt.org/2014/05/12/distributed-systems-an... [2] https://news.ycombinator.com/item?id=23900749
c
The most used languages don't support the real world, and especially not "functional" languages (without a lot of piping). I believe that event emitters can potentially be composable, it just depends how you set them up. There are a lot of ideas in the data-oriented paradigm (often used in game dev) which have been by far the most composable approach to integrations, I've ever experienced.
I'm glossing over some assumptions being made about what an "event emitter" is, exactly, but in our case it's essentially something modifies a row in a shared DB, and something else was directly listening to that row to change. For example "when my postmates order arrives"
The key to this approach is that everything is talking together in the same "DB", and we're enforcing visibility. There was an interesting programming language just announced that goes in this direction: https://www.reddit.com/r/ProgrammingLanguages/comments/ik0w0q/tablam_a_experimental_relational_language/
g
I think at least one version of Eve also had a similar story going on
also—can’t you model event emitters with observers? which can be modeled with functional reactive programming? which can be implemented with pure functions? so you can compose in the same way?
I guess I’m a bit fuzzy on the details of what separates/defines “integration” vs “composition”
c
@Garth Goldwater, yeah. Good point. I wonder if @Aria Minaei meant something more specific. integration vs composition: I'm not entirely sure. It makes me feel like composition is like swallowing the other service like a library, while integrations are the icons on your landing page.
a
integration vs composition: I'm not entirely sure. It makes me feel like composition is like swallowing the other service like a library, while integrations are the icons on your landing page.
That's how I picture it too. An example of "integration-style" programming that I deal with often, is the Node.js-style EventEmitter, where there isn't much of a principle in event ordering, concurrency, propogation, scheduling, etc, and the topology of dataflow is more emergent rather than explicitly designed and very hard to debug. It is still possible to compose things that use EventEmitters, but it's just not ergonomic. The composable counterpart to EventEmitter would be an FRP-style Observables like those in Rx.js. Observables there are just generalizations over functions and get the benefit of functions, such as recursion and explicit scope.
👍 1
Another example of composition over integration (again from the JS world, sorry 🙂) is React vs, say, jQuery. In jQuery, there is a global namespace that is the DOM tree representing the HTML document, and interactivity is peppered on top of individual html elements, like: 
$('ul').reorderable()
(this is supposed to turn all 
<ul>
lists into lists that the user can re-order by drag/dropping their items). But as soon as you need to nest two re-orderable lists, the code becomes quite awkward, especially if one list can create more lists inside itself. It is not impossible, just hacky. Compare that with React, where a 
<ReorderableList>
is just a component, which are themselves a generalization over functions. Suddenly it becomes easy to write and use nested lists like so: 
<ReorderableList>...<div><ReorderableList>...
.
👍 1
In integration, things have IDs that have to be book-kept. In composition, things are addressable through their position in the topology (parent can reference a child without having to assign a global ID to that child).
👍 2
(though topology doesn't need to be hierarchical in a composition).
c
@Aria Minaei, are you familiar with using data-oriented programming? Esp that used in game development with entity-component-systems?
a
In a composition, the lifecycle of things is again managed by the topology. If a thing is no longer needed, it is removed, similar to how values on a function call stack get freed after the function is done running. In react, 
componentWillUnmount()
gets called. In refcounting, some sort of 
object.free()
gets called.
are you familiar with using data-oriented programming? Esp that used in game development with entity-component-systems?
@Cole Haven't used ECS in anything bigger than a toy, so not very familiar.
c
You might find this sort of intro to ECS interesting. It's not super Rust heavy, so the concepts are the focus

https://www.youtube.com/watch?v=aKLntZcp27M▾

Essentially, data oriented tech is all about the state of the world is accessible by all systems, and each system will look at the data in the world to make a decision to make an update or not based on what they see. Kinda like the blackboard design pattern. But, in this way each system can be written in a pure functional way with effects coming into the top of the funnel
a
You might find this sort of intro to ECS interesting.
@Cole Thank you! I was actually building another ECS toy yesterday and looking for a good intro.
👏 1
Open in Slack
PreviousNext
Powered by