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

31–40 of 116 posts

Re: A Philosophy of Software Design

#31

Post by lvturner »

corethree wrote: post #25
lvturner wrote: post #19

Earlier quoted context omitted.

Just because it doesn't use formal theory now --- does not mean it/we shouldn't use it. I'm talking about needs, not haves.

Well in all other engineering fields although they are used in conjunction. The two concepts are practically more or less mutually exclusive. There's no room for "design" when finding the shortest distance between two points because the shortest distance between two points is done via calculation using formal theory. Things like user-friendliness can be "philosophical". You can separately and selectively apply theory…

I see what you are driving at and I think we are looking at the problem from slightly different lenses yet still drawing much the same conclusions.

There's no room for design in finding the shortest distance between two points, but there is room for design in picking which points you wish to find the distance on -- I think perhaps for meaningful discussion on this specific topic my definition of "Software Design" is too broad-scope ;)

Re: A Philosophy of Software Design

#32

Post by mbwgh »

In addition to 'A philosophy of Software Design', I would also recommend the less well known 'Object-Oriented Design Heuristics'.

It came out at the same time as the GoF book, but I think it is still relevant today and similar in spirit to Ousterhout's book.

Re: A Philosophy of Software Design

#33

Post by cryptography »

codeflo wrote: post #11
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]

I'm a fan of Ousterhout's writing; "A philosophy of software design" clarified a lot of my thinking around complexity. I find the "Grug Brain" stuff pretentious and dishonest. "Me not smart. Me like simple things. Me not believe in hype. Hence why me invent complex new frontend framework, and then me hype it up beyond reason." (To be clear what I'm saying, my point is not that HTMX is overhyped -- it might be, but th…

Do you think this would be beneficial for a somewhat perplexed CTO of a newly seed-funded startup? Or would it be wiser for me to concentrate on my current responsibilities and return to this book when my mind is clearer? I'm feeling a bit overwhelmed and under pressure, and I'm concerned that reading this book might add to the chaos. I would appreciate your input.

Re: A Philosophy of Software Design

#34

Post by xoac »

ludston wrote: post #24
corethree wrote: post #23

Earlier quoted context omitted.

Everything on the face of the earth falls under philosophy. It's the biggest non-category ever. I'm basically talking about "philosophy" the way the book uses the word. Which in short is just the authors opinionated take on software masquerading as something a bit more "official" then just an opinion. I mean would you call your own opinions on software design a "philosophy"?

Yes probably. The only real difference between an opinion and a philosophy are the number of people that believe it.

You can only have this take if you know absolutely nothing about philosophy.

Re: A Philosophy of Software Design

#35

Post by matheusiacono »

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 premature specialization.

How do we keep a team aware of the forest?

Re: A Philosophy of Software Design

#36

Post by bryanrasmussen »

mparnisari wrote: post #7

His book is awesome! One takeaway I had: code reviews matter. If your code is undergoing review and a reviewer tells you that something is not obvious, don’t argue with them; if a reader thinks it’s not obvious, then it’s not obvious.

>One takeaway I had: code reviews matter. If your code is undergoing review and a reviewer tells you that something is not obvious, don’t argue with them; if a reader thinks it’s not obvious, then it’s not obvious.

ok, what about if you have code and you think this is not obvious because edge case for browser X version Y therefore I will leave a long comment specifying why it is the way it is and when and under what conditions in the future it should be removed - but the reviewer thinks it is obvious and please remove the comment.

As a general rule reviewers concerns should be addressed, but I have had some experiences in which what the reviewer wanted made the code worse, or even would possibly introduce hard to find bugs.

Re: A Philosophy of Software Design

#37

Post by xoac »

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…

You seem to think that this is some sort of battle between the wordcels and the shape rotators or whatever, it's not. Extremely smart people have been in these fields for thousands of years and they didn't think that math and philosophy are opposites or in some tension. Even a cursory familiarity with the history of math and philo will reveal this.

Re: A Philosophy of Software Design

#38

Post by glun »

laurent_du wrote: post #21
mparnisari wrote: post #7

His book is awesome! One takeaway I had: code reviews matter. If your code is undergoing review and a reviewer tells you that something is not obvious, don’t argue with them; if a reader thinks it’s not obvious, then it’s not obvious.

If I ask my kids or my girlfriend to review my code, nothing will be obvious to them. Doesn't mean that my code is the problem. The idea that the reviewer is always right makes no sense.

Your family is not the intended audience for the code. If the reviewer isn’t either, then they have no business reviewing your code.

Re: A Philosophy of Software Design

#39

Post by exclipy »

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]

Rich Hickey is the odd one out. What do you see in someone who shuns static typing? Static typing is the clearest way to reduce complexity.

Re: A Philosophy of Software Design

#40

Post by synthc »

exclipy wrote: post #39
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]

Rich Hickey is the odd one out. What do you see in someone who shuns static typing? Static typing is the clearest way to reduce complexity.

static typing is a way to manage complexity, Rich Hickey is about avoiding complexity
Post reply on HN