>It's definitely not "science", either is it "engineering", but it is definitely a discipline. You are judging one field by the axioms of another and then declaring it invalid because it doesn't comply.
It's a discipline the same way modern art is a discipline.
>But that literally has nothing to do with the actual problem, which as Twisol said is about mapping the problem domain and the software domain so that both are supported.
I explained to Twisol, that I am talking about the "problem domain." Both domains actually go hand in hand.
Think about it this way. Number theory is a formalization of numbers. A Math problem is in the problem domain that utilizes the formalization of numbers as a method for solving.
>Both hardware and software have moved in well known cycles. Processing has moved from CPUs to external processors (IO, then GPUs etc) and back again as hardware capabilities change. When comms are slow, its better to have two smart ends so that you minimize the information that needs to flow. When comms are fast, you can make one end "dumber".
So your point? I'm not getting what you mean by slow comms, and smart ends and dumb ends.
>Your entire premise is at a different level of abstraction than "software architecture" or "systems design". You haven't proposed a mechanism by which messy human problems can be formalized.
No it's not. It encompasses all levels. Have you ever used formal math to solve a "math problem" let's say accounting. Balancing the books of your finances. This is a "messy human problem" that uses a formalization of something else for solving.
>Software architecture and design is about dealing with non-deterministic, non-linear, fractal environments and the computer and systems science hasn't provided the theoretical frameworks that would allow the environments to be formalized so that they can be "engineered".
wrong. software is mostly deterministic. However, even a non-deterministic model is amenable to theory. Ever heard of probability? Additionally non-linear systems are just not as easily analyzable by certain methods such as calculus. You can still form a proof around a set of non-linear assembly instructions.
>allow the environments to be formalized so that they can be "engineered".
And that's my entire point. There's no point in iterating over the same endless design cycles and repeating the same mistakes over and over again every couple of years with a new framework that doesn't necessarily make anything better. Better to develop the formalism around "design" and optimize it. Another article like the one the parent poster posted is pointless and doesn't move the needle forward At all.
>It's definitely not "science", either is it "engineering", but it is definitely a discipline. You are judging one field by the axioms of another and then declaring it invalid because it doesn't comply.
No I'm looking at the field and seeing that we're going nowhere with endless conjectures and analogies about design. I'm seeing the patterns of today aren't that much different then the patterns from the past. I'm also seeing the software being called "engineering" while eschewing much of the formalism that is part of engineering.
Due to all this I'm saying, that the field is going nowhere and is pretty much a big sham. I'm tired of the pointless flat circle of repeating history. "Systems Design" from the software perspective is therefore ripe for formalization and theory.
It's a discipline the same way modern art is a discipline.
>But that literally has nothing to do with the actual problem, which as Twisol said is about mapping the problem domain and the software domain so that both are supported.
I explained to Twisol, that I am talking about the "problem domain." Both domains actually go hand in hand.
Think about it this way. Number theory is a formalization of numbers. A Math problem is in the problem domain that utilizes the formalization of numbers as a method for solving.
>Both hardware and software have moved in well known cycles. Processing has moved from CPUs to external processors (IO, then GPUs etc) and back again as hardware capabilities change. When comms are slow, its better to have two smart ends so that you minimize the information that needs to flow. When comms are fast, you can make one end "dumber".
So your point? I'm not getting what you mean by slow comms, and smart ends and dumb ends.
>Your entire premise is at a different level of abstraction than "software architecture" or "systems design". You haven't proposed a mechanism by which messy human problems can be formalized.
No it's not. It encompasses all levels. Have you ever used formal math to solve a "math problem" let's say accounting. Balancing the books of your finances. This is a "messy human problem" that uses a formalization of something else for solving.
>Software architecture and design is about dealing with non-deterministic, non-linear, fractal environments and the computer and systems science hasn't provided the theoretical frameworks that would allow the environments to be formalized so that they can be "engineered".
wrong. software is mostly deterministic. However, even a non-deterministic model is amenable to theory. Ever heard of probability? Additionally non-linear systems are just not as easily analyzable by certain methods such as calculus. You can still form a proof around a set of non-linear assembly instructions.
>allow the environments to be formalized so that they can be "engineered".
And that's my entire point. There's no point in iterating over the same endless design cycles and repeating the same mistakes over and over again every couple of years with a new framework that doesn't necessarily make anything better. Better to develop the formalism around "design" and optimize it. Another article like the one the parent poster posted is pointless and doesn't move the needle forward At all.
>It's definitely not "science", either is it "engineering", but it is definitely a discipline. You are judging one field by the axioms of another and then declaring it invalid because it doesn't comply.
No I'm looking at the field and seeing that we're going nowhere with endless conjectures and analogies about design. I'm seeing the patterns of today aren't that much different then the patterns from the past. I'm also seeing the software being called "engineering" while eschewing much of the formalism that is part of engineering.
Due to all this I'm saying, that the field is going nowhere and is pretty much a big sham. I'm tired of the pointless flat circle of repeating history. "Systems Design" from the software perspective is therefore ripe for formalization and theory.