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

Re: Please do not attempt to simplify this code

#301

Post by k__ » Fri, Dec 28, 2018, 3:52 AM UTC

3pt14159 wrote: post #277

dragonwriter wrote: post #232

Earlier quoted context omitted.

> 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. I kind of see it as the opposite: “space shuttle style” is code that adheres to heavyweight rules that most software development has abandoned in favor of a more improvisational style. But in either case it illustrates that co…

I've had this latent thought for a while that I'm finally putting to words: The complexity goes somewhere. It's either into lots tests, or it's into something like shuttle style with lots of comments, or it's into a huge QA department, or it's into the type system / DB schema. It could even be going into the org structure! But something, somewhere is handling the complexity and it is doing so as a partial function to…

Probably the reason why libraries and frameworks are so omnipresent.

They solve the complexities the average programmer couldn't control on their own.

Re: Please do not attempt to simplify this code

#302

Post by chillacy » Fri, Dec 28, 2018, 3:53 AM UTC

3pt14159 wrote: post #277

dragonwriter wrote: post #232

Earlier quoted context omitted.

> 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. I kind of see it as the opposite: “space shuttle style” is code that adheres to heavyweight rules that most software development has abandoned in favor of a more improvisational style. But in either case it illustrates that co…

I've had this latent thought for a while that I'm finally putting to words: The complexity goes somewhere. It's either into lots tests, or it's into something like shuttle style with lots of comments, or it's into a huge QA department, or it's into the type system / DB schema. It could even be going into the org structure! But something, somewhere is handling the complexity and it is doing so as a partial function to…

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).

Re: Please do not attempt to simplify this code

#303

Post by db48x » Fri, Dec 28, 2018, 3:59 AM UTC

hibikir wrote: post #258

jml7c5 wrote: post #165

Earlier quoted context omitted.

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 _…

There's plenty of good reasons to not write 95% of code with big walls of explanation. The first is a matter of cost: Writing a good explanation around everything is very expensive to do at first. A whole lot of the custom code you find in random companies, from the shiny SV startup to the old enterprise, is unimportant, cobbled together pieces. We have no idea of whether we are writing code that will be thrown away…

Always say Software Archaeology instead; it sounds better.

Re: Please do not attempt to simplify this code

#304

Post by boulos » Fri, Dec 28, 2018, 4:01 AM UTC

thockingoog wrote: post #257

existencebox wrote: post #12

Earlier quoted context omitted.

I think it's situationally useful. If I take the author of the OP code at their word, this is one of those situations. Core, critical plumbing/logic at the kernel of business critical, long-lived applications, will be the source of my stress-dreams long into the twilight years of my life; in the form of a lack of documentation and a presence of organic growth. To criticize myself quite bluntly: If the core code I wor…

As one of the authors of the original code here, this was the result of several days of intense works by a half dozen people working through every corner case we could dream up, and a bunch we thought of on the spot. It is in no way a guarantee that we got them all, but after spending so much time reason in through why those 'else' clauses were correctly empty, we thought it would be rude not to write it down. In tru…

Tim, does someone have a fuzzer running against this? Or even some static analysis ensuring that say the enums from various things are actually handled?

Re: Please do not attempt to simplify this code

#305

Post by BurningFrog » Fri, Dec 28, 2018, 4:01 AM UTC

lliamander wrote: post #256

TeMPOraL wrote: post #94

Earlier quoted context omitted.

I just finished his book yesterday; he has a lot to say about size and comments. For size, your summary is spot-on. I'd only add that he notes overeager splitting of methods and classes makes code involved in a particular abstraction to be no longer in one place, leading developers to constantly jump around files, which makes it more difficult to understand the code and increases the chances of making bugs. As for co…

Martin Fowler of the Agile world, and Garret Smith of the Erlang community, are both excellent programmers whom I respect, and they both take the approach of breaking code into lots of extremely small functions. Having tried that style, I notice that I don't particularly favor it, and for the very reason you site: the code is no longer all in one place. I've switched to moderately sized methods/functions with comment…

I assume everyone who splits code into smaller pieces use modern IDEs that makes it trivial to navigate to functions by clicking them etc.

I say this because I'm always astonished by the number of "modern" programmers who refuse to use IDEs.

Re: Please do not attempt to simplify this code

#306

Post by neeleshs » Fri, Dec 28, 2018, 4:02 AM UTC

root_axis wrote: post #69

endymi0n wrote: post #50

Earlier quoted context omitted.

I know a business coach who regularly asks his audience "Who here makes better burgers than McDonalds?". When half the audience raises their hand, he asks them why they don't outsell this giant company. Functional programming advocats, especially for the "pure" ones like Haskell, always strike me as odd. It seems that all the beauty of those languages make people obsess over that beauty and purity while keeping them…

I agree with the general sentiment of your post, but the idea that Kafka is somehow less painful to operate than Rabbit is ridiculous. I love Kafka, but I can't think of a more painful software to maintain in production.

In my experience, Kafka has been relatively painless. Sure, it needs zookeeper. But zk has turned out to be start it and forget it kind of infrastructure for us.

Re: Please do not attempt to simplify this code

#307

Post by thockingoog » Fri, Dec 28, 2018, 4:03 AM UTC

boulos wrote: post #304

thockingoog wrote: post #257

Earlier quoted context omitted.

As one of the authors of the original code here, this was the result of several days of intense works by a half dozen people working through every corner case we could dream up, and a bunch we thought of on the spot. It is in no way a guarantee that we got them all, but after spending so much time reason in through why those 'else' clauses were correctly empty, we thought it would be rude not to write it down. In tru…

Tim, does someone have a fuzzer running against this? Or even some static analysis ensuring that say the enums from various things are actually handled?

Probably not, in truth. It's a great idea and not just for this code, but lots of tricky stuff.

Re: Please do not attempt to simplify this code

#308

Post by mindcrime » Fri, Dec 28, 2018, 4:04 AM UTC

1. Every 'if' statement has a matching 'else' (exception: simple error

I've always considered this a best practice. There's rarely a good reason not to have a matching else, even if it's no more than a comment reading

// intentional NOP

or

logger.trace( "THING didn't happen, ignoring." );

Either one tells anybody reading the code that the else case was thought about and handled the way it was for a reason.

Re: Please do not attempt to simplify this code

#309

Post by casper345 » Fri, Dec 28, 2018, 4:26 AM UTC

Although I think this is great, this reminds me of a talk Bryan Lunduke did where he says CS/software development is not a profession yet. I love the flexibility software devoplmentgives to every cs, programmer, developer but when you think more about it, that is not the same for other jobs/professions. Professions have standard guideline, procedures to follow. Everyone is doing any language they want, design patterns they just read from a random article, 100s of tutorials on one subject. But are all languages/paradigms/architecture equal? Should there be language only used in some industries to keep consistency? Doctors can't just try a new technique, neither do lawyers. Not saying it is bad, but something I think more thought needs to be put into.

Re: Please do not attempt to simplify this code

#310

Post by bjourne » Fri, Dec 28, 2018, 4:26 AM UTC

marcc wrote: post #124

Dowwie wrote: post #121

Kubernetes, eh? (strikes through its name on my list)

Why? Does this file/comment cause you to lose confidence in the project in some way? I'm genuinely curious to understand the reason for your comment.

Code that "can't be refactored" is a huge smell. This code can be written in a simpler and easier to follow fashion even if the authors of the code were unable to do so. The proof of that is the thousands of free software projects of equal level of complexity whose code bases are a joy to read.