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

Please do not attempt to simplify this code

github.com

Post reply on HN
Print view View original

451–460 of 647 posts

Re: Please do not attempt to simplify this code

#451

Post by lmm »

nickharr wrote: post #224

Having spent 25+ years writing, viewing, commenting on and reviewing code in a multitude of languages, this is good stuff to see - regardless of the 'style' of programming (or the language broadly-speaking). Stepping back and whilst we can all overlook it, good code comments can make an enormous difference in productivity - both for an individual, a team and indeed a business. It aids repository knowledge (something…

> There are those that believe good code shouldn't need explanation and to some degree that's true, but you can't apply that brush to every codebase. Code can become complex, awkward, spaghetti-like and almost unfathomable at times.

I have yet to find a codebase that couldn't be made clear as soon as a programmer actually put some effort into doing so. Far too often adding a comment is used as an excuse to give up on making the code readable before you've even started.

Re: Please do not attempt to simplify this code

#452

Post by pwm »

karmasimida wrote: post #261
dajonker wrote: post #16

"it became clear that we needed to ensure that every single condition was handled and accounted for in the code" This is a feature of several (mostly functional) programming languages, e.g. Haskell. Fun to see that often people figure out that these types of concepts are a smart way to write your code. Too bad it usually means many people reinvent the wheel instead of learning about computer science history and other…

> This is a feature of several (mostly functional) programming languages, e.g. Haskell I didn't see that. In fact this speaks to me as mission critical software like this needs to be as tediously documented as possible to eliminate surprises. Those branches and conditions are collected through a huge pool of trial-and-errors, implying Haskell can provide those valuable use cases out-of-box is misleading, no it can't.…

I think what the parent comment referred to is that in Haskell if/then/else is an expression (like everything else) so you must by definition have to have an else “branch”. Basically it frees you from a subtle type of error.

Re: Please do not attempt to simplify this code

#453

Post by lmm »

beefeater wrote: post #196
dajonker wrote: post #16

"it became clear that we needed to ensure that every single condition was handled and accounted for in the code" This is a feature of several (mostly functional) programming languages, e.g. Haskell. Fun to see that often people figure out that these types of concepts are a smart way to write your code. Too bad it usually means many people reinvent the wheel instead of learning about computer science history and other…

If you need to make sure every condition is handled, write a test for every condition.

Why? That's both more work and more error-prone than just using a language that will ensure it.

Re: Please do not attempt to simplify this code

#454

Post by lmm »

woolvalley wrote: post #173
thothamon wrote: post #30

This code reminds me of why ML-like languages with Maybe-style types and case expressions that generate compiler errors for missed alternatives are good. I bet rewriting this in OCaml or Haskell would lead to tighter code and might even unearth a couple possible states that haven't been accounted for.

You don't really need functional languages to have those features, as swift, kotlin and others show.

Those languages have all of the ML features; they are functional languages in every reasonable sense, unless you consider "functional" to mean the absence of something.

Re: Please do not attempt to simplify this code

#455

Post by femiagbabiaka »

lmm wrote: post #449
kierenj wrote: post #404

Earlier quoted context omitted.

Would you agree that sometimes, abstractions can just distribute and hide complexity whereby actually all of that context is needed to comprehend the algorithm or process at hand (some things just ARE complex)? In this case right here, what's your counter-example, or what would you use instead of their specific approach?

> Would you agree that sometimes, abstractions can just distribute and hide complexity whereby actually all of that context is needed to comprehend the algorithm or process at hand (some things just ARE complex)? No, or at least not often enough to be worth thinking about. It is of course possible to use abstractions badly, but the problems that business software has to solve are always fairly simple because they're…

Your metaphor doesn’t really apply — this isn’t business software, it’s part of a distributed job scheduler. That is inherently complicated. There is of course an open argument of language choice, but I think there’s something to learn from the lack of software built in $BETTER_LANGUAGE.

It’s also an open source project, so if anyone wanted to throw up a branch with an example of simplification without sacrificing logic branch completeness that door is open. Code might even convince the k8s team to change what you think is misguided behavior.

Re: Please do not attempt to simplify this code

#456

Post by marvin »

munchbunny wrote: post #182
Klathmon wrote: post #21

I love this! It's the "jazz music" of software development. Something which breaks all the "rules" but does so purposefully and explicitly so that it can become better than the "rules" allow. A naive look at this and my head is screaming that this file is way too big, has way too many branches and nested if statements, has a lot of "pointless comments" that just describe what the line or few lines around it is doing,…

I agree. My day job is working on code that isn't this level of critical, but also has the characteristic of being low level, both closer to the metal than typical backend code and also called by so much frontend and backend code that if there was such a thing as "even backend-ier code" this would be a good example. If you miss a nuance, a horde of angry developers will show up at your desk the moment the build deplo…

Well said. I feel that 80% of this thread is people talking past each other, with different assumptions about what the code in question is going to do.

Re: Please do not attempt to simplify this code

#457

Post by austincheney »

spullara wrote: post #400

My take away from reading this code is that it is a huge mess that may be impossible to clean up. At some point they failed to introduce abstractions that would remove the need for all this complexity. They are probably right that now that it works that it will be hard to refactor it without leaving out some critical case. However, I pity anyone that works on this code base.

Abstractions don't remove complexity. Abstractions instead hide the appearance of complexity behind layers of ever increasing code.

Re: Please do not attempt to simplify this code

#458

Post by lmm »

femiagbabiaka wrote: post #455
lmm wrote: post #449

Earlier quoted context omitted.

> Would you agree that sometimes, abstractions can just distribute and hide complexity whereby actually all of that context is needed to comprehend the algorithm or process at hand (some things just ARE complex)? No, or at least not often enough to be worth thinking about. It is of course possible to use abstractions badly, but the problems that business software has to solve are always fairly simple because they're…

Your metaphor doesn’t really apply — this isn’t business software, it’s part of a distributed job scheduler. That is inherently complicated. There is of course an open argument of language choice, but I think there’s something to learn from the lack of software built in $BETTER_LANGUAGE. It’s also an open source project, so if anyone wanted to throw up a branch with an example of simplification without sacrificing lo…

> That is inherently complicated. There is of course an open argument of language choice, but I think there’s something to learn from the lack of software built in $BETTER_LANGUAGE.

Sometimes the best software is no software. Kubernetes exists to solve problems that people using better languages don't generally have.

> It’s also an open source project, so if anyone wanted to throw up a branch with an example of simplification without sacrificing logic branch completeness that door is open.

The "Please do not attempt to simplify this code" comment suggests otherwise. In any case, the team have chosen a language in which good solutions are not possible.

Re: Please do not attempt to simplify this code

#459

Post by Karrot_Kream »

mdpopescu wrote: post #376
Karrot_Kream wrote: post #86

Earlier quoted context omitted.

There's a lot of talk about comments becoming stale and code being self documenting in the replies which makes me wonder: do people genuinely not read comments and just made code changes without updating comments? And do reviewers not look at the context of the surrounding code and just let commits in? What's the point of having code reviews then?

I once spent two hours on figuring out why a log file wasn't being modified when there was an error. I knew the location of the file but it just wasn't showing that error. Eventually I tracked down this line: // writes to the log file at c:\...\xyz.log AppendToLog(message); Yeah, that was the correct path and everything, and yet the line wasn't executing! Eventually I looked inside the AppendToLog method. It was writ…

Can't you modify the comment to improve overall hygiene instead of emerging with code nihilism?

Re: Please do not attempt to simplify this code

#460

Post by efaref »

thefounder wrote: post #155
hueving wrote: post #85

Earlier quoted context omitted.

This is what a lot of Go code looks like. This "space shuttle" code honestly isn't much more verbose than most Go code I interact with. The main difference is they have more comments here.

"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.
Post reply on HN