Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Software design gets worse before it gets better

tidyfirst.substack.com

Post reply on HN
Print view View original

131–140 of 145 posts

Re: Software design gets worse before it gets better

#131

Post by rqtwteye »

prerok wrote: post #121
rqtwteye wrote: post #115

Earlier quoted context omitted.

I have concluded that smaller is better and straightforward is better. I think it’s easier to scale up a small system than to maintain a complex system that was built for scale from the ground up but usually got some things wrong because the requirements at the time weren’t clear. But in the end there is never a clear answer. I am happy when people can explain what the positives and also the drawbacks of a design are…

Indeed, could not agree more. Also, using composition over inheritance is age old advice but that still did not prevent those architectural astronauts from creating inheritance structures 15+ levels deep. Luckily, newer languages make constructing such monstrosities harder and discouraged.

"Luckily, newer languages make constructing such monstrosities harder and discouraged."

They just encourage constructing monstrosities of a different kind. I don't think people who do stupid things in one paradigm will do any better in another paradigm. I see that a lot in the microservice vs monolith debate. If you can't manage a monolith you will also screw up microservices.

Re: Software design gets worse before it gets better

#132

Post by magicalhippo »

sylware wrote: post #111
immibis wrote: post #107

Earlier quoted context omitted.

In what way did X11 get worse and worse? It's one of the most stable protocols in use - outliving HTTP, IIRC. It didn't change - our expectations did. Sure, there are incremental improvements to be made, and incremental improvements that have been made, all of which are optional and therefore couldn't have made it worse.

x11 is absurdely gigantic and dirty compared to core wayland. We can implement an alternative of a real-life wayland compositor reasonably. A real-life alternative xserver+window manager is not on the same order of magnitude in terms of work. That reason alone is enough, but if you dig a bit deeper you'll find more reasons to drop x11: you don't need external libs, code is static, x11 bazillion of libs is an abominat…

Sure, X11 was getting long in the tooth and not well fit for the modern desktop.

However, the main problem is that the replacement isn't a replacement. If X11 was a pickup truck, Wayland is a bare engine and transmission package.

Sure it might be a much better engine with cleaner design and has no trouble passing emissions testing, and the transmission has much better efficiency and smoother gear shifts. But if you need a pickup truck then it's just one, albeit important, piece.

By leaving all that extra work up to the individual compositors only reinforces the negative aspects of open source fragmentation.

Re: Software design gets worse before it gets better

#133

Post by Rhapso »

zb3 wrote: post #91
jfoutz wrote: post #76

Earlier quoted context omitted.

You quoted this part, > Take chances, make mistakes, and get messy. But then seemed to indicate evolution disagrees. I might be misunderstanding your point, but it sure seems like, evolution tries a bunch of stuff, and whatever reproduces kinda wins. That seems like, take chances, make mistakes, get messy. That seems like the core of evolution. Could you clarify or refine what you’re saying? The two seem at odds.

So that was a bad quote, I only wanted to address the part that mentioned monotonic-only improvement, since to me, evolution has achieved more than I'd imagine, evolving organs like the eye incrementally. I got inspired by this article: https://writings.stephenwolfram.com/2024/05/why-does-biologi...

Basically, the root disagreement was "monotonic improvement". Evolution is awesome, but it couldn't work with only monotonic improvement.

I used to do an "optimization" on my genetic algorithms. I'd ensure the highest scoring genome of the last population was a member of the new one. It made sure every single generation improved or stood still.

It was a good idea to keep a copy of the "best" genome around for final output, but by keeping it in the search space, I was damaging the ability of the algorithm to do it's job by dragging the search space constantly back to the most recent local optima.

Re: Software design gets worse before it gets better

#134

Post by Rhapso »

corimaith wrote: post #105
Rhapso wrote: post #77

Earlier quoted context omitted.

I think cooperation is never a locally optimal strategy. Somebody allways gets to pick second at the prisoner's dilemma table, and locally optimal behavior is to eat the trusting idiot. Takes a lot of luck to evolve cooperation multiple times at once, much more likely to happen in a situation where the selection pressure is lower, not higher.

Pretty sure those non-cooperative strategies quickly burn themselves to extinction though. The selection pressure itself would be regulated towards an equilibrium. The thing about evolution is that you are sampling many times in different directions. So "luck" isn't that hard to achieve.

> Pretty sure those non-cooperative strategies quickly burn themselves to extinction though.

> Pretty sure those non-cooperative strategies quickly burn themselves to extinction though.

Um, most life hanging out in the same tropic level or lower is heavily predated upon. Competition is the norm.

Luck is hard for cooperation because it is a coordination problem. You basically have to evolve cooperation entirely as a unexpressed trait then trigger it in the population almost simultaneously. The mechanisms of cell cooperation are critical dividers on our evolutionary trees for a reason, they are rare and dramatic in consequence. Cell populations regressing in terms of coordination behavior (see cancer) is one of their most problematic failure modes and it is only very weakly selected against.

Re: Software design gets worse before it gets better

#135

Post by throwAGIway »

prerok wrote: post #129
throwAGIway wrote: post #128

Earlier quoted context omitted.

Just having a huge bikeshedding festival at work after I wrote this sentence into guidelines... The worst thing is how hard it is to talk about it because all the books - by authors making more money from talking about software than from writing and maintaining code - recommend it, and it's just so SOLID and Hexagonal and looks obviously intuitively correct.

Can you elaborate, you have piqued my interest :) The sentence for preferring "composition over inheritance" for code reuse is in the book by the gang of four (the design patterns book). I really don't understand how we ended up in the situation, where 30 years old advice is still valid and still not followed. I lay, perhaps too much, blame on Java, which seems to have this baked into its infrastructure, but similar…

This is exactly the problem - the advice is valid, but the developers can't see their implementation is not, and my examples of maintainable code seemingly go against the advices.

They think their huge class diagrams and statically unverifiable mess of many structurally identical classes (in Typescript) is an example of DRY, composition, separation of concerns, inversion of control and encapsulation - all the great advice neatly packed into 50 files opaquely interconnected through dependency injection containers, where a simple 100 line function would have done the job and wouldn't cause a major headache for the poor guy who has to fix a bug in 3 years.

The root issue is that these guys never were the poor guy who has to fix a bug after 3 years. They moved on after a year or two of "implementing best practice approaches" to the next job.

Re: Software design gets worse before it gets better

#136

Post by m463 »

prerok wrote: post #110
tremon wrote: post #104

Earlier quoted context omitted.

Different engineers can have different interpretations of "right balance" -- and many of them may be correct. Which makes "better" again ambiguous.

I think this is actually addressed in the article: > The key question for the designer is, “What would the system’s structure need to be so that would be no harder to implement than necessary?” (It’s a bit surprising when designers don’t ask this question, instead simply asking, “What should the design look like?”—for what purpose?) During my career, I have been in many situations where the SW architects tried to ans…

> "What would the system’s structure need to be so that would be no harder to implement than necessary?"

This sounds good, but in my direct experience it is really really hard.

For example, sometimes you have a feature that is really easy to add. Just add a new argument or keyword or command and implement it in the guts.

But every once in a while you get a beautiful architecture that has a "direction" to it. And a horrendous requirement comes along and breaks everything. For example, port it to macos. Or add and call this third-party library. Or break it up into an SDK, a CLI and a web service.

sigh. guess that's why this kind of career keeps you on your feet.

Re: Software design gets worse before it gets better

#137

Post by immibis »

sylware wrote: post #124
ahartmetz wrote: post #116

Earlier quoted context omitted.

I'm not sure who you are being sarcastic about in the end, but yes, Wayland is indeed clean and simple enough to not particularly discourage alternative implementations.

Huh. Indeed, we agree. We just need to do the hardest part: keep it clean and simple to not particularly discourage alternative implementations... on the long run.

For example, it's vitally important that wayland resists adding features like title bars, window icons, resize handles, desktop icons, or mouse cursors. These frivolous features have no place in a serious desktop environment! They are only bloat!

Re: Software design gets worse before it gets better

#138

Post by immibis »

sylware wrote: post #127
ahartmetz wrote: post #125

Earlier quoted context omitted.

...while also doing what users want and expect.

... while avoiding their tantrums which will most likely destroy that "clean and simple".

"tantrums" is when you expect windows to be delineated with borders apparently. You got the Wayland attitude down pat: are we the problem? No, it's the users who are wrong!

Re: Software design gets worse before it gets better

#139

Post by immibis »

sylware wrote: post #111
immibis wrote: post #107

Earlier quoted context omitted.

In what way did X11 get worse and worse? It's one of the most stable protocols in use - outliving HTTP, IIRC. It didn't change - our expectations did. Sure, there are incremental improvements to be made, and incremental improvements that have been made, all of which are optional and therefore couldn't have made it worse.

x11 is absurdely gigantic and dirty compared to core wayland. We can implement an alternative of a real-life wayland compositor reasonably. A real-life alternative xserver+window manager is not on the same order of magnitude in terms of work. That reason alone is enough, but if you dig a bit deeper you'll find more reasons to drop x11: you don't need external libs, code is static, x11 bazillion of libs is an abominat…

Huh? You don't need libs to use X11. You can just open a socket and send messages. And thanks to the protocol actually defining most of the message IDs you don't even need as much nonsense. 60% of that "bloat" in X11 is stuff Wayland actually needs, and lacks, making it a failure until it gets them. 75% of the rest isn't harming anyone, besides the trees the extra documentation is printed on.

Have you implemented a Wayland compositor by yourself? Without libs?

Desktop systems having desktop system calls is not "sabotage" any more than Linux having open and close syscalls is "sabotage". At some point you have to draw lines in the sand, and say which stuff is in scope and which stuff is out of scope. A useful API does things, which means there have to things in scope. You can't leave everything as an optional extension unless you are defining some kind of absolutely generic message transport layer with absolutely no semantics (not even message ordering or reliability). Is Wayland a protocol for making GUIs appear on the screen, or a protocol for launching nuclear missiles? Right, so it should have features that are relevant to making GUIs appear on the screen. These are core features. "Make a GUI appear on the screen" is a core feature of Wayland even if you pretend it isn't. By requiring the use of five extensions to do that, you do not make anything simpler or more modular, because they are interdependent. You do not increase compatibility, because now you have effective compatibility profiles based on extension sets that are equivalent to protocol version numbers except you didn't call them that. You just make the compatibility story more complicated for no benefit. Abdication of responsibility for a thing doesn't make that thing unnecessary.

Re: Software design gets worse before it gets better

#140

Post by corimaith »

Rhapso wrote: post #134
corimaith wrote: post #105

Earlier quoted context omitted.

Pretty sure those non-cooperative strategies quickly burn themselves to extinction though. The selection pressure itself would be regulated towards an equilibrium. The thing about evolution is that you are sampling many times in different directions. So "luck" isn't that hard to achieve.

> Pretty sure those non-cooperative strategies quickly burn themselves to extinction though. > Pretty sure those non-cooperative strategies quickly burn themselves to extinction though. Um, most life hanging out in the same tropic level or lower is heavily predated upon. Competition is the norm. Luck is hard for cooperation because it is a coordination problem. You basically have to evolve cooperation entirely as a u…

>Um, most life hanging out in the same tropic level or lower is heavily predated upon. Competition is the norm.

I'm referring to the predator-prey population cycles. If you overexploit your prey you are going to run out of food and see your population thin out rapidly from starvation. Hence hyper-competitive strategies would get outbreeded by less competitive but sustainable strategies.

High predation levels would require equally high cooperation levels amongst prey to ensure rapid reproduction to sustain the food supply. If we go down the food chain it's the same thing, plant life, celluar life, etc, has to be flourishing to sustain the upper levels.

Post reply on HN