… or “In advocacy of the total submission pattern”
HTML is a great and durable protocol, but something hard to generalize in the world of Turing complete programming languages. So often you have the power to just tell the computer everything that you want it to do; however this also means you have been given the responsibility to tell the computer everything that it should do. This is usually not what anyone wants.
If I were to label HTML with a term to describe why it is such a cool technology, I would want to highlight how little it actually does. There are less than 60 tags in HTML5 and most of them are deprecated. It is amazing to think of how much one can do just by mixing a few of these primitives together.
Another one of my favorite technologies is SQL. This database query language, more-or-less elegantly, captures much of the power of the π-calculus. It does so in plain enough language that many non-programmers routinely use this powerful tool to create dynamic spreadsheets or drudge through reams of data to find valuable insights.
What both of these technologies share, and what I believe makes them so powerful, is their total submission to a “driver” object. For HTML there is the browser. For SQL there is the engine. The driver object becomes infinitely complicated, but the interface grounds the driver into a zone of fertility where mere mortals can interact with these dynamic objects of providence.
What prompted me to look back on this pattern now is something I have been struggling with recently, that I think is going to become huge over time: something called, ominously, the borrow checker. This is a concept implemented in the Rust programming language, and originating from linear type theory. It has frustrated me time and again, and probably similarly to others throughout the larger community. It is a thorn in the side of the von Neumann architecture and directly inhibits many of the solid patterns of code that constitute what is generally thought to be good code.
To describe it simply, the borrow checker is a book library that only lends to visitors that can prove that they will return the book before coming due.
Just try to checkout a book. It will make your head hurt.
Now back to the topic of the “god object”. In this case it is easy to see how the Strict Library can be a good fit for this pattern. Edge code can often be broken down into pure functions or data structures. These small pieces can be connected to create even more refined yet flat semantics. I think we will be seeing more of this within the Rust community. This whole idea is still quite young in practice, and has yet to reach scale. However, as use of this toolset begins to grow, I am betting that we will see more small libraries and more pure semantics: submission then becomes one way to defer the borrow entirely.
This post was originally published on medium.com
Top comments (1)
The 'god object' reference in the title might be a bit misleading.
God objects are more like an OOP anti-pattern. It's usually some (static) class that knows about too many things and it is referred to by many classes. So the codebase is tightly knit to the god object. God objects make it harder to reuse code, and if it keeps it's own state it also makes the code harder to reason about.
HTML and SQL are languages. At best it helps expressing various query needs or document structures in a more concise manner. Dealing with other languages should not lead to the anti-pattern described above, but that's up to the developer.