[CodeGlitch]

What I love about stack overflow is that you don't just get the answer to your question (usually) but the top rated answers also include the "whys". Meaning you get to expand your understanding of the domain in question.

People who write stack overflow answers really are the unsung heroes of the open source world.

[shadowgovt]

This highlights something I believe to be a deeper truth about programming in general: the whys matter, sometimes more than the hows.

So much of programming is patterns that exist for extremely arbitrary reasons (note: not acausal reasons, just reasons that are unimportant to the immediate problem domain one is trying to solve, or perhaps important in a way one doesn't yet know). Knowing those reasons can give you some mental hooks to hang the arbitrariness off of.

COM, which Joel mentions anecdotally at the top of the article, is a great example of that. I think the biggest challenge people have remembering why COM works the way it does is it's there to solve a problem that primarily the Microsoft software ecosystem had, which didn't show up in other software ecosystems as strongly: Microsoft had a vested financial interest in enabling developers to create closed-source binary blobs that could interact with each other via exposed objects.

Though COM is language-agnostic, most examples from textbooks of the mid-'90s era reveal the big problem it's solving: C++ was the hot language at the time, but C++ doesn't standardize name-mangling, so two arbitrary binary blobs of C++ code from two different compilers weren't guaranteed to be able to use the objects in each other's libraries. This isn't a problem Apple's software stack saw so often (Apple had fewer toolchains, so compiler incompatibility was less frequent a problem) and it was rarely a problem in the open-source OS ecosystems (if you're passing around source code instead of closed-source binary blobs, you don't care about name-mangling issues because you're building the source as a lump under the watchful eye of one compiler). But in the Windows world, with a pile of choices for compiler and a business need to support closed-source binary blobs that could expose objects, it was hell.

It's helpful in understanding COM to understand why Microsoft's ecosystem needed a way for closed-source libraries to expose objects in a language-agnostic way.

[WorldMaker]

> This isn't a problem Apple's software stack saw so often

Apple had the exact same component object model problems which is why it took the long way around discovering exactly the right way to deal with it and eventually gave up and bought NeXTStep. Objective-C exists in large parts to solve the same problems that COM does! It also has a reference counting component memory model and a component message model designed to handle compiler name-mangling issues.

> closed-source binary blobs that could expose objects

Component systems aren't just for closed source, though. They are also for deployment management and trying to solve problems where multiple apps from different teams need to interact and trying to avoid strong coupling to allow better flexibility/resiliency.

Even in Open Source there have been plenty of COM-like projects. Gnome 2 built a lot of early things on Bonobo which was pretty directly a COM clone. Since then things have migrated to D-Bus, and while D-Bus is not a COM clone in the way that Bonobo was, it is still there to solve a lot of the same coupling problems so that individual apps can communicate without directly depending on one another. D-Bus just takes more of a publish/subscribe approach than an object model for components that more directly communicate.

[HWR_14]

What are you looking up that you get "whys"? I consider myself lucky if SO returns "here's the name of the library function you assumed existed that does what you want."