Please do not attempt to simplify this code • Hacker News Board

Re: Please do not attempt to simplify this code

#531

Post by tapland » Fri, Dec 28, 2018, 2:02 PM UTC

jml7c5 wrote: post #165

pdkl95 wrote: post #110

Ignoring the initial boilerplate (license, imports) and the request to preserve the verbose ("space shuttle") style, the first line is: // Design: // // [... 4 paragraphs of English prose // explaining goals and intent... ] That's exactly the type of comment that should be at the beginning of most files!

As a novice programmer, I was absolutely stunned that this was not standard practice. A typical source file provides zero context, background on the subject, pointers to reference material/blog posts/books explaining the concepts, information on how it fits into the program's 'bigger picture', or (most importantly) the thought process that resulted in the file (i.e., why the choice was made to do _this_ rather than _…

> unless one is willing to spend hours of archaeological examination

Currently the only person in-office over Christmas on my first software dev job. Debugging a 50k LOC COBOL beast that digs into three other beast programs and ends up in a final 20k LOC uncommented piece where things are supposed to happen and be returned back.

Nothing is commented, the programs are huge and one can only debug one program at a time, requiring me to submit untested changes in one of them to the shared dev environment since I'm making changes in two, before debugging the other program.

If it just said somewhere what half of the stuff is I would save an insane amount of time getting to know the system.

Re: Please do not attempt to simplify this code

#532

Post by AstralStorm » Fri, Dec 28, 2018, 2:08 PM UTC

szemet wrote: post #499

BurningFrog wrote: post #325

Earlier quoted context omitted.

Sure. In sane code the name of the function should describe what they do well enough that you rarely have to click in to learn how they do it. Or something like that...

I have read an extreme counter-opinion in some J or APL article. It said that it is a bad pactice to name small and common functions: The example was maybe the average function - and the reasoning was, if I recall correctly: 1. The defintion is shorter then the name average ;) 2. Every praticioning programmer will recognise the definition as a common idiom 3. From the definition it is immediately clear how corner cas…

Allegedly. And then you suddenly want to write a SIMD version of an average or optimize it... Mass search and replace time? That'd bloat the code a lot.

Common repeated well defined and mostly immutable code is best left as functions. This is why for example in C strcmp exists instead of everyone writing a two-liner - and the specialized variant gives big performance gains.

Re: Please do not attempt to simplify this code

#533

Post by amai » Fri, Dec 28, 2018, 2:10 PM UTC

Isn't this code style just a sign that go is lacking proper exception handling?

Re: Please do not attempt to simplify this code

#534

Post by AstralStorm » Fri, Dec 28, 2018, 2:14 PM UTC

badminton1 wrote: post #230

afarrell wrote: post #42

Earlier quoted context omitted.

> probably a hell of a lot easier to maintain and manage than splitting the logic up among tens or hundreds of files I'm only halfway through John Ousterhout's book Philosophy of Software Design but I think it agrees with you on this -- that smallness-of-file or smallness-of-function is not a target to shoot for because it prevents the things you build from being deep. That you should strive to build modules which ha…

> that smallness-of-file or smallness-of-function is not a target to shoot for I disagree. Unless you are methodical and know what you are doing (like NASA or the authors of Kubernetes), it is hard to create large functions and files by keeping levels of detail consistent and not repeating code. How do you test a function that has 100 unique outcomes? How do you safely maintain it to ensure it won't break? How do you…

Write automated proofs? Probably best but tooling is junk - it's rarely supported.

Constraint or property based tests as opposed to value tests? (That depends on how unique.) Usually the only thing that does unique things is a direct mapping, everything else is either an equation or has other preconditions, postconditions and internal or external properties. It also makes the logic more directly visible and refactoring easier presuming tests are reasonably written.

Ensure coverage with a tool to be sure.

Re: Please do not attempt to simplify this code

#535

Post by the_af » Fri, Dec 28, 2018, 2:16 PM UTC

Dylan16807 wrote: post #218

TeMPOraL wrote: post #111

Earlier quoted context omitted.

> It's certainly not that McDonald's makes better (or "simpler") hamburgers At the risk of derailing the thread, that would be the lesson I wish people would take away from that example. Criticizing fast food like that is dumb signalling IMO; McDonald's!hamburger != homemade!hamburger. It's an entirely different product sharing the same name and some of the ingredients. It tastes different, and has a different form f…

Plenty of places can get me a significantly better burger in under a minute. McDonald's is not high up inside its category .

This is what kills me: McDonald's doesn't even make good burgers for its price range and speed of service. Plenty of competitors where I live make equally mediocre burgers cheaper and faster. Of course, if you wanted to enjoy a good burger you wouldn't go to any of them, McD's included.

It's all about the brand, unfortunately.

Re: Please do not attempt to simplify this code

#536

Post by AstralStorm » Fri, Dec 28, 2018, 2:19 PM UTC

efaref wrote: post #460

thefounder wrote: post #155

Earlier quoted context omitted.

"else/else if" is not used very often in Go.

It's not used very often here, either. Despite their claims at the top of the code of every `if` having a corresponding `else`, there are 140 `if`s, but only 20 `else`s and a mere 5 `else if`s.

Most of the ifs are for early termination. Using an else on one of these is wasteful.

Re: Please do not attempt to simplify this code

#537

Post by liamfd » Fri, Dec 28, 2018, 2:25 PM UTC

garmaine wrote: post #423

hoorayimhelping wrote: post #370

Earlier quoted context omitted.

> Tesler's Law, also known as The Law of Conservation of Complexity, states that for any system there is a certain amount of complexity which cannot be reduced. https://lawsofux.com/teslers-law.html

Cute, but objectively not true.. using the right tool, or right approach can drastically simplify the solution, sometimes even making intractable problems solvable.

>

I take this more to mean that the logic you're trying to implement has a fixed, non-zero level of complexity (sometimes called "essential" or "inherent" complexity), which forms the complexity floor of your application. On top of that, your implementation adds additional complexity (sometimes called "accidental" or "incidental" complexity), which is not-zero but not fixed.

So, my reading is that in saying "every application has an inherent amount of complexity that cannot be removed or hidden", the law is referring to the essential complexity. Meaning, the law says "some of the complexity is unavoidable in every application" vs. "the amount of complexity is fixed in every application". I do think the name of the law is a little weird, as it implies the latter meaning.

Re: Please do not attempt to simplify this code

#538

Post by AstralStorm » Fri, Dec 28, 2018, 2:26 PM UTC

zeroimpl wrote: post #214

adjkant wrote: post #175

Earlier quoted context omitted.

I think your desire is right, but think about this every time you create a file, and how much slower your work would be. The question then becomes: "how much commenting exactly is needed before this becomes more time than the technical debt it creates? I think this type of summary should not be per source file but per package/folder/module/project. A high-level developer overview with sufficient depth will also help…

I think this commenting only makes sense if the design is atypical. Probably 90% of the code I write is following design patterns already used throughout the code base.

Since comnenter announce does not understand what I meant, it does not matter if design is typical. Functionality still has to be described, so the pattern itself buys you nothing on its own. Then the overarching idea and reasoning also has to be described to make it easier for everybody else to understand.

I've met more than one codebase which tried to use a big hammer pattern to open doors. Heavy indirection to do simple things because of design choices, usually caused by a forced framework - instead of easily factorizable simplicity. Patterns should be emergent not forced. Or more specifically, the choice of appropriate pattern should be based on the problem being solved, rarely one pattern can cleanly solve all problems.

Similarity is very seductive but end result is often complex and hard to reason about when followed religiously.

Re: Please do not attempt to simplify this code

#539

Post by starbeast » Fri, Dec 28, 2018, 2:28 PM UTC

garmaine wrote: post #530

starbeast wrote: post #463

Earlier quoted context omitted.

If it was objectively not true, then you could have infinite compression and any program could be reduced to a single bit.

If "conservation of complexity" were universally true then ANY compression would be impossible. This isn't a dichotomy. My point is that there are clear examples of situations where you aren't just pushing complexity around, but actually achieving great simplifications.

>If "conservation of complexity" were universally true then ANY compression would be impossible.

No it wouldn't. The complexity of a pattern can usually be conserved while reducing its length, but for each pattern there is a limit. This is the entire concept behind the Kolmogorov complexity of a system and any patterns that cannot be reduced any further without removing complexity are at their limit already.

This is also related to the idea that you cannot have a universal compression algorithm.

Re: Please do not attempt to simplify this code

#540

Post by chillacy » Fri, Dec 28, 2018, 2:30 PM UTC

AstralStorm wrote: post #436

chillacy wrote: post #302

Earlier quoted context omitted.

In the most ideal way, the complexity becomes the code structure. People can only keep track of 7 or so odd things in working memory at a time, we tackle complexity through chunking (abstraction), so that these new 7 things are in turn each 7 more things which are in turn 7 more things (ideally).

Your code structure is not my memory chunking structure and it will interfere. At a point you run the risk of just overloading memory with way to many names and entities by merciless chunking, not to mention create a file or function maze. Inlining works surprisingly well because you do not have to memorize things and can just read them. Theoretically it is a tooling problem, but nobody wrote a good enough "inline" t…

I'm not sure what to say, just do the right thing and be more practical than dogmatic I guess? There are situations where it's better not to install an abstraction. There are situations where an abstraction fits super well and is well understood by your dev team.