Comment by zameermfm | Hacker News Reader

Comment by zameermfm | Hacker News Reader

I've seen this reusable assembly of software components again and again in the discussions for decades as well as in some older research papers. One side it's good that we check periodically if it can be done with any new tech that is available.

But has any efforts made it far that is universally plug and play? Open source projects had come close. Now those OS projects used by AI coding assistants come close. But no so much plug and play. I think I know why it wasn't happened, and may be can happen.

But I think the idea of abstractions in software engineering, which has guided OOP and even the classes today, is because it was somehow pioneered and may be natural to us to think of the systems that way. Abstractions change from person to person and from teams to teams. Two fleet system components for the same purpose built by two different team will internally behave differently. So universal plug and play for same flows might not work as we think it should be.

Even a low code/no code components, which has a high reusability among completely different projects by different people may introduce overhead that will not work for a said system? because their abstraction of the system isn't the one same as the component was designed? They end up reusing the abstractions of how the system should be around what is already there.

Whats happening now with AI coding assistants, would be the reusability of components software as it should be in this engineering world. It reuses the approaches from any OS project, we can even alternate between the approaches and we get the best out of it (if you know what you're doing) from the different choices and also via our own abstractions of how software should be.

I think we are there, antifragile way of software reusability. We should embrace the choas. A universal metaphorical plug and play for software engineering.

There has to be a central component that allows everything else to be glued together, discoverable parts and configurable bits. It’s really hard to do that generically enough that it works for everything. I think the closest I’ve seen was OSGi. You had ways to do anything based on modules that were completely decoupled, or you could introduce coupling in a very principled manner as needed. This worked for backend and front end components and the Eclipse IDE was built that way.

Java beans, from the same era, were envisioned to allow the creation of LEGO blocks with which you could build an application. They expected there would be market places where you could buy and sell Beans that did all sorts of things, from pure data representation to Swing UI components like charts and dashboards. I think OSGi built on that idea.

The problem was people thought OSGi was too complex, hard to learn, hard to debug and so on. I believe that was a problem with the execution, not the idea.

Now that I consider it, perhaps emacs is another example of this concept. You have access to use and modify nearly everything with small code snippets. It even has a UI system though that’s a bit outdated and really just text based ! People are trying to create similar systems using more modern technology but it’s very hard to do it well.

Perhaps yet another example is Smalltalk. Have a look at the Glamorous Toolkit (GTK) and its support for UIs that live inside the programming environment itself.

I think this hasn't been yet achieved because components need to interface with each other easily. This requires a standard that all components implement, from which everything can be assembled together.

From that perspective, the idea of microservices is basically "IKEA for software" relying on (primarily) HTTP as the interface between components. But this doesn't really solve it entirely, or very elegantly, because you still need to write the server boilerplate and deploy it, which will be different depending on the programming language being used. Also, your app may require different protocols, so you'll be relying on different standards for different component interactions, therefore the interface is not constant across your entire application.

I believe there's one way we can achieve this reliably, which is via WebAssembly, specifically via the WASM component model [1].

But we need an ecosystem of components, and building an ecosystem that everyone uses and contributes to will likely be the challenging part. I'm actually working on this right now, the platform I've been building (asterai.io) started out as an agent building platform (using WASM components for tool calls) but is evolving into being mostly a registry and (open source) lightweight runtime for WASM components.

The idea of using WASM to solve for this is very simple in concept. Think about a tool like Docker, but instead of images you have an "environment" which is a file that defines a set of WASM components and ENV vars. That's basically it, you can then run that environment which will run all components that are executable. Components can call each other dynamically, so a component can act as a library as well, or it may be only a library and not an executable. A component can also only define an interface (which other components can implement), rather than contain any implementation code.

This architecture solves the main challenges that stop "IKEA for software" from being a reality: 1. You can write WASM components in any programming language. 2. You can add components to your environment/app with a single click, and interfacing is standardised via WIT [2]. 3. Deploying it is the same process for any component or app.

Of course, it still would require significant WASM adoption to become a reality. But I think WASM is the best bet for this.

[1]: https://component-model.bytecodealliance.org [2]: https://component-model.bytecodealliance.org/design/wit.html

Reply on news.ycombinator.com