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

81–90 of 116 posts

Re: A Philosophy of Software Design

#81

Post by nuancebydefault »

corethree wrote: post #56
agent327 wrote: post #45

Earlier quoted context omitted.

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.

> 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 cpu load, hard to reuse...), well that is usually not solved. IMO that matches your point.

Re: A Philosophy of Software Design

#82

Post by codr7 »

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, which is something some people/teams/organizations are better at than others.

Also, some people are better system thinkers than others, usually more experienced. You need someone to understand everything at a deep enough level to be able to teach it on every team.

Re: A Philosophy of Software Design

#83

Post by Chris_Newton »

Ecoste wrote: post #79
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…

> 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. I would argue that such absolutist rules are harmful. Yeah, there certainly are times when smaller functions are better. But there are times where separating a function in…

I would argue that such absolutist rules are harmful.

Indeed. There are millions of us out there developing software for numerous different applications with numerous different trade-offs. “Never say never” is probably good advice here.

I once had a discussion with a prominent member of the ISO C++ standards committee about the idea of labelled break and continue statements of the kind found in various other languages, which let you affect control in an outer loop from within a nested inner one something like this:

    outer_label:
    for (int i = 0; i
They were essentially arguing that such a language feature should not be necessary because you should never need deep nesting of loops in a program with good coding style anyway.

At that time, I was working on code where a recurring need was to match sometimes quite intricate subgraphs within a large graph structure. This is known as the subgraph isomorphism problem¹ and it’s NP-Complete in the general case, so in practice you rely on heuristics to try to do it as quickly as you can.

That’s a fancy way of saying you write lots of deeply nested loops with lots of guard conditions to exit a particular iteration as quickly as possible if it can’t possibly find the pattern you’re looking for. 5–10 levels of indentation in a function to find matches of a particular subgraph were not unusual. Functions at least 50–100 lines long were common and longer was not rare. It probably broke every rule of thumb the advocates of short functions and shallow nesting have ever written.

To this day, I believe it was probably also the most clear, efficient and maintainable way to write those algorithms in C++ at that time. But it would have been clearer with labelled breaks.

¹ https://en.wikipedia.org/wiki/Subgraph_isomorphism_problem

Re: A Philosophy of Software Design

#84

Post by auggierose »

corethree wrote: post #59
auggierose wrote: post #30

Earlier quoted context omitted.

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

There is nothing wrong with functions. But forcing yourself to think exclusively in functions doesn't make much sense, and that is what pointfree is all about. It's basically a fetish. After all, functions have a domain, and the domain consists of objects that are often not functions.

Re: A Philosophy of Software Design

#85

Post by v9v »

simplegeek wrote: post #71
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]

> He taught not just ways to design software, but also ways to live. Mind sharing his insights on ways to live?

Not parent commenter, but I recall seeing this talk of his posted online before: https://gist.github.com/gtallen1187/27a585fcf36d6e657db2

Re: A Philosophy of Software Design

#86

Post by conkeisterdoor »

agumonkey wrote: post #78
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.

good point but it's culture dependent i had people telling me d = {i:str(i) for i in range(10)} was too hard to read, preferring d = {} for i in range(10): d[i] = str(i)

I also strongly prefer the dictionary comprehension and find it much more readable - for whatever my 2c is worth.

Re: A Philosophy of Software Design

#87

Post by ludston »

corethree wrote: post #55
ludston wrote: post #42

Earlier quoted context omitted.

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"

I think I do understand your argument: In your view a formal theory has a level of rigour and evidence that exceeds that of a "best practice" such as SOLID. And I agree with that, but the point is that writing code based on formal theories is still just another software development philosophy with its own set of fuzzy trade offs. For example:

Given ten different calculuses with completely different syntaxes and modes of expression, (for example lamba calculus, combinatory calculus, a Turing machine, a type inference calculus, euclidean geometry, ultrafinitism), each and every one of these ought to be able to express a formal theory that is equivalent. When you are writing software based upon some theory, which calculus will you use to express it? A giant tree of lambdas? A state machine? Pure functions? Mathematically they are all proven to be equivalent so you must make a practical decision based on which one that you believe is best for the job. How will you make that decision? Most likely you will follow some set of personal heuristics that in your experience have shown one form of expression is easier for you than others. And thus you are adopting some philosophy of software even if you try tell yourself that you aren't.

Re: A Philosophy of Software Design

#89

Post by corethree »

ludston wrote: post #87
corethree wrote: post #55

Earlier quoted context omitted.

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"

I think I do understand your argument: In your view a formal theory has a level of rigour and evidence that exceeds that of a "best practice" such as SOLID. And I agree with that, but the point is that writing code based on formal theories is still just another software development philosophy with its own set of fuzzy trade offs. For example: Given ten different calculuses with completely different syntaxes and modes…

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.

Re: A Philosophy of Software Design

#90

Post by corethree »

xoac wrote: post #72
corethree wrote: post #58

Earlier quoted context omitted.

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

I studied philosophy at a department with an analytic slant. So essentially with philosophers who have a hardon for math and science. Still, even there people were not talking nonsense like this. Pure math is really nice, but there are so many aspects of human activity where this math is just totally useless. This is where we have to use the fuzzy words and stuff and where rigorous interpretation that you get trained…

I'm well versed in the "philosophy" of science.

Personally though because philosophy encompasses stuff like animism I don't give the entire field much weight. Aspects of it are interesting but the entire field as a whole is a category error that encompasses everything on the face of the earth. What is not philosophy? I mean it sounds like philosophy is the study of anything and everything.

Anyway to your point physics supposedly is a mathematical model that can model everything down to the tiniest atom. There are holes where not everything can be calculated in a closed form equation and there are holes where the fundamental primitive is true randomness which is something hard to replicate or define.

In this sense physics can model almost (key adjective) everything in the the universe. Including most of all human activity. Because in the end that's of what's going on. Atoms.

Post reply on HN