Hacker News Reader

Comment by CipherThrowaway | Hacker News Reader

IMO it's not that the simplest solutions are the best but that the "better" complex solutions are not actually available upfront. They can only be made with hard-won domain knowledge. The design policy for lld v1 per this article encoded many assumptions that turned out to be untrue in practice (like the importance of platform independence). If they had been true then the extra complexity might have been worth it. Over time the simpler lld v2 might accrue its own complexity that better reflects learned experience.

Code is a tool for exploring and understanding problems as much as it is about solving them. Sophisticated solutions can't be designed before they are validated.

View on HN

The software engineering field is terrible at handing down domain knowledge.

Part of the problem is that it's next to impossible to separate the facts from the religion in software domain knowledge. Software artifacts are simultaneously art, technology. math and religion.

It's also hard to separate the abstract knowledge that is broadly applicable from its original context where it was hard won: the particular operating systems, toolchains and tech stacks.

Even that knowledge which is separable is mired in the jargon of those systems, so that it looks like it is specific to them. If those systems are long obsolete, then it's easy to dismiss anything that is robed in their jargon as being obsolescent by association.

If civil or electronic engineering were like software, then every five years, someone would be reinventing a class B push-pull emitter follower amplifier output stage, or Pratt truss, under different names.

My thing is I go simple. I'm good, maybe messy. Finally see enough / think I know a good abstraction and pull the trigger and later I find out ... oh man I was wrong. Knowing when you know is the hard part.

I've got some abstractions out there I wrote early on when I didn't think I coded well and they have lived for years and saved tons of time.

Others don't live long :(

https://sandimetz.com/blog/2016/1/20/the-wrong-abstraction

So many times I've taken code that was a mess because someone tried blindly DRY code for the sake of being DRY and rub abstractions on top of it and I've reverted the code back to being simple copypasta and its become so much more clearer and robust. Then you can look at the result and a simple abstraction may pop out which can reduce enough code duplication that the result is satisfactory (it may require a bit more boilerplate in the subclasses or whatever, but nothing likely to be brittle under future fixes).

The nice thing about dealing with an overly-DRY codebase is you can unwind the abstractions.

But an underly-DRY codebase... good luck. Copypasta tends to accumulate minor differences and figuring out if those minor differences matters can become very time consuming.

> Copypasta tends to accumulate minor differences and figuring out if those minor differences matters can become very time consuming.

The DRY version of this is functions/constructors/methods that take a stupid number of parameters, many with unclear purposes.

The DRY version of this is base classes with subclasses that have crazy protected interfaces that violate Liskov all over the place.

I'd rather debug code spaghetti by rearranging copypasta to sort out the simple deltas than try to unwind LSP-violating inheritance spaghetti.

All the libraries I love and use the most have tons of parameters but they are really well documented including their parameters' interactions with each other.

I don't mean well-considered and documented libraries, I mean the thing where someone goes to DRY up a codebase and keeps thinking "oh, if I just add a parameter this function can also handle this one-off case over here..." over, and over, and over, until you've got this function with a name that makes it look straightforward but for some reason it wants three strings, two of which should actually be nulled in most cases (and god help you if you fill in a value when you don't need them), an integer for unclear reasons but it's the same value in every call you can find, and half a dozen booleans that you'll have to go read the source to figure out, because some of them do more than the variable name in the signature implies.

Good intentions at every step, but a Frankenstein's monster of a function (or entire class, sometimes) in the end

It's the DRY equivalent of having 20 slightly-different copypastes all over a codebase.

Ah yes :)

The Django monolith I worked in for some time was like this - 30, 30, 40 parameters on the methods to handle completing a purchase.

If it's unclear, then it's poor code or poor documentation or both. Sane developers will provide a way to obtain default or common configurations rather than forcing you to figure out the 100 different tunable options.

It isn't one sane developer.

It is the aggregation of a dozen different developers each adding a knob to close a ticket/bug over the course of maybe 10 years.

Not-quite right abstraction also can accumulate minor differences where it is forced on use-cases that fit poorly.

It is better to under-abstract and keep some duplication than over-complicate and miss. Complexity snicks up on you (it is a time bomb).

>Copypasta tends to accumulate minor differences and figuring out if those minor differences matters can become very time consuming.

Welcome to the field of genetics.

"Programming as Theory Building by Peter Naur"

https://pages.cs.wisc.edu/~remzi/Naur.pdf

I would say, theory as in "music theory", not as "theory of general relativity".

A person who possesses music theory can explain why they are composing something they way they are, and suggest better notes to someone who is trying to embellish the music with a harmonization or whatever. Just like the people who held the "theory" of the compiler were able to spot better ways of implementing the ideas of the second group without spoiling the design.

Reply on news.ycombinator.com