4 ms·
> The problem with this dream is that to achieve it, (1) everything would need to be rewritten in a single language Not true. Look at COM. It has a reputation
by zvrba 5y ago
> The problem with this dream is that to achieve it, (1) everything would need to be rewritten in a single language
Not true. Look at COM. It has a reputation for being "ugly" and "legacy", but having worked with it, it's a marvel of engineering. There's still no "modern" system that can compare with it, IMO. In a C++ project of mine I implemented a COM server (not _that_ difficult) and could control the program from Powershell "for free". IOW, I got scripting with no glue, no bindings, nothing -- just instantiate the component from Powershell and invoke methods on it. (Courtesy of IDispatch, default implementation provided by ATL.)
> (2) to support remote distribution, every procedure/interface/method would need to have full remote semantics.
COM and DCOM implemented that. Where it came short -- or where I failed to find the documentation -- is about customizing timeouts of remote calls. I found some documentation about defaults, but, IIRC, the setting was system-wide and not applicable to a particular "connection".
- abernard1 5y agoCOM is an abject failure when you're dealing with a remote system. Like, I challenge you to find anyone with experience in heterogeneous systems software that thinks COM functions well. And so if we're talking about software that will always be hosted one one machine and memory space, fine, this can work. The 1994 paper brings up Spring which was implemented in a successful way with DI and AOP principles later in Java. It supported things like transactions across thread contexts, modules, etc. and those concepts were later adopted in other VMs like RoR or any other framework that used components + thread propagation. The problem always comes down to this megalomaniacal vision of a "unified"-anything. Aside from the agreement problem of adopting those concepts in new and existing languages, some of these concepts simply cannot be adopted in certain languages: thread context propagation, concurrency mechanisms, error handling. And even if we did not have the limitations of certain languages not supporting certain behavior, we have the problem that composition semantics are deeply rich in a domain. Creating primitives for composition and execution of code that persist across languages and systems does not work without consensus adoption of a language. The same reason why I can not go into IntelliJ, right-click, and "refactor" across my service architecture is the same reason why COM failed and why this will fail.