CHChrisMarshallNY·Jun 14, 2020
> I also don't think it's really how we do everything
Good point, and I agree. It was probably a rather "generalized" statement, on my part. I really meant "clumped-together opaque modules."
Yeah, COM worked (sort of), but CORBA has always struggled, and that was probably the real methodology that expressed the concept.
What I was thinking, was the "dependencyshere" that pretty much describes software development, these days; often linked through communications networks (as opposed to binary APIs). A bit like the distributed nature that was a big part of CORBA, but without the common data link layer.
There's an entire generation of engineers that can create marvelous applications, but barely understand what's going on in the components they use (which is not necessarily a bad thing. I don't know what's going on inside my calculator).
BTW:
Read the rest
Thanks for the excellent article.
For what it's worth, I use frameworks a lot. I have always believed in modular development, with modules being atomic, standalone entities with independent lifecycles.
Not all of these are "frameworks," per se. For example, my RVS_Spinner project, which implements a powerful "prize wheel spinner" in UIKit, is actually just a single source file, and not really worth importing as an opaque framework: https://github.com/RiftValleySoftware/RVS_Spinner
Same with my persistent prefs project, which is just a single, 300-line file: https://github.com/RiftValleySoftware/RVS_PersistentPrefs
Most of the code in these projects is testing code (I like testing. It's a good thing).
Modern package managers help that along.