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

461–470 of 647 posts

Re: Please do not attempt to simplify this code

#461

Post by xendo »

austincheney wrote: post #457
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.

You are right that they move the complexity somewhere else, but when abstractions are done right, you don't have to worry how they are implemented when you use them. That is huge benefit.

Re: Please do not attempt to simplify this code

#462

Post by F_r_k »

skybrian wrote: post #254
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 don't understand the objection to having more, smaller files, at least in Go where they can all be in the same package. Once two functions are too far apart to be on screen at the same time, jumping back and forth between two functions in the same file doesn't seem any easier than switching between different files. If anything, switching between two different files is easier since they each get an editor tab. On th…

You should learn markers in vim; really useful for jumping between marks in the code

Re: Please do not attempt to simplify this code

#463

Post by starbeast »

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.

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

Re: Please do not attempt to simplify this code

#464

Post by tome »

TeMPOraL wrote: post #353
sridca wrote: post #212

Earlier quoted context omitted.

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…

I've done it frequently myself when I've changed a line that I originally wrote myself in a way that invalidates a comment written directly above.

Re: Please do not attempt to simplify this code

#465

Post by fluffycat »

austincheney wrote: post #457
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.

I believe that premature abstraction is terrible. But in some cases good abstractions may help with handling complexity and may make testing easier. I have a feeling that because authors say that this class should not be changed / refactored, they failed to introduce a good abstraction. This also implies that their tests are inadequate.

Re: Please do not attempt to simplify this code

#467

Post by TeMPOraL »

AstralStorm wrote: post #441
TeMPOraL wrote: post #359

Earlier quoted context omitted.

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.

You could. It is called an automated theorem prover, with the cheap limited version called constraint based programming. Sadly very unavailable for most programming languages. Sometimes writing the proof of why it should be like this is tricky, especially when complexity or performance is involved. (But then the tests are hard too.) Linters are essentially constraint systems for code, but not for the program.

Theorem provers can still only talk about what the code does and whether or not it does it correctly. Specifying why the code is there is an AI-complete problem. Hence, comments.

Re: Please do not attempt to simplify this code

#468

Post by xendo »

jonahx wrote: post #387
Xyik wrote: post #377

Love this thread. I see this a lot, where engineers blindly follow best practices and have urges to re-factor code when its not necessary. Big files are not necessarily bad and I love that a lot of the comments are with me on this. Having to open several tabs and remembering where you are in the stack can be hard once there are more than a couple of frames / function calls in. There is a lot of benefit to keeping log…

> As with all engineering, there are always trade-offs to every decision This is the cliche that needs to be put to rest. Yes, often there are tradeoffs. But just as often one thing is better than another thing, and there is no tradeoff. A worldview in which everything has pros and cons and is ultimately subjective is fertile ground for entrenched habits, because it means never having to admit you're plain wrong, tha…

> everything has pros and cons and is ultimately subjective

That sound's awfully like postmodernism which is terrible everywhere it's applied, not only programming.

Re: Please do not attempt to simplify this code

#469

Post by lmm »

c3534l wrote: post #393
lmm wrote: post #7

Earlier quoted context omitted.

I think it's likely to indicate low quality. Comments are for where the code wasn't clear enough.

This sounds like a self-fulfilling prophesy. If only think comments are for telling you what a line of code does literally, then you're only going to see comments where the code is obscure. If you use it as a form of high-level communication to help the user understand the broader context and reasoning behind code (like at the top of the linked page), then it will be useful because the person writing the comments und…

Code can and should be a form of high-level communication too. In a well-structured program, the high-level code will explain the high-level context, and the low-level detailed code will explain the low-level details.

Re: Please do not attempt to simplify this code

#470

Post by dsirola »

nindalf wrote: post #96
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 spirit of what you're saying. Too often I've seen folks on HN dismiss languages because they didn't have features X or Y, usually with a condescending "maybe this language's creators should read some PL theory". I remember circa 2013 or 2014, it became impossible to read threads related to Go because the entire thread would always be "a Real Language(TM) needs Generics". Look at the success Go has se…

It's part of the Blub Paradox[1]. If you don't know about better things, you won't miss them. But once you do know about more powerful things, it's hard to go back to living without them.

[1] http://paulgraham.com/avg.html

Post reply on HN