Component-based software engineering

What Hacker News says

1. wahernApr 2020
   You can't refactor any implementation (i.e. shuffle code) into components and magically make verification tractable. But there's more than one possible implementation to any particular functional problem, and some of those implementations might be tractable.

   AFAIU Component-Based Software Engineering has been a bedrock principle of applied formal verification for decades. It's a process approach. If a functional problem is sufficiently complex it's necessary, if not always sufficient, as a practical matter to use a component architecture. And even if it's not sufficient, a solution where some components are formally verified is better than where none are. Circumscribing soundness isn't an alternative, it's complementary.

   You're right, it's not by itself a "solution" in the sense of completely resolving the problem; it's a "solution" in the other meaning of that word--a means of dealing with a problem.

   Show morethread
2. pronApr 2020
   > AFAIU Component-Based Software Engineering has been a bedrock principle of applied formal verification for decades.

   Yes, and still the only software verified using such techniques has been tiny (< 10KLOC) and required extraordinary simplification and tremendous effort by specialists. It's like saying that particle accelerators have been a bedrock principle of turning lead into gold. It "works" but not in any sense that makes it a repeatable, affordable practice. Moreover, the gap between the size of programs verifiable in this way and the size of a "normal" piece of business software has stayed pretty much constant over the past four decades -- 3 orders of magnitude.

   > And even if it's not sufficient, a solution where some components are formally verified is better than where none are.

   Better in what sense? Is it better to soundly verify one component or to use unsound methods on an entire system (even assuming similar costs, but often the latter is cheaper). Soundness is costly and is never a real requirement as a software system is a physical system, anyway; machines only perform machine instructions according to spec with some probability, and probability is all engineers can ever hope for. But sure, sometimes there are small components that are easy enough to verify with deductive proofs, making it the most affordable path to high confidence, although I'd say that's the rare exception rather than the rule.

   > Circumscribing soundness isn't an alternative, it's complementary.

   It allows you to use automated methods that don't require careful modularity.

   Show morethread
3. pjmlpNov 2018
   Yes, I did watch that talk back when he did it. I always follow CppCon talks.

   Then you should also watch the talks he did later at Unite, after joining Unity.

   As I mentioned regarding ECS, on CS literature.

   For example,

   "Component Software: Beyond Object-Oriented Programming"

   https://www.amazon.com/Component-Software-Object-Oriented-Pr...

   First edition (1997) used Component Pascal, C++ and Java, while the 2nd edition replaced Component Pascal with C#.

   "Component-Based Software Engineering: Putting the Pieces Together"

   https://www.amazon.com/Component-Based-Software-Engineering-...

   ECS and Data-oriented programming aren't the same thing.

   Show morethread
4. pjmlpOct 2018
   Published in 1997, "Component Software: Beyond Object-oriented Programming", followed by "Component-Based Software Engineering: Putting the Pieces Together" in 2001.

   https://www.amazon.com/Component-Software-Beyond-Object-Orie...

   https://www.amazon.com/Component-Based-Software-Engineering-...

   The problem is how badly many schools teach OOP paradigms, and how many frameworks abuse a specific style of OOP.

   thread