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

Re: Please do not attempt to simplify this code

#351

Post by TimTheTinker » Fri, Dec 28, 2018, 6:42 AM UTC

tobr wrote: post #126

Klathmon wrote: post #66

Earlier quoted context omitted.

Now i'm squarely in frontend web-app development right now which definitely changes things (mainly the complexity is centered around enabling fast changes/additions to the codebase, and not the actual business logic for the most part), but while "deep functionality and small interfaces" sounds good on paper, most of the time giant files with a few functions exported aren't a good way to manage that. Sure, it solves t…

Breaking things down into smaller pieces is good when it’s good... but there are drawbacks that I feel are often ignored. For example, as you say, a small piece of stand alone code implies that someone can do meaningful work on it without understanding the entire context around it. It also implies that it is suitable for reuse. But if it’s both reused liberally and encourages you to keep working on it, it will almost…

> When you break things apart you also fossilize that way of approaching the problem, which often makes it more difficult to see orthogonal approaches and refactor towards them later.

This is particularly true on teams where a significant proportion of the developers is reticent to refactor code as they go. It seems that given a developer with a sub-80th (or so)-percentile propensity to refactor, the more broken up the solution is (into smaller functions, methods, classes, modules, etc.), the less likely that developer will be to refactor the solution when an obviously better approach exists.

Re: Please do not attempt to simplify this code

#352

Post by jonahx » Fri, Dec 28, 2018, 6:43 AM UTC

Good: High-level comments that provide context, history, and motivation for the current design.

Also good: Line comments that explain cryptic details (eg, the semantics behind bit manipulations) or link to things like protocol definitions.

Bad: Line comments that simply repeat what the code does.

Re: Please do not attempt to simplify this code

#353

Post by TeMPOraL » Fri, Dec 28, 2018, 6:45 AM UTC

sridca wrote: post #212

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!

Yea, but watch how soon it becomes outdated as the file changes.

How soon? I've rarely seen it happen in a meaningful way (i.e. other than someone using automated refactoring on some name, and breaking some comment reference that wasn't written in a way the autorefactor tool could read). When it happens and you see it, you should fix it like any other bug.

Key trick is writing comments as close as possible to the code they affect. Then it's hard to miss affected comments if one's not doing a shoddy job.

Re: Please do not attempt to simplify this code

#354

Post by tzjmetron » Fri, Dec 28, 2018, 6:48 AM UTC

The amount of circlejerking in this thread is unbelievable. Go is a horrible language, and if this code were posted anonymously, these same idiots calling it "the jazz music of software development" and "space shuttle style" (copied verbatim from the actual code comments to boot) would be deconstructing and denigrating it to the last fine detail. Hilarious.

Re: Please do not attempt to simplify this code

#355

Post by hellofunk » Fri, Dec 28, 2018, 6:55 AM UTC

jonahx wrote: post #340

boramalper wrote: post #327

> Space shuttle style is meant to ensure that every branch and condition is considered and accounted for… FTFY: …hopefully! Only if they’ve used a language with Algebraic Data Types support, the compiler would enforce that “every branch and condition is considered and accounted for.” The only PL with ADT that I’ve used was Haskell, but I’ve heard that Rust has them too “enums”. People are arguing that “code is what c…

> It’s human eyes that skim through all the cases, and look for a matching branch for every one of them that “ensures.” This a thousand times. The praise in this thread is disturbing. The absurdity of this code is the logical conclusion of ignoring decades of PL advances in favor of Go's "simplicity." When you insist on "space shuttle" era language design, is it any surprise when you're reduced to "space shuttle" era…

You are forgetting the tremendous advantages that Go offers for many projects over alternative languages.

There are no perfect languages, that is certain.

Re: Please do not attempt to simplify this code

#356

Post by peter_retief » Fri, Dec 28, 2018, 6:55 AM UTC

Way easier to maintain code that is verbose, I have never been a fan of abstracting functionality with the purpose of having less code to read

Re: Please do not attempt to simplify this code

#357

Post by fogetti » Fri, Dec 28, 2018, 6:57 AM UTC

TeMPOraL wrote: post #350

fogetti wrote: post #322

Earlier quoted context omitted.

Sure, and then the next day the whole thing is just a long boring text which has no correlation to reality because the business rule changed and the developer next to you refactored the code.

If the developer next to you refactored the code without refactoring the comments, they did a shit job . Period. They need to be told to go back and fix it.

Or maybe the original developer who wrote the code which was so poorly written that it needed 4 paragraphs of explanation did a shitty job. Period. They need to be told to go back and fix it. You see! You argument works both ways, yay!

Re: Please do not attempt to simplify this code

#358

Post by RickS » Fri, Dec 28, 2018, 7:01 AM UTC

jonahx wrote: post #352

Good : High-level comments that provide context, history, and motivation for the current design. Also good : Line comments that explain cryptic details (eg, the semantics behind bit manipulations) or link to things like protocol definitions. Bad : Line comments that simply repeat what the code does.

As a fairly junior programmer, I'll play devil's advocate on the Bad bit – I find that kind of thing very helpful sometimes. Having plain english demarcations for what a piece of logic does – or where in the loop something is – can shave 80% off the time it takes to get reacclimatized when needing to make a quick change. There are moments when I know the conceptual bit that needs changing, and would prefer to hunt it in english rather than spend time translating on the fly.

Re: Please do not attempt to simplify this code

#359

Post by TeMPOraL » Fri, Dec 28, 2018, 7:03 AM UTC

fogetti wrote: post #357

TeMPOraL wrote: post #350

Earlier quoted context omitted.

If the developer next to you refactored the code without refactoring the comments, they did a shit job . Period. They need to be told to go back and fix it.

Or maybe the original developer who wrote the code which was so poorly written that it needed 4 paragraphs of explanation did a shitty job . Period. They need to be told to go back and fix it. You see! You argument works both ways, yay!

Of course it does.

If the comments are completely redundant with the code, they're bad. But you can't express as code why the some code is the way it is, and why it does what it does. After you tried to express in code every important information that's expressible as code, whatever important information remains must go into comments.

Re: Please do not attempt to simplify this code

#360

Post by Ericson2314 » Fri, Dec 28, 2018, 7:06 AM UTC

bb88 wrote: post #132

iamwil wrote: post #104

Earlier quoted context omitted.

Selling a lot of burgers encompasses much more than making good burgers. By the same token, good products entails much more than making a programming language choice. Functional programming, at its heart, is about using self-imposed constraints to avoid certain classes of programming mistakes. If your application domain doesn't have big consequences for these classes of programming mistakes, then it can seem like fun…

> So yes, just because you use a functional programming language won't help you sell your widgets or make a great product. And you can spend lots of time fucking around with it for its own sake and still not sell widgets or make a great product. It comes down to trust. You're either fucking with your code in a powerful programming language that lets you do everything, or your fucking with the language restrictions to…

As a professional Haskell dev, it definitely makes me more productive even discounting the higher quality of the results. Everything the language does for me is something less I have to think about it. And reusable abstractions, surprise, reduces work later making things go faster still.

Hopefully sometime soon I can share an example of this.