5 ms·

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 har

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.

duxup 4y ago
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 :(
- lamontcg 4y ago
  https://sandimetz.com/blog/2016/1/20/the-wrong-abstraction 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).
  - bcrosby95 4y ago
    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.
    - d0mine 4y ago
      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).
    - corrral 4y ago
      > 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.
      - skrtskrt 4y ago
        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.
        corrral 4y ago
        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.
        skrtskrt 4y ago
        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.
hcarvalhoalves 4y ago
"Programming as Theory Building by Peter Naur" https://pages.cs.wisc.edu/~remzi/Naur.pdf https://pages.cs.wisc.edu/~remzi/Naur.pdf
- kazinator 4y ago
  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.
kazinator 4y ago
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.

duxup 4y ago

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 :(

lamontcg 4y ago
https://sandimetz.com/blog/2016/1/20/the-wrong-abstraction 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).
- bcrosby95 4y ago
  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.
  - d0mine 4y ago
    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).
  - corrral 4y ago
    > 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.
    - skrtskrt 4y ago
      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.
      - corrral 4y ago
        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.
        skrtskrt 4y ago
        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.

hcarvalhoalves 4y ago

"Programming as Theory Building by Peter Naur" https://pages.cs.wisc.edu/~remzi/Naur.pdf https://pages.cs.wisc.edu/~remzi/Naur.pdf

kazinator 4y ago
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.

kazinator 4y ago

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.