Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

A Philosophy of Software Design

web.stanford.edu

Post reply on HN
Print view View original

101–110 of 116 posts

Re: A Philosophy of Software Design

#101

Post by corethree »

nuancebydefault wrote: post #81
corethree wrote: post #56

Earlier quoted context omitted.

No. theory is very much part of the creation of the bridge. It is not just for verification. If you read more carefully. What I am saying is that in software engineering, there is no theory. It's all Design. All made up. There's also no verification of the design itself.

> There's no verification of the design itself. I think this is mostly a philosophical statement, but it certainly has truth to it. Code reviews / rework tackle mostly the code, but not the fundamental design. However the execution of the code tackles the design as well: - If the design is wrong, the result is bad, that is detected at the execution phase. - If the design is suboptimal (hard to maintain or extend, bad…

>I think this is mostly a philosophical statement, but it certainly has truth to it.

It's fact. What theory is there to prove that the following design is the best possible design? What does "best" even mean? We can't verify formally in anyway how good a design is overall.

We can verify, efficiency, we can verify speed, and we can verify correctness. But design? We can't verify that.

Re: A Philosophy of Software Design

#102

Post by yoyonamite »

anononaut wrote: post #67

I can't at all agree with the added differences of opinion with Uncle Bob's Clean Code. The author argues a reducing the size of a function of "a few dozen lines" likely won't improve the readability of the code. That's not even defensible! I would fail any (professional) code review for having that many lines of code in a function. It's a complete failure of abstraction. He later goes on to say "more functions means…

Good code to me usually comes down to things like state management, code organization, ... Having code that reads like prose isn't a high priority to me, but I'm familiar with that style and I can see why people like it. I just wish they'd realize they're expressing an opinion on style instead of a fact.

Re: A Philosophy of Software Design

#103

Post by agent327 »

corethree wrote: post #101
nuancebydefault wrote: post #81

Earlier quoted context omitted.

> There's no verification of the design itself. I think this is mostly a philosophical statement, but it certainly has truth to it. Code reviews / rework tackle mostly the code, but not the fundamental design. However the execution of the code tackles the design as well: - If the design is wrong, the result is bad, that is detected at the execution phase. - If the design is suboptimal (hard to maintain or extend, bad…

>I think this is mostly a philosophical statement, but it certainly has truth to it. It's fact. What theory is there to prove that the following design is the best possible design? What does "best" even mean? We can't verify formally in anyway how good a design is overall. We can verify, efficiency, we can verify speed, and we can verify correctness. But design? We can't verify that.

How do you prove that a bridge is the 'best' design? What does 'best' mean, for a bridge?

Re: A Philosophy of Software Design

#104

Post by auggierose »

corethree wrote: post #99
auggierose wrote: post #97

Earlier quoted context omitted.

You can apply algebra to your functions, while also acknowledging that there are other interesting objects than just functions. It's called logic, and in my opinion, logic is really just algebra. Number theory is not just numbers, by the way. It has plenty of functions as well, for example the Riemann zeta function.

>You can apply algebra to your functions, while also acknowledging that there are other interesting objects than just functions. It's called logic, and in my opinion, logic is really just algebra. The basis of all formal theories includes logic. I haven't heard of any illogical formal theories. Logic isn't just algebra it's everything. I acknowledge there are other interesting primitives other than functions. But doe…

> Anyway the point here is that we want to formulate a theory with the lowest amount of primitives and axiomatic concepts.

A theory makes only sense with respect to some logic. So first, you need to define what logic you are using. This logic is your theory with the lowest amount of primitives and axiomatic concepts.

Now, once you have that, you can turn your attention to other things on top of that. If you are interested in functions only, sure. You can for example study the lambda calculus.

But don't pretend that this is so that you can reason about computer programs better. Sure, learning more about functions is useful, but numbers are also very important for computer programs. So are trees. And graphs. Expressing all of these just in terms of functions can be a fun exercise (pun intended, Church numerals anyone?). But instead of trying to express the important concepts of your program as functions, and then studying them, maybe your time is better spent studying the concepts themselves directly.

Re: A Philosophy of Software Design

#105

Post by corethree »

agent327 wrote: post #103
corethree wrote: post #101

Earlier quoted context omitted.

>I think this is mostly a philosophical statement, but it certainly has truth to it. It's fact. What theory is there to prove that the following design is the best possible design? What does "best" even mean? We can't verify formally in anyway how good a design is overall. We can verify, efficiency, we can verify speed, and we can verify correctness. But design? We can't verify that.

How do you prove that a bridge is the 'best' design? What does 'best' mean, for a bridge?

That's what a full formal theory encompasses. We need to define the term formally. It can be done for software organization.

We've defined it for algorithmic complexity. Turns out it's two metrics.. speed and memory. Best means the lowest N, with primitives being algorithmic loops.

What are the primitive modules used in program organization? Given 3 of the smallest possible primitive modules we can define in computing and all the ways possible to compose those three modules. What composition would be best? What is the metric that fits most well with our notion of best? There may be several metrics here. These questions are the ones that are asked when formalizing a theory derived from intuition.

For the bridge it's likely balancing several metrics we already know. Safety, cost, length, etc. Once those metrics are quantified a theory exists to find the best. It's called optimization theory.

Re: A Philosophy of Software Design

#106

Post by agent327 »

corethree wrote: post #105
agent327 wrote: post #103

Earlier quoted context omitted.

How do you prove that a bridge is the 'best' design? What does 'best' mean, for a bridge?

That's what a full formal theory encompasses. We need to define the term formally. It can be done for software organization. We've defined it for algorithmic complexity. Turns out it's two metrics.. speed and memory. Best means the lowest N, with primitives being algorithmic loops. What are the primitive modules used in program organization? Given 3 of the smallest possible primitive modules we can define in computin…

Those formulas are not reversible. You can compute load bearing capacity of a design, and you can compute cost of a design, but you cannot start with load bearing capacity and cost, run those through a formula, and get a bridge. Or even a sketch of a bridge.

Design comes first, always, whether it is for real-world items or for software. The design is then validated using formal methods, and iterated until it meets the required goal.

If you still want to maintain your position that you can compute a bridge, feel free to point out a source that describes the formula for bridges. Or any object that takes significant engineering, really.

Re: A Philosophy of Software Design

#107

Post by corethree »

agent327 wrote: post #106
corethree wrote: post #105

Earlier quoted context omitted.

That's what a full formal theory encompasses. We need to define the term formally. It can be done for software organization. We've defined it for algorithmic complexity. Turns out it's two metrics.. speed and memory. Best means the lowest N, with primitives being algorithmic loops. What are the primitive modules used in program organization? Given 3 of the smallest possible primitive modules we can define in computin…

Those formulas are not reversible. You can compute load bearing capacity of a design, and you can compute cost of a design, but you cannot start with load bearing capacity and cost, run those through a formula, and get a bridge. Or even a sketch of a bridge. Design comes first, always, whether it is for real-world items or for software. The design is then validated using formal methods, and iterated until it meets th…

>Those formulas are not reversible. You can compute load bearing capacity of a design, and you can compute cost of a design, but you cannot start with load bearing capacity and cost, run those through a formula, and get a bridge. Or even a sketch of a bridge.

What goes on today is largely just a bunch of templates. See the requirements and pick a template and modify it accordingly. That template can definitely be plugged into a optimization equation.

ML models can be used to find the best templates if you want. It's a way to use compute to "design" things and sort of estimates the most optimal design given a set of other templates. These things can be modelled but sometimes they are not computationally tractable to find the best of the best optimal system.

>Design comes first, always, whether it is for real-world items or for software. The design is then validated using formal methods, and iterated until it meets the required goal.

The difference between software and real world engineering is that in software the primitives are well defined and few. You aren't dealing with thousands of variables so you don't need something like optimization theory or ML to estimate the optimum.

There can very much be a theory for software that is practical because software is basically trying to simulate mathematics. It's not so complicated that it can't be done.

>If you still want to maintain your position that you can compute a bridge, feel free to point out a source that describes the formula for bridges. Or any object that takes significant engineering, really.

I maintain that one exists. We just don't know it and may never know it because the theory would involve billions of primitives. I maintain that one exists for software design and while we don't know it right now I think it's possible to find one.

What I don't like about this question is the subtle sass of "maintaining your position to compute a bridge". It's a bit rude. Feel free to not be rude. thank you.

Re: A Philosophy of Software Design

#108

Post by corethree »

auggierose wrote: post #104
corethree wrote: post #99

Earlier quoted context omitted.

>You can apply algebra to your functions, while also acknowledging that there are other interesting objects than just functions. It's called logic, and in my opinion, logic is really just algebra. The basis of all formal theories includes logic. I haven't heard of any illogical formal theories. Logic isn't just algebra it's everything. I acknowledge there are other interesting primitives other than functions. But doe…

> Anyway the point here is that we want to formulate a theory with the lowest amount of primitives and axiomatic concepts. A theory makes only sense with respect to some logic. So first, you need to define what logic you are using. This logic is your theory with the lowest amount of primitives and axiomatic concepts. Now, once you have that, you can turn your attention to other things on top of that. If you are inter…

>A theory makes only sense with respect to some logic. So first, you need to define what logic you are using. This logic is your theory with the lowest amount of primitives and axiomatic concepts.

Logic as I know it can't be made up. It's already well defined and the basis for all other formal theories.

The lowest amount of primitives and axiomatic concepts is largely a design choice for developing a theory. Makes it easier to deal with the theory rather than a theory that starts out with extremely complicated axioms.

>But don't pretend that this is so that you can reason about computer programs better. Sure, learning more about functions is useful, but numbers are also very important for computer programs. So are trees. And graphs. Expressing all of these just in terms of functions can be a fun exercise (pun intended, Church numerals anyone?). But instead of trying to express the important concepts of your program as functions, and then studying them, maybe your time is better spent studying the concepts themselves directly.

Yeah but I would want to prune all that other stuff away and focus on a theory on the best way to organize and abstract programs. The primitive most important for that is the function because that's basically at it's core all a computer does, just calculate stuff.

Re: A Philosophy of Software Design

#109

Post by auggierose »

corethree wrote: post #108
auggierose wrote: post #104

Earlier quoted context omitted.

> Anyway the point here is that we want to formulate a theory with the lowest amount of primitives and axiomatic concepts. A theory makes only sense with respect to some logic. So first, you need to define what logic you are using. This logic is your theory with the lowest amount of primitives and axiomatic concepts. Now, once you have that, you can turn your attention to other things on top of that. If you are inter…

>A theory makes only sense with respect to some logic. So first, you need to define what logic you are using. This logic is your theory with the lowest amount of primitives and axiomatic concepts. Logic as I know it can't be made up. It's already well defined and the basis for all other formal theories. The lowest amount of primitives and axiomatic concepts is largely a design choice for developing a theory. Makes it…

> Logic as I know it can't be made up. It's already well defined and the basis for all other formal theories.

Of course logic can be made up, and in fact, all logics are. First-order logic, simply-typed higher order logic, dependent type theory, all made up.

My favourite made up logic is Abstraction Logic (http://abstractionlogic.com).

But I guess what you mean is that you are a mathematical realist. That's good! I am too.

> Yeah but I would want to prune all that other stuff away and focus on a theory on the best way to organize and abstract programs. The primitive most important for that is the function because that's basically at it's core all a computer does, just calculate stuff.

If that's what you want to do, then that's what you want to do!

Re: A Philosophy of Software Design

#110

Post by corethree »

auggierose wrote: post #109
corethree wrote: post #108

Earlier quoted context omitted.

>A theory makes only sense with respect to some logic. So first, you need to define what logic you are using. This logic is your theory with the lowest amount of primitives and axiomatic concepts. Logic as I know it can't be made up. It's already well defined and the basis for all other formal theories. The lowest amount of primitives and axiomatic concepts is largely a design choice for developing a theory. Makes it…

> Logic as I know it can't be made up. It's already well defined and the basis for all other formal theories. Of course logic can be made up, and in fact, all logics are. First-order logic, simply-typed higher order logic, dependent type theory, all made up. My favourite made up logic is Abstraction Logic ( http://abstractionlogic.com ). But I guess what you mean is that you are a mathematical realist. That's good! I…

>Of course logic can be made up, and in fact, all logics are. First-order logic, simply-typed higher order logic, dependent type theory, all made up.

That's like saying math is made up. Is it made up or is it discovered?

You're just being pedantic.

>If that's what you want to do, then that's what you want to do!

Yeah and if you want some theory of program design that encompasses every damn concept under the sun as an axiom go for it as well! Genius!

Post reply on HN