Formal theories are not independent of belief at all! They are based upon axioms, which are the beliefs that must be true in order for the formal theory to be useful.
I agree. But then what is the difference between religion and an axiom? Both are beliefs. Are you saying there is no difference? Maybe technically there is no difference. But clearly from the practical perspective there's a huge mutually exclusive difference.
We should not merge GOF design patterns and SOLID or any other made up "software religion" with a formal theory.
I think I do understand your argument: In your view a formal theory has a level of rigour and evidence that exceeds that of a "best practice" such as SOLID. And I agree with that, but the point is that writing code based on formal theories is still just another software development philosophy with its own set of fuzzy trade offs. For example:
Given ten different calculuses with completely different syntaxes and modes of expression, (for example lamba calculus, combinatory calculus, a Turing machine, a type inference calculus, euclidean geometry, ultrafinitism), each and every one of these ought to be able to express a formal theory that is equivalent. When you are writing software based upon some theory, which calculus will you use to express it? A giant tree of lambdas? A state machine? Pure functions? Mathematically they are all proven to be equivalent so you must make a practical decision based on which one that you believe is best for the job. How will you make that decision? Most likely you will follow some set of personal heuristics that in your experience have shown one form of expression is easier for you than others. And thus you are adopting some philosophy of software even if you try tell yourself that you aren't.
Sure in that sense, you need to choose the theory. And that part can be "design." You can have a meta theory of theories where you can calculate the best theory but that's too impractical. Just choose a theory via "design."
As of right now we don't have a theory that encompasses the best way to abstract and organize primitives.
I'm saying at least use A theory. Any theory. The book pdbc contains a theory and one that from what I've seen comes closest to program design via calculation.
Basically that book is, in short, about functional programming or the lambda calculus way to do things... this is better because it allows you to more exploit the power of math and algebra which are basically the basis for which we developed all of our other formal theoretical concepts.
It's those design choices that are subject to all of the dilemmas that necessitate schools of thought such as those in "A Philosophy of Software Design". The mathematics hasn't been invented yet to determined the most efficient way to lay out complex software. And it won't be until long after our jobs are all replaced by fuzzy AI. Until then, software development is a performance art subject to many different schools of thought or philosophies of design, and you're fooling yourself if you think that you can escape from them.
At the end of the day, there is no mathematical formula to choose which color the border of a selected text-input should be: Only conventions, design philosophies, tastes and opinions.
The book you've linked (although I haven't read it all yet), provides a design philosophy for approaching a subset of the problems that computer programmers face. But: It doesn't have any writing on the hardest problems that programmers face in regards to IO and managing persistent state in a concurrent-access environment.
>It's those design choices that are subject to all of the dilemmas that necessitate schools of thought such as those in "A Philosophy of Software Design".
The philosophy of design doesn't talk about theory at all. It is an opinion on the most efficient way to do things not a proof.
If there was a theory, the answer on the "best" way would be a proof. The answer is indisputable given the axioms.
>At the end of the day, there is no mathematical formula to choose which color the border of a selected text-input should be: Only conventions, design philosophies, tastes and opinions.
And that's why the color of the border is not technically part of software engineering. They call that department the art department or the graphic design department. And the people who work this stuff are called "designers"
>The book you've linked (although I haven't read it all yet), provides a design philosophy for approaching a subset of the problems that computer programmers face. But: It doesn't have any writing on the hardest problems that programmers face in regards to IO and managing persistent state in a concurrent-access environment.
No it doesn't provide a philosophy. It provides a theory based on axioms. The choice of the axioms and the resulting theory may be done using "philosophy" but the outcome of that choice is a formal theory.
>The book you've linked (although I haven't read it all yet), provides a design philosophy for approaching a subset of the problems that computer programmers face. But: It doesn't have any writing on the hardest problems that programmers face in regards to IO and managing persistent state in a concurrent-access environment.
There's a short chapter on monads but your right. I never said there's a complete theory and I hinted and mentioned several times in this overall thread that there is no complete theory.
