Great idea, though maybe you meant "standards" not "models"?
https://xkcd.com/927/
Composition shouldn't be this hard
41–50 of 78 posts
Re: Composition shouldn't be this hard
#42Centralization is the #1 solution. It works. It's "ugly", but it works. You see even on this thread people begging for one single standard. What actually happens with that one single standard? - Behind it, you have a shittload of people implicitly optimizing for the general use case and hiding all the said complexity for you - No need to worry about [semantic conflict]( https://www.sigbus.info/worse-is-better ) Once…
I'm not disagreeing but I was reminded of a counterexample: https://www.theregister.com/2026/01/29/birmingham_oracle_lat...
> Although the council had planned to implement Oracle "out-of-the-box," it created several customizations including a banking reconciliation system that failed to function properly. The council struggled to understand its cash position and was unable to produce auditable accounts. It has spent more than £5 million on manual workaround labor.
Not a great example of a single centralised system. The errors came from trying to write custom reconciliation code between two systems, the ERP and the bank - perfect example of the problems OP raises.
Re: Composition shouldn't be this hard
#43> What code is truly about is precision: code is unambiguous, even when it’s abstract. It’s easy to conflate ambiguity and abstraction—both refer to “a single statement that could have to multiple meanings.” But the meanings of an ambiguous statement are entirely unconstrained. I used to believe this, but after working at a successful SaaS I have come to believe that correctness and unambiguity are not entirely neces…
Right. One thing I learned over the years is that you can support arbitrarily high level of tech debt and still be able to effectively maintain and enrich a successful software system, as long as you throw enough warm bodies at it.
The overhead will get absurd, you'll end up with 10x or more increase in engineers working on the system, all of them making slow progress while spending 90% time debugging, researching, or writing docs and holding meetings to work out this week's shared understanding of underlying domain semantics - but progress they will make, system will be kept running, and new features will be added.
If the system is valuable enough for the company, the economic math actually adds up. I've seen at least one such case personally - a system that survived decades and multiple attempts at redoing it from scratch, and keeps going strong, fueled by massive amount of people-hours spent on meetings.
Adding AI to the mix today mostly just shifts individual time balance towards more meetings (Amdahl's Law meets Parkinson's law). But ironically, the existence of such systems, and the points made in the article, actually reinforce the point of AI being key to, if not improving it, then at least keeping this going: it'll help shorten the time to re-establish consensus on current global semantics, and update code at scale to stay consistent.
Re: Composition shouldn't be this hard
#44This is light on specifics, but is still directionally the closest anyone has come to describing my ideal future data platform. The founder Dan Sotolongo's work at Snowflake included Dynamic Tables which makes me think the proposal is basically this: a hybrid transactional/analytical database, with declarative domain-oriented schemas, with smart incrementally calculated updates, and a la carte performance characteris…
Sotolongo's lineage is Twitter observability -> Google streaming -> Snowflake Dynamic Tables, which is a declarative, relational, query-optimizer-centric tradition. Marz's lineage is Storm -> Trident -> Rama, which is a procedural-dataflow, programmer-controls-the-plan, event-sourcing-centric tradition. Both are trying to unify OLTP + OLAP + application logic + reactivity into a coherent substrate, but they're coming at it from opposite epistemological poles. Rama says "give the programmer fine-grained control over partitioning, indexing, and dataflow, and trust them to design the right physical representation for their queries." Cambra, if your inference about Dynamic Tables is right, will almost certainly say "let the programmer describe the domain model declaratively and let the system figure out the physical representation." This is the classic Codd-vs-Codasyl split, recapitulated forty years later with much more sophisticated machinery on both sides.
If this is the right framing, then the two systems aren't really competitors despite solving the same problem--they're going to appeal to fundamentally different developer sensibilities. Rama is for people who want to think like Jay Kreps or Martin Kleppmann: the event log is sacred, physical data layout is a first-class design decision, and the programmer earns the performance benefits by understanding the system deeply. Cambra (if these assumptions hold) will be for people who want to think like database users: describe what you want, let the optimizer figure out how, intervene only when necessary. These are both defensible positions and both have historical track records of working. SQL's history shows the declarative camp has ecosystem advantages once the optimizer is good enough; Kafka/Rama's history shows the log-centric camp has correctness and observability advantages for event-heavy domains.
Re: Composition shouldn't be this hard
#45> What code is truly about is precision: code is unambiguous, even when it’s abstract. It’s easy to conflate ambiguity and abstraction—both refer to “a single statement that could have to multiple meanings.” But the meanings of an ambiguous statement are entirely unconstrained. I used to believe this, but after working at a successful SaaS I have come to believe that correctness and unambiguity are not entirely neces…
This is the realization that pretty much all engineers go through as they become more senior. The areas where the business really can’t afford issues is very small. Usually only accounting / billing and then that’s solved not by great code / design but just audit it once and never touch it again.
In the end most challenges for a business holding them back to better code quality are organizational, not technical.
Re: Composition shouldn't be this hard
#46I've also felt that composition is unnecessarily hard in web & data infrastructure. I do game development as a hobby, and web + data technology is in the stone age compared to game engines when it comes to composability. For example, say I develop some object (scene) in Godot Engine. It interacts with the environment using physics simulation, renders 3D graphics to the screen with some shaders and textures, and plays…
I've heard of people using Godot for non-game applications and I'm tempted to try something similar in the (near?) future because supposedly Low Processor Usage Mode makes it kinda feasible/sensible if you develop with that in mind from the start.
And while web pages can masquerade as desktop and mobile apps why wouldn't games be allowed to do the same? Godot for example can do desktop multi-window while something like Flutter (which is amazing in its own right) can't do.
But yeah, someone needs to spend time and build out UI toolkits for Godot and sadly that's not really a long weekend undertaking.
Still! It's nice to dream from time to time and imagine a reality where we can either do some generic cookie cutter UI because it's meant to get things done without much ceremony or we can pull out all the stops and plop a 3D scene to walk around the file system and shot files to delete them. And yeah, I'm aware someone did a thing like that in VS Code with Three.js (I think?)[0] and for Flutter you can do something similar in a webview inside the app proper.
Yet somehow I would rather do those things inside Godot for reasons unknown to me.
[0] Found it: https://marketplace.visualstudio.com/items?itemName=brian-nj...
Re: Composition shouldn't be this hard
#47This resonates a lot if you’ve ever worked in system integration. In practice, most of the complexity comes exactly from what’s described here: every system has a rich internal model, but the moment data crosses a boundary, everything degrades into strings, schemas, and implicit contracts. You end up rebuilding semantics over and over again (validation, mapping, enrichment), and a lot of failures only show up at runt…
> You end up rebuilding semantics over and over again (validation, mapping, enrichment), and a lot of failures only show up at runtime. I think die-hard fans of static typing mostly fail to acknowledge this objective reality and its implications. Every time they encounter this problem again and again, they approach it as if nobody thought of this before, and didn’t develop reliable abstractions to productively work i…
I'm genuinely interested in examples of these reliable abstractions, or at least in some keywords I can look up.
Re: Composition shouldn't be this hard
#48> What code is truly about is precision: code is unambiguous, even when it’s abstract. It’s easy to conflate ambiguity and abstraction—both refer to “a single statement that could have to multiple meanings.” But the meanings of an ambiguous statement are entirely unconstrained. I used to believe this, but after working at a successful SaaS I have come to believe that correctness and unambiguity are not entirely neces…
Right. One thing I learned over the years is that you can support arbitrarily high level of tech debt and still be able to effectively maintain and enrich a successful software system, as long as you throw enough warm bodies at it . The overhead will get absurd, you'll end up with 10x or more increase in engineers working on the system, all of them making slow progress while spending 90% time debugging, researching,…
> Amdahl's Law meets Parkinson's Law
[Infinite screaming]
Re: Composition shouldn't be this hard
#49Not sure if tools and technologies can solve accidental complexity. In my opinion, a system that has been stable for years isn't 'mature' in a good sense. An exceptional system is one that can still change after many years in production. I believe this is almost impossible to achieve for enterprise software, because nobody has incentive to make the (huge) investment into longterm maintainability and changeability. Fo…
You can't say...
> Not sure if tools and technologies can solve accidental complexity.
... and then say
> For me, consistent systematic naming and prefixes/suffixes to make names unique are a hint that a person is thinking about this or has experience with maintaining old systems. This has a huge effect on how well you can search, analyze, find usages, understand, replace, change.
I have battle scars from refactoring legacy systems where my predecessors did _not_ consistently or uniquely name things and I would not have seen it through without my sidekick, the type checker!
Re: Composition shouldn't be this hard
#50> What code is truly about is precision: code is unambiguous, even when it’s abstract. It’s easy to conflate ambiguity and abstraction—both refer to “a single statement that could have to multiple meanings.” But the meanings of an ambiguous statement are entirely unconstrained. I used to believe this, but after working at a successful SaaS I have come to believe that correctness and unambiguity are not entirely neces…
This is the realization that pretty much all engineers go through as they become more senior. The areas where the business really can’t afford issues is very small. Usually only accounting / billing and then that’s solved not by great code / design but just audit it once and never touch it again. In the end most challenges for a business holding them back to better code quality are organizational, not technical.
> In the end most challenges for a business holding them back to better code quality are organizational, not technical.
This is true. And I get sad every time it is used as an argument not to improve tooling. It feels like sort of a self-fulfilling prophecy: an organizational problem that prevents us from investing into technical improvements... is indeed an organizational problem.