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

51–60 of 116 posts

Re: A Philosophy of Software Design

#51

Post by TeMPOraL »

resonious wrote: post #47
codeflo wrote: post #11

Earlier quoted context omitted.

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…

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.

Re: A Philosophy of Software Design

#52

Post by TeMPOraL »

rTX5CMRXIfFG wrote: post #14
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…

That’s because your example, a bat, is a high level of abstraction. If you dig into the cellular level things start becoming very single-purpose, even more so down to the atomic level, and so on. The architecture of recursive composition usually done in building large software was found in nature first.

On the contrary, once you start digging down into details, you'll see living things made of multi-purpose components with fuzzy boundaries, going very much against "single responsibility principle" and the like. That's because evolution isn't like human engineers, who need to walk up and down the abstraction ladder so things they care about fit in their head. Evolution is brute-forcing the problem space, using a greedy optimization algorithm. It doesn't need to remember anything.

Re: A Philosophy of Software Design

#53

Post by TeMPOraL »

a_c wrote: post #46
matheusiacono wrote: post #35

Earlier quoted context omitted.

> 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…

People seem to have an intuitive understanding on what matter the most to a ramen shop. Have ramen, get eaten, happily, in that order. And then we can talk about decor, hygiene, side dishes, etc. It is so muddy when it comes to software. People spend endless energy debating a lightbulb of a ramen shop. "What is your ramen? What is OUR ramen?" is something I try to bring up to the team with varying success. Sometimes…

WRT. the comparison to a ramen shop, it would seem that the "intuitive understanding on what matter the most" is all about the product, and the value and experience it delivers. In software, almost all of the debates are about the process. Code style, culture, CI/CD, code reviews, scrums and scrams... this is all process. The product? I suppose it's kind of a given. Or perhaps just not in power of the programmers to influence enough. IDK. There's some depth to be extracted from your analogy.

Re: A Philosophy of Software Design

#54

Post by daveslash »

ludston wrote: post #12
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.

But don't forget that there are two reasons why something will not be obvious: It may not be obvious because the meaning is obfuscated, or it may not be obvious because it relies on the reader understanding certain ideas, concepts or technologies.

This. I once had a code review with a new hire who couldn't understand a for loop in C#. Something almost as simple as the snippet below. Their resume showed a B.S. in CompSci from a CalState school. But they professed "I never understood loops".

  for(int i = 0; i
I've also been in working environments where management has insisted that the code reviews be moderated by someone who was a mechanical engineer with no code/software training, background, or experience. I didn't particularly enjoy those....

Re: A Philosophy of Software Design

#55

Post by corethree »

ludston wrote: post #42
corethree wrote: post #26

Earlier quoted context omitted.

Right, what about "formal theory"? Let's say number theory? That's a concept independent of belief. And that's the difference I'm getting at here.

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.

That's what I mean by "belief"

Re: A Philosophy of Software Design

#56

Post by corethree »

agent327 wrote: post #45
corethree wrote: post #15

Earlier quoted context omitted.

>Software design, in my opinion, is both a science and an art so my stance is that we need both the formal theory and science as well as the philosophy and that they shouldn't be viewed as mutually exclusive. What formal theory have you ever used for designing your software? I would argue you've never used anything. Every abstraction you've ever made was likely a gut feeling, an instinct or following some vague hand…

Aren't you being overly optimistic about the engineering disciplines' ability to compute things? How does engineering work: do you sit down with a spec (say, "create a wing that can lift a passenger plane"), and then run some formulas, and end up with a wing? Or do you propose a wing, based on past experience (rough shape and size), and _then_ bring in computation to make sure it provides the correct amount of lift,…

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.

Re: A Philosophy of Software Design

#57

Post by corethree »

lvturner wrote: post #31
corethree wrote: post #25

Earlier quoted context omitted.

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…

Sort of but I think you're too limiting on the scope of what theory can do. Usually in engineering you can't just design anything in your imagination. You have a limited set. A domain. Which to continue the theme of the example, I have a set of points. I rarely have all the points on the face of the earth.

How do I pick the point such that it minimizes a specification constraint? Let's say that constraint is the shortest distance. This is design by calculation.

Then design is out of the equation. But if the specification constrains is "The two points most pleasing to the user" Then you can "design" those points.

If I had access to every neuron and had a exact fully realized mathematical model of the general human brain, even this constraint of "pleasing" and "usability", in theory could be met with a calculation.

Largely anything that leans more towards "design" means we don't know shit about what's going on so we hire philosophers and artists to make wild guesses. That is essentially what design is: a wild guess.

The more of software we can model in a theory, the less wild guesses we need.

Re: A Philosophy of Software Design

#58

Post by corethree »

xoac wrote: post #37
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.

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

Yeah it was actually progress when the field largely separated the philosophical mumbo jumbo away from the pure math. In the past math text books were littered with this mumbo jumbo because people couldn't separate the philosophy away from the axiomatic logic. Textbooks were just a mess. Nowadays there's a clear delineation. I believe it was Newton who started this separation trend with his laws of motion.

Mathematics is an entirely separate department that is NOT under philosophy in most schools because of this.

Re: A Philosophy of Software Design

#59

Post by corethree »

auggierose wrote: post #30
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…

That book has its very own philosophy, in particular that "pointfree" (pointless?) programming is a good thing. No, it isn't.

You think it's not good because that's just your particular philosophy.

Pointfree programming allows for theory. It allows for algebraic composition of functions which in turn allows application of algebraic theory.

I mean in the end what is a computer program? A set of functions. Wouldn't you build a program by composing functions together to form bigger functions? It makes sense for this to be the fundamental theory of program organization.

Of course IO and mutation aren't initially included in this theory but that's a different aspect of the theory once you get more advanced.

So basically you're just saying something along the lines that in your opinion you don't like the theory of algebra or geometry or some such. It's not invalid, but like the philosophy book, just another opinionated take.

Re: A Philosophy of Software Design

#60

Post by AnimalMuppet »

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 known) variety of task mixes.

And so on. There are parts of the requirements that are blurry and hand-wavy. That makes the "calculation" approach hard. At least, you have to translate the hand-wavy stuff into precise things that you can calculate. And you can't calculate that translation process, because the inputs are hand-wavy.

Post reply on HN