Is this true? I'm just picturing in my mind juxtaposing Fowler's writings and I dunno, an art critic's.
Category theory is cool and important, but to insinuate that all design problems can be "derived" by it sounds like a mathematician declaring that the work of all civil engineers as just "applied math".
>Is this true? I'm just picturing in my mind juxtaposing Fowler's writings and I dunno, an art critic's.
He does. The language is different. He uses technical buzz words from the tech industry rather then the jargon from the art industry.
A paper with science will have data and statistics. A paper with logic will have formal descriptions, axioms and theorems. Martin Fowlers papers contain little of any of these things.
>Category theory is cool and important, but to insinuate that all design problems can be "derived" by it sounds like a mathematician declaring that the work of all civil engineers as just "applied math".
I never said that all solutions can be derived from category theory, I meant that the current state of category theory hints at a possibility that this could be possible in the future.
Civil engineers do a lot of similar things to what a proper Software architect should do. They use science, theory and art to materialize their ideas. I'm saying category theory COULD be pointing at way of making that "art" section smaller or eliminating it all together. Though total elimination is IMO unlikely I think making it much smaller is very viable. This process is even more amenable to computing systems as the solution space is much smaller. For computing systems, I think it's more reasonable to say that it may be possible in the future for "art" to be completely eliminated from this field, still unlikely imo, but definitely more likely then other types of engineering.
> I never said that all solutions can be derived from category theory
But I think what you're saying is that they should. I don't understand how this is possible or desirable.
However formally described the internals of a system are, it must interact with the world, and designing those boundaries depends entirely on what you want your system to do, which is an art. Just like you can't get an ought from an is, you can't derive a solution to "will this satisfy the user" or "will this be done in time for market" from correctness proofs of code.
You might be referring purely to the computational soundness of a system, but that is to system design as the structural soundness of concrete is to the architecture of a bridge.
>But I think what you're saying is that they should. I don't understand how this is possible or desirable.
Definitely not possible (yet) but this may be possible in the future. Whether it should be or not is not something I talked about. But since you brought it up, my opinion is that if there exists a function that can definitively derive the best possible system for a problem given a set of requirements then YES absolutely I would use it rather then design a system myself.
Whenever we design a system we have no idea whether that system is the "best" possible solution. Better to derive the best then to "design" or aka "estimate" a solution.
Anyway this stuff is mostly speculative not entirely worth debating over speculation. If it never happens what's the point?
>However formally described the internals of a system are, it must interact with the world, and designing those boundaries depends entirely on what you want your system to do, which is an art.
This is true. Designing the specifications of a system is largely an art because you could be trying to satisfy a customer who needs and wants are unknown and varying. This is not what I am referring too.
I am talking about implementing a solution to MEET those specifications. This part unfortunately is also largely an art. I'm speculating about a function that can potentially FIND the BEST solution to meet a specification and therefore eliminating the artistic portion of this part of the problem, not the specification part.
>You might be referring purely to the computational soundness of a system, but that is to system design as the structural soundness of concrete is to the architecture of a bridge.
The architecture of a bridge is different from software architecture. I am talking about the "architecture" of a system to meet the high level needs of a specification.
The product designer translates the world of vagueness and opinion into a set of exact specifications.
The software architect builds a system to meet those specification or potentially changing specification. I am referring to the process being implemented by the software guy, not the product designer.
The bridge architect usually is a hybrid role he does a bit of translating requirements and implementation as well. It's less clear cut.
To fit your analogy lets use a designer instead. The designer gives me a shape he wants the bridge to be in, and how many people are going to walk across the bridge per day. The civil engineer builds the bridge to meet that specification using the cheapest materials possible. The civil engineer is not concerned with whether or not the shape of the bridge is pleasing to the people who walk over the bridge. That part is the responsibility of the designer.
Think about it, even for systems implemented by the software architect today, even when the architect has knowledge about the EXACT specifications needed to be fulfilled by the system he is largely doing a lot of design work. He has no way of verifying whether his design is the best way to do things.
Is this true? I'm just picturing in my mind juxtaposing Fowler's writings and I dunno, an art critic's.
Category theory is cool and important, but to insinuate that all design problems can be "derived" by it sounds like a mathematician declaring that the work of all civil engineers as just "applied math".