Please don't continue this thread. Whether you agree with me or not, it has devolved into personal and character insults by the other poster. You can continue the discussion with me somewhere else in the thread just not under yowlingcat. Blood has been spilled (figuratively) and tensions are extremely high.
Suffice to say, I'm not talking directly about category theory, that's one possibility of formalization (that seems quite unlikely). Other parts that have successfully made it into programming (and have changed programming for the better) including complexity theory, type theory and the Rust borrow checker. Two theories automate correctness and one is helpful in analysis of execution speed. My proposal is about one for modular organization and while category theory is a great candidate, it does have an incredibly high learning curve and to me that is why I agree with you that it is an unlikely candidate. I mean it does sort of exist already as a type checker in haskell... I'm more saying that I don't expect people to actually try to learn CT.
Either way, I believe more formality can be done and we don't have to force the entire industry to use monads and FP (FYI I prefer the style myself). If a formal theory about modular organization ever comes into vogue my guess is that it will exist more popularly as a "design pattern" in the industry rather than a programming framework or formal method. People can choose to use a pattern, or bend the rules... the main point and the crux of my entire effort is to say something along the lines of the fact that we need design patterns that provably improves "design." Without proof most of our efforts seem like steps to the side rather than forward.
If you have a reply, please place it directly under my parent post, not here.
edit:
That github link is picture perfect mirror of what I'm talking about in the industry. Thumbs up for bringing it to my attention.
Suffice to say, I'm not talking directly about category theory, that's one possibility of formalization (that seems quite unlikely). Other parts that have successfully made it into programming (and have changed programming for the better) including complexity theory, type theory and the Rust borrow checker. Two theories automate correctness and one is helpful in analysis of execution speed. My proposal is about one for modular organization and while category theory is a great candidate, it does have an incredibly high learning curve and to me that is why I agree with you that it is an unlikely candidate. I mean it does sort of exist already as a type checker in haskell... I'm more saying that I don't expect people to actually try to learn CT.
Either way, I believe more formality can be done and we don't have to force the entire industry to use monads and FP (FYI I prefer the style myself). If a formal theory about modular organization ever comes into vogue my guess is that it will exist more popularly as a "design pattern" in the industry rather than a programming framework or formal method. People can choose to use a pattern, or bend the rules... the main point and the crux of my entire effort is to say something along the lines of the fact that we need design patterns that provably improves "design." Without proof most of our efforts seem like steps to the side rather than forward.
If you have a reply, please place it directly under my parent post, not here.
edit: That github link is picture perfect mirror of what I'm talking about in the industry. Thumbs up for bringing it to my attention.