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

431–440 of 647 posts

Re: Please do not attempt to simplify this code

#431

Post by danieldisu »

eecc wrote: post #401
arduanika wrote: post #331

Earlier quoted context omitted.

In this case, the questionable choice of a "something" to handle the complexity is jarringly at odds with the high economic importance that the comments convey. > tests pv_controller.go has 1715 lines. To be generous, we might say half of it is comments. pv_controller_test.go has 359. Hopefully this code is exercised elsewhere in integration tests? > a huge QA department That's what you're signing up for when you cho…

Monadic Try, biased Either, Some, pattern matching and destructuting... you don’t even need to know category theory to use and understand them in code, and you let the compiler do all the tough work. This example - despise the perplexing celebrations - is a product of the limits of Go

Yet you can argue that despite it's limitations they could make working (complex) software with it.

Re: Please do not attempt to simplify this code

#432

Post by eklavya »

bcherny wrote: post #372
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 wonder if it’s not the language that causes the products, but more that programmers that are drawn to functional languages are less likely to care about product. That said, lots of things are functional: chunks of Facebook, Twitter, and Microsoft (and I assume Google) are written in OCaml, Haskell, Reason, and F#. Jet is built in F#. Jane Street famously uses OCaml, and Scala is becoming the standard language for h…

I use functional languages because I care about products. What makes you think otherwise?

Re: Please do not attempt to simplify this code

#433

Post by garmaine »

steinuil wrote: post #415
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…

OCaml is not Haskell, but it does provide almost all of the guarantees Haskell does. Here's a list of popular software you might have used written in OCaml: - the Flow and Hack compilers - Facebook's Messenger app - Jane Street's entire trading infrastructure (and everything else they do) - XenServer - some parts of Docker, including the TCP/IP networking stack on OS X and Windows

Also Pandoc and git-annex are both written in Haskell.

Re: Please do not attempt to simplify this code

#434

Post by reuben364 »

hoorayimhelping wrote: post #370
3pt14159 wrote: post #277

Earlier quoted context omitted.

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…

> 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

That's kind of a truism though. There will always be a non-zero entropy for the distinct kind of systems you want to build.

Unless there is one system to rule them all, configured exactly the way it is needed out the box.

Re: Please do not attempt to simplify this code

#435

Post by rakoo »

arduanika wrote: post #331
3pt14159 wrote: post #277

Earlier quoted context omitted.

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 this case, the questionable choice of a "something" to handle the complexity is jarringly at odds with the high economic importance that the comments convey. > tests pv_controller.go has 1715 lines. To be generous, we might say half of it is comments. pv_controller_test.go has 359. Hopefully this code is exercised elsewhere in integration tests? > a huge QA department That's what you're signing up for when you cho…

So basically complexity would go in the language

Re: Please do not attempt to simplify this code

#436

Post by AstralStorm »

chillacy wrote: post #302
3pt14159 wrote: post #277

Earlier quoted context omitted.

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

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" tool so instead everyone relies on incomplete and buggy textual descriptions.

Re: Please do not attempt to simplify this code

#437

Post by baq »

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 don’t see how your example makes it false.

Re: Please do not attempt to simplify this code

#438

Post by nailer »

james_s_tayler wrote: post #398
hexane360 wrote: post #338

Earlier quoted context omitted.

Hard disagree. You still need to think of the sentence to write the first half.

Beg to differ. I consider the time taken to think and write as the aggregate time to write the sentence.

You've had to think of the design whether you write the sentence or not.

Re: Please do not attempt to simplify this code

#439

Post by hinkley »

yoz-y wrote: post #386

Honestly, to me this looks like normal good code. It reads from top to bottom, exits early, does not have conditions so long that they require lines to be wrapped, it has function that are long or wide but not both... Does not seem to superfluously refactor code into functions called only once. Maybe there are too many comments, but for code that is critical and might be harder to understand at a glance that is bette…

The longest functions don’t follow the same guard clause style as many of the shorter functions and I think that’s a mistake. That half the file avoids else clauses and half don’t tells me there’s an argument here that was never adequately resolved. I think we’re missing about six functions and a couple more refractors, then tone down the a couple parts of the lecture.

As it is it’s obvious that many different hands were in it (and if you look at git blame, one of them doesn’t know how to revert changes properly and needs to stay after school for extra lessons. If this file is so important it shouldn’t have the most critical lines with a “revert changes” comment as the commit message. You done goofed, son.)

Re: Please do not attempt to simplify this code

#440

Post by AstralStorm »

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.

And the 10% is unmaintained.

Design patterns can tap you easily in bad designs. Usually the lost thing is performance, big way, or actual simplicity.

Post reply on HN