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

91–100 of 116 posts

Re: A Philosophy of Software Design

#91

Post by corethree »

auggierose wrote: post #84
corethree wrote: post #59

Earlier quoted context omitted.

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.

Well once you introduce points into the theoretical world of functions, composition no longer fully works. It doesn't make sense.

While a program in practice can have "points" an algebra of functions should be a theory like number theory. Number theory deals with numbers only, function theory deals with functions only.

I'm not so strict on this in practice, the function must eventually be called and in the end the compositions converge into a point. But if you want to apply algebraic theory to the functions, they need to be point free.

Re: A Philosophy of Software Design

#92

Post by ludston »

corethree wrote: post #89
ludston wrote: post #87

Earlier quoted context omitted.

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…

> And that part can be "design."

It's those design choices that are subject to all of the dilemmas that necessitate schools of thought such as those in "A Philosophy of Software Design". The mathematics hasn't been invented yet to determined the most efficient way to lay out complex software. And it won't be until long after our jobs are all replaced by fuzzy AI. Until then, software development is a performance art subject to many different schools of thought or philosophies of design, and you're fooling yourself if you think that you can escape from them.

At the end of the day, there is no mathematical formula to choose which color the border of a selected text-input should be: Only conventions, design philosophies, tastes and opinions.

The book you've linked (although I haven't read it all yet), provides a design philosophy for approaching a subset of the problems that computer programmers face. But: It doesn't have any writing on the hardest problems that programmers face in regards to IO and managing persistent state in a concurrent-access environment.

Re: A Philosophy of Software Design

#93

Post by LewisJEllis »

cryptography wrote: post #33
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…

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.

APoSD is a relatively quick high-signal read, and not really a source of additional chaos. You can get through it in a weekend or less.

It mostly gives you vocabulary and labels and explanations for things that you may already intuitively understand, and teaches you to notice small things that matter. It will probably make it easier for you to discuss and dissect some of the chaos you're already dealing with.

Re: A Philosophy of Software Design

#94

Post by nucleardog »

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. It's a complete failure of abstraction.

Can you elaborate on how this is a failure of abstraction? Or maybe what abstraction means to you?

To me, abstraction is about simplify a problem space by making assumptions about the use case.

A hard disk is a bunch of spinning platters that can store 0s and 1s. The drive controller abstracts that by presenting it as if it’s just one continuous stream of 1s and 0s. The operating system abstracts that and presents it as a file system so you can say “shove this data into this name” then later “give me the data in this name”.

The drive controller simplifies the interface by assuming that “where this goes on the platters” doesn’t matter. The operating system simplifies the interface by making many assumptions about where and how we want to organize this data within that stream. This greatly simplifies the use case of… well, basically everything. Except for the things it doesn’t where the abstraction simply no longer works.

All I’ve ever seen “Clean Coder” style short methods do as far as abstraction is reduce it. Instead of a call tree 12 layers deep to finally abstract a problem away as a single operation, people give up halfway through and leave 6 methods that need to be called to do one conceptual thing, meaning the caller needs to understand the underlying implementation/concerns and there’s no longer _any_ abstraction. This isn’t inherent to that approach, but definitely seems encouraged by it.

Shorter methods may (I’d disagree, but understand) help reusability. But whether your `download(string url, string path)` method is a single hundred line method or is composed from parseUrl, resolveDomain, openTcpConnection, sendData, buildHttpRequest, receiveData, receiveHeader, parseHttpResponse, openFile, writeFileData, closeFile, closeTcpConnection… the abstraction is the same if the interface is the same: retrieve a URL over HTTP and write the body to a file. You don’t care about HTTP, sockets, DNS, URL formatting, or anything else.

Re: A Philosophy of Software Design

#95

Post by nucleardog »

tabtab wrote: post #70
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.

Have you read the book? I felt it did that quite well.

The overall pattern really seemed to be “I think we should do X because Y. This falls apart in the face of Z, so don’t do it there.”

That said, it’s been a couple years since I read it so I may be misremembering.

Re: A Philosophy of Software Design

#96

Post by corethree »

ludston wrote: post #92
corethree wrote: post #89

Earlier quoted context omitted.

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…

> And that part can be "design." It's those design choices that are subject to all of the dilemmas that necessitate schools of thought such as those in "A Philosophy of Software Design". The mathematics hasn't been invented yet to determined the most efficient way to lay out complex software. And it won't be until long after our jobs are all replaced by fuzzy AI. Until then, software development is a performance art…

>It's those design choices that are subject to all of the dilemmas that necessitate schools of thought such as those in "A Philosophy of Software Design".

The philosophy of design doesn't talk about theory at all. It is an opinion on the most efficient way to do things not a proof.

If there was a theory, the answer on the "best" way would be a proof. The answer is indisputable given the axioms.

>At the end of the day, there is no mathematical formula to choose which color the border of a selected text-input should be: Only conventions, design philosophies, tastes and opinions.

And that's why the color of the border is not technically part of software engineering. They call that department the art department or the graphic design department. And the people who work this stuff are called "designers"

>The book you've linked (although I haven't read it all yet), provides a design philosophy for approaching a subset of the problems that computer programmers face. But: It doesn't have any writing on the hardest problems that programmers face in regards to IO and managing persistent state in a concurrent-access environment.

No it doesn't provide a philosophy. It provides a theory based on axioms. The choice of the axioms and the resulting theory may be done using "philosophy" but the outcome of that choice is a formal theory.

>The book you've linked (although I haven't read it all yet), provides a design philosophy for approaching a subset of the problems that computer programmers face. But: It doesn't have any writing on the hardest problems that programmers face in regards to IO and managing persistent state in a concurrent-access environment.

There's a short chapter on monads but your right. I never said there's a complete theory and I hinted and mentioned several times in this overall thread that there is no complete theory.

Even the book is incomplete. It's a draft.

Re: A Philosophy of Software Design

#97

Post by auggierose »

corethree wrote: post #91
auggierose wrote: post #84

Earlier quoted context omitted.

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.

Well once you introduce points into the theoretical world of functions, composition no longer fully works. It doesn't make sense. While a program in practice can have "points" an algebra of functions should be a theory like number theory. Number theory deals with numbers only, function theory deals with functions only. I'm not so strict on this in practice, the function must eventually be called and in the end the co…

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.

Re: A Philosophy of Software Design

#98

Post by aryehof »

rzmmm wrote: post #3

I think Ousterhout has interesting approach for software complexity and it's causes. In a nutshell, he suggests it's composed of (cognitive) dependencies between the software components, and obscurity. If anyone has more reading suggestions which have focus on software complexity, I'd like to hear about them.

Perhaps ponder…

“If any part of a system depends on the internals of another part, then complexity increases as the square of the size of the system” — Dan Ingalls

Re: A Philosophy of Software Design

#99

Post by corethree »

auggierose wrote: post #97
corethree wrote: post #91

Earlier quoted context omitted.

Well once you introduce points into the theoretical world of functions, composition no longer fully works. It doesn't make sense. While a program in practice can have "points" an algebra of functions should be a theory like number theory. Number theory deals with numbers only, function theory deals with functions only. I'm not so strict on this in practice, the function must eventually be called and in the end the co…

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 does it make sense to formulate a theory with linked lists and dependency injection as it's core primitives? Then we build everything else in terms of those two concepts? Seems arbitrary. More than likely there are more fundamental building blocks we can use to develop a theory.

If we want to make a theory of computation what is the core primitive that computes? A function. So it makes sense to use this as the core primitive of a theory.

>Number theory is not just numbers, by the way. It has plenty of functions as well, for example the Riemann zeta function.

How should I put this. In number theory you have numbers as an instantiated primitive. Then you have rules on how to compose those numbers to form other numbers. Those rules are called "functions".

If we have a "function theory" on computation. Then the instantiated primitive is a function. Then we need rules on how to compose those functions to form other functions. Those rules are called "functions".

Note the repetition of the two paragraphs above. It might clarify to you what I'm talking about. So in a sense the word "function" in the second paragraph is more Meta... a function of functions.

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

Re: A Philosophy of Software Design

#100

Post by agumonkey »

conkeisterdoor wrote: post #86
agumonkey wrote: post #78

Earlier quoted context omitted.

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.

to me it's even beyond readability, it's a close oneliner scope.. less opportunity to insert some weird statement / bug in it

but anyway, to some senior engineer, the dict comprehension is a chore

Post reply on HN