Is there a drm-free ebook to buy somewhere? Someone mentioned in a recent HN thread thatthe Calibre plugin to read Kindle books no longer works, so not sure I want to buy the Kindle version right now.
A Philosophy of Software Design
41–50 of 116 posts
Re: A Philosophy of Software Design
#42Earlier quoted context omitted.
Yes probably. The only real difference between an opinion and a philosophy are the number of people that believe it.
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.
Re: A Philosophy of Software Design
#43I 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.
Thinking Forth.
Re: A Philosophy of Software Design
#44Earlier quoted context omitted.
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.
Ad hominem and an argument from authority in one breath. Or to summarize: Irrelevant.
Re: A Philosophy of Software Design
#45Earlier quoted context omitted.
Do the business requirements (fundamental assumptions around design to be more generic) of a bridge, car or airliner change dramatically over time? I'd argue not. 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.
>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, iterating through designs as you go?
Because I think it's really the last one. There is no formula to design a bridge: you design the bridge, and then use formulas and lookup tables to validate it is strong enough. Same for pretty much anything else produced by any engineering discipline.
So in that sense, engineering and programming aren't all that far apart: both start from past experience, and use various validation methods after a design has been proposed, iterating through designs to reach an optimal state. Software engineering, being a younger discipline, is still working on validation methods, and many practitioners find they simply have no budget to apply them (nor any life-or-death constraints that force them to). That's ok though. If you design a new can opener you aren't going through all the processes that apply to an airliner either.
Re: A Philosophy of Software Design
#46Haven'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…
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 it is more effective just telling people what to do. If we see people as code, then some of them are of single responsibility with simple interface. It really depends what kind of a team we want.
Re: A Philosophy of Software Design
#47[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…
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.
Re: A Philosophy of Software Design
#48Earlier quoted context omitted.
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
But there's no way to completely avoid complexity.
So tools to manage complexity are welcome in my toolbox.
Re: A Philosophy of Software Design
#49Earlier 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.
[deleted]
Re: A Philosophy of Software Design
#50Is there a drm-free ebook to buy somewhere? Someone mentioned in a recent HN thread thatthe Calibre plugin to read Kindle books no longer works, so not sure I want to buy the Kindle version right now.
No, but you can find the first edition online, and the new chapters of the second edition are available for free via TFA.
There’s also a DRM-free German translation of the second edition from O'Reilly.