Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Composition shouldn't be this hard

cambra.dev

Post reply on HN
Print view View original

31–40 of 78 posts

Re: Composition shouldn't be this hard

#31

Post by auxiliarymoose »

eitland wrote: post #25
auxiliarymoose wrote: post #16

I'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…

Back in the days we had this in programming as well with palettes of drag & drop components. It is kind of broken now, much thanks to using web applications (and applications that are basically just wrappers for web applications), but I don't know I if want to go back. On one side it was much easier when I could hack together a program that was good enough (since everything was the same bland grey). On the other hand…

I think there's a lot of potential for some more old-school UI in business software. People using points of sale, CRM/ERP/PLM/etc. systems, intranet portals, and so on don't really care about how nice it looks. Efficiency is more important.

Especially if it can be easy for non-technical people to build efficient UIs and databases (so they don't have to resort to spreadsheet contraptions), I think there's an opportunity here...

Re: Composition shouldn't be this hard

#33

Post by Toutouxc »

reedf1 wrote: post #12

Em dash , corny sub headings, numbered lists for no reason. I think some of this may be human written or edited, but it isn't passing my smell test. Sorry if this is mostly or all human written, but you have a very AI style.

If the article is a product of a LLM, I am willing to pay good money to be able to use that exact LLM for development. Because it seems to understand many things that current LLMs and their loudest proponents don't seem to understand.

Re: Composition shouldn't be this hard

#35

Post by Toutouxc »

LeCompteSftware wrote: post #22

There's a contradiction here that needs to be untangled: There are many examples of models that enable coherent systems within specific domains: - Type systems in programming languages catch many logic errors and interface misuses - The relational model in databases enables programmers to access incredible scale and performance with minimal effort. [...] So coherent systems are great: everyone should just buy into wh…

> The problem of course is that type systems and databases are not meaningfully "domain-specific." They aren't technical magic bullets but they separately provide real value for the use cases of "web and API serving, transaction processing, background processing, analytical processing, and telemetry." So then why hasn't the industry settled on a specific type system? Why do database vendors (and the SQL standard) keep breaking the relational model in favor of something ad hoc and irritating?

I'm not sure what point you're trying to make here. The list you're referring to is definitely a bit hand-wavy, but it also makes sense to me to read it as, for example, "today's relational databases (software) are almost perfectly aligned to the domain of relational databases (concept)". As in, MariaDB running on my Mac wraps an insane amount of complexity and smarts in a very coherent system that only exposes a handful of general concepts.

The concepts don't match what I'd like to work with in my Rails app, which makes the combination of both a "fragmented system", as the article calls it, but the database itself, the columns, tables, rows and SQL above it all, that's coherent and very powerful.

Re: Composition shouldn't be this hard

#36

Post by Toutouxc »

Good. The article makes sense to me, it gives names to certain things I've already sort of internalized intuitively and not only does it not end with a proposal to use AI to fix everything, it actually explains how AI (or at least today's LLMs) fails at the same boundaries as we do, which is exactly what I've been seeing so far.

I'm looking forward to whatever these people come up with, because I believe they do understand the problem, which is the best starting position you can have.

Re: Composition shouldn't be this hard

#37

Post by LeCompteSftware »

Toutouxc wrote: post #35
LeCompteSftware wrote: post #22

There's a contradiction here that needs to be untangled: There are many examples of models that enable coherent systems within specific domains: - Type systems in programming languages catch many logic errors and interface misuses - The relational model in databases enables programmers to access incredible scale and performance with minimal effort. [...] So coherent systems are great: everyone should just buy into wh…

> The problem of course is that type systems and databases are not meaningfully "domain-specific." They aren't technical magic bullets but they separately provide real value for the use cases of "web and API serving, transaction processing, background processing, analytical processing, and telemetry." So then why hasn't the industry settled on a specific type system? Why do database vendors (and the SQL standard) kee…

It depends on what you mean by "almost perfectly aligned to the domain of relational databases" but by my standards I can't think of a single production database where that's true, in large part because it's not true for SQL itself.

- Tables are not relations. Tables are multisets, allowing duplicate rows, whereas relations always have a de facto primary key. SQL is fundamentally a table language, not a relational language.

- NULL values are not allowed in relations, but they are in SQL. In particular, there's nothing relational about an outer join.

In both cases they are basically unscientific kludges imposed by the demands of real databases in real problems. "NULL" points to the absence of a coherent answer to a symbolic rule, requiring ad hoc domain-specific handling. So this isn't a pedantic point: most people wouldn't want to use a database that didn't allow duplicate rows (the SQL standard committee mentioned a cash register receipt with multiple entries that don't need to be distinguished, just counted). Nullable operations are obviously practical even if they're obviously messy. Sometimes you just want the vague structure of a table, a theory that's entire structural and has no semantics whatsoever. But doing so severely complicates the nice symbolic theory of relational algebra.

That's the point I'm getting at: there isn't really a "domain" limitation for relational algebra, it's more that there's a fundamental tradeoff between "formal symbolic completeness" and "practical ability to deal with real problems." Eventually when you're dealing with real problems, practicality demands kludges.

Re: Composition shouldn't be this hard

#38

Post by sigbottle »

Centralization 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 you have centralization, "composition" is not so hard. You get to define all your edge cases, define how you see the real world. Everybody doesn't have their own way of doing things, you have only one way of doing things.

Of course, then comes the extension of the software. People will see the world differently. And we have not algorithmically figured out how domains themselves evolve. The centralization abstraction breaks because people disagree and have different use cases.

I don't see how you get around this fundamental limitation. Are you going to impose yet another secret standard on everybody to get the interoperability you want? If you had full control over the world, yes, things are easy.

I'm not saying this as a diss. I truly do believe centralization works. AWS? Palantir? Building the largest centralized platforms in history and having everybody go through your tooling, when executed carefully, is a dummy effective strategy. In the past, monopolies were effectively this too (though I'd say buying steel is much different than "buying" arbitrary turing-complete services to help deal with a wide variety of semantic issues, and that's what precisely makes the 'monopoly' model break in the 21st century). And hey, at least AWS is a pretty good service, insofar that it makes certain things braindead easy. Is it a "good" service, intrinsically or whatever? I don't know.

Re: Composition shouldn't be this hard

#39

Post by lmc »

sigbottle wrote: post #38

Centralization 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...
Post reply on HN