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

61–70 of 116 posts

Re: A Philosophy of Software Design

#61

Post by corethree »

AnimalMuppet wrote: post #60
corethree wrote: post #6

An alternative viewpoint on software: https://www4.di.uminho.pt/~jno/ps/pdbc.pdf Rather then using blurry fuzzy concepts about software. This book is called "Program design by calculation". Which is to view software through the theoretical lens of math, science and engineering rather then "philosophy". Should software design be interpreted using the blurry and hand wavy concepts of philosophy and literature? or shoul…

Calculate ease-of-use of a GUI. Yes, you can, to some degree. You also can't, to some other degrees. Calculate correctness of some business logic, when part of "correctness" is correspondence to some badly-written procedures, and another part is correspondence to some regulations that are spread across ten thousand pages. Calculate correctness of an OS scheduling algorithm that has to work against a (not precisely kn…

Given a formal specification the idea is that a theory should be in place to calculate the design. We don't fully have this yet.

Given a hand wavy blurry specification, well... of course the implementation will be blurry and hand wavy as well.

Re: A Philosophy of Software Design

#62

Post by AnimalMuppet »

corethree wrote: post #61
AnimalMuppet wrote: post #60

Earlier quoted context omitted.

Calculate ease-of-use of a GUI. Yes, you can, to some degree. You also can't, to some other degrees. Calculate correctness of some business logic, when part of "correctness" is correspondence to some badly-written procedures, and another part is correspondence to some regulations that are spread across ten thousand pages. Calculate correctness of an OS scheduling algorithm that has to work against a (not precisely kn…

Given a formal specification the idea is that a theory should be in place to calculate the design. We don't fully have this yet. Given a hand wavy blurry specification, well... of course the implementation will be blurry and hand wavy as well.

Well... given a hand wavy blurry specification, you can create a formal specification - just not by formal means.

Re: A Philosophy of Software Design

#63

Post by corethree »

AnimalMuppet wrote: post #62
corethree wrote: post #61

Earlier quoted context omitted.

Given a formal specification the idea is that a theory should be in place to calculate the design. We don't fully have this yet. Given a hand wavy blurry specification, well... of course the implementation will be blurry and hand wavy as well.

Well... given a hand wavy blurry specification, you can create a formal specification - just not by formal means.

Changing the specification is fine.

Re: A Philosophy of Software Design

#64

Post by yawboakye »

i read this book. no, i studied it but found it less about philosophy of software design and more about how to deal with the current state of affairs. it does a good job here, in my opinion. but as a work of philosophy it undersells. one criteria is can a non-programmer study and have any idea what software design should be about? in my experience, the answer is no. a philosophy of software design shouldn’t necessarily target software designers/engineers. amazing book, wrong title.

Re: A Philosophy of Software Design

#66

Post by esafak »

matheusiacono wrote: post #35
a_c wrote: post #13

Haven't read the book yet but it seems to be about design principles, abstraction, divide and conquer, single responsibility and the like. Man made objects tend to be single-purposed and interact with few other components. Over the years I have come to appreciate the nature more and more. In nature, things are always multi-purposed and exist in a web of relationship. A bat is a pollinator, pest control, fertilizer an…

> People seem to talk more about infinite scaling is a fool's errand. I say so is specialising without seeing the forest first. I started first disagreeing with your point, but I think this last sentences captured what sticked to me. That's similar to the rule of three practice (three strikes and you refactor). I find it's always hard to keep the whole team aware of the forest, maybe that's why I've seen many prematu…

Communication, with clarity and repetition.

Re: A Philosophy of Software Design

#67

Post by anononaut »

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 more interfaces to document and learn." This is also smelly. Clean code is self documenting. It should be simple to read because it should read like prose. If levels of abstraction are kept to one per function, it's easy to understand what is happening. One would only drill down into functions if it were necessary to grok implementation details of an abstract function.

The comment on comments I also disagree with, although that's more contentions. In general I agree with Uncle Bob that comments are usually apologies. Most of the time the code should be refactored to not need comments. Ousterhout does bring up a point that names can sometimes be verbose as a result, but I can't be convinced that's a universal evil in the same way I can't be convinced that comments are a universal evil.

>And, with this approach, developers end up effectively retyping the documentation for a method every time they invoke it!

In what way is that a negative? This is a feature of self documenting code! This is what makes good code so great! This seems like some degree of misunderstanding of Clean Code.

I'm compelled to pick up this book, however.

Re: A Philosophy of Software Design

#68

Post by tabtab »

cc_ashby wrote: post #5

[redacted] are my favorite people on complexity. [redacted] was notably my professor for operating systems @ [redacted]. He taught not just ways to design software, but also ways to live. [redacted]’s work is also directly influenced by [redacted], as referenced at the end of his article. For [redacted], I suggest looking at the class website: [redacted] For [redacted], I suggest his book, [redacted]

Systems software design (SSD) is too different from application design to automatically use one conclusion for the other. Things like OS's and database engines are designed by mostly logical engineers for logical engineers.

Business and amininistration apps, on the other hand, reflect screwy random-seaming legislation and management whims, which often change in unexpected ways. Management doesn't care that much if their screwy rules and processes complicate automation. (Or don't comprehend the impact.)

I noticed this in debates where SSD experts showed code patterns that assumed too much uniformity between variations of concepts (sub-types, etc.). They just wouldn't fly in biz apps.

I lean toward using flags/tags to manage variations on themes instead of sub-typing, composition, or dependency inversion. Variation granularity has to be small in these domains.

Re: A Philosophy of Software Design

#69

Post by recursivedoubts »

TeMPOraL wrote: post #51
resonious wrote: post #47

Earlier quoted context omitted.

I feel the exact same about grug. I don't think people actually agree on what's simple, so it's pretentious to pretend your "simple" is the obvious one that a caveman would agree with.

Grug has some good points about complexity, but proceeds to take it all the way to full-blown, self-defeating anti-intellectual and anti-professional attitude. It makes sense for imaginary cavemen, but not for practitioners of a profession - people both capable and expected to learn the tools of their craft and continue learning past their first job interview.

ironically, i teach at a university

agree that anti-intellectualism is a danger if you take grugbrainism too far

Re: A Philosophy of Software Design

#70

Post by tabtab »

yawboakye wrote: post #64

i read this book. no, i studied it but found it less about philosophy of software design and more about how to deal with the current state of affairs. it does a good job here, in my opinion. but as a work of philosophy it undersells. one criteria is can a non-programmer study and have any idea what software design should be about? in my experience, the answer is no. a philosophy of software design shouldn’t necessari…

An honest book would explain the trade-offs instead of say "design X is always better than Y". Context and domain matter. One-size-fits-all is wrong.
Post reply on HN