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

51–60 of 78 posts

Re: Composition shouldn't be this hard

#51

Post by well_ackshually »

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…

Your Godot scene doesn't work in Unreal Engine. I always felt that composition is unnecessarily hard in game engines infrastructure. I do web development as a hobby, and any .js file targeting the DOM works on any browser. I can't even run GDScript in Unity!

You're just comparing the wrong things. Yes, when you're locked into one environment, everything works together well. The moment you interact with outside systems, all hell breaks loose. If anything, what you're saying is just that platforms should have a much larger stdlib, or abstract platform differences properly (hint: this is only doable if you're a game engine and can afford to absolutely ignore _everything_ the OS does and just concern yourself with reinventing every wheel).

Not to say there's nothing good in the games side of things: a bunch of software could benefit from accepting that some systems like a big fat central message bus and singletons can be good when handled well.

Re: Composition shouldn't be this hard

#53

Post by lmc »

adammarples wrote: post #42
lmc wrote: post #39

Earlier quoted context omitted.

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 tr…

Fair point but AWS is also highly extensible, and i'm not sure about Palantir but i guess it must be too to a point? Maybe it's a classic case of good abstractions vs bad ones

Re: Composition shouldn't be this hard

#54

Post by mmillin »

This article reminded me a lot of a previous HN post[0] which hinted at choreographic programming[1]. While this post is light on details, I think this is an interesting space and deserves much more attention than it gets today. I'm excited to watch what comes from this space.

[0] Distributed Systems Programming Has Stalled: https://news.ycombinator.com/item?id=43195702

[1] Choreographic Programming: https://en.wikipedia.org/wiki/Choreographic_programming

Re: Composition shouldn't be this hard

#57

Post by soyyo »

DanielHB wrote: post #28

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

Yeah that's true, a product can be successful with truly bad code, but it also makes developers lives miserable each time they need to add a new feature, solve a bug, or simply understand how that entangled mess works.

Management and sales may not appreciate good software design and good code, the next developer that has to work on system will.

Re: Composition shouldn't be this hard

#58

Post by arboles »

DanielHB wrote: post #28

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

That comment seems off-topic, but just to exemplify:

In your example even as the interface for those products is unstable (UI that changes all the time, slightly broken API), those products are coded in a language like C++ or Java, which benefit from compiler error checking. The seams where it connects with other systems is where they're unstable. That's the point of this blog post.

Re: Composition shouldn't be this hard

#59

Post by arboles »

Toutouxc wrote: post #33
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.

Have you ever asked an LLM if it understands this stuff?

Re: Composition shouldn't be this hard

#60

Post by sigbottle »

lmc wrote: post #39
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...

No I mean like, centralization is unfortunately the thing that just works.

I work at a company that thinks extremely deeply about interoperability issues and everybody is on the opposite side: it can be said that we were made as a response to xkcd 927, to try and solve the issue.

I think the company is right in that semantic decentralization with interoperability would be a good end goal, but I think just plain darwinism explains the necessity of the opposite.

Post reply on HN