Comment by corethree
2 years ago
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.
> And that part can be "design."
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.
Even the book is incomplete. It's a draft.