Component technology in an embedded system (2010)

(polberger.se)

1 points | by davidpolberger 4 hours ago ago

1 comments

  • davidpolberger 4 hours ago ago

    Back in 2005, CBSE (Component-Based Software Engineering) was already on its way out. Remember COM and CORBA? That year, I started doing my thesis work at Sony Ericsson in Lund. The goal was to modify their IDL compiler to generate runtime traces using UML sequence diagrams.

    I defended my thesis in 2010 and produced a site, generated straight from the LaTeX sources. It's been live since then, but I just gave it a fresh coat of paint. (While the content was painstakingly written by hand, Claude Code and Opus 5.5 modernized the site itself.)

    I don't think we have solved what CBSE set out to do. Most libraries are still confined to their "native" environments. I've just made a formula compiler written in Java usable from JavaScript through TeaVM. I also made its runtime system accessible from Java using GraalVM, and neither was easy. When I wrote all that boilerplate (or rather, had Claude do it), I longed for an interface description language.

    One thing that has changed is that open source, available at no cost, is the default for libraries these days, whereas components in the CBSE sense were expected to be proprietary binary blobs. With the source available, anyone can port a library to their favorite environment. LLM agents make that even easier. That's great for making libraries fit well with their host language, but on the flip side, those versions tend to diverge.

    Of course, gluing together services that run on different machines and in different processes is done today too, with microservices. I would have expected just one or two unifying ecosystems, not the large number of competing technologies we now have.

    So what's your take on all this? Did something get lost when we moved away from COM and CORBA, or should we just be happy that all that (enormous) complexity is gone?