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

401–410 of 647 posts

Re: Please do not attempt to simplify this code

#401

Post by eecc »

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…

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

Re: Please do not attempt to simplify this code

#402

Post by mdpopescu »

macintux wrote: post #54
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.

It is rare to find code that comprehensively explains (without comments) why it exists, or often more importantly, why some superficially-equivalent code doesn’t exist there. Comments when done correctly are vital.

So are politicians when not lying and well-behaved children.

Correctly done comments are a one in a million thing. In my experience, they are utterly surpassed by "i = i + 1; // increment i" style comments. (Seriously, I'm working on code written by someone who teaches programming and he writes this type of comment.)

Re: Please do not attempt to simplify this code

#403

Post by Cthulhu_ »

qlk1123 wrote: post #204
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 _…

> As a novice programmer, I was absolutely stunned that this was not standard practice. I agree with your point, and I will be benefit from this style if it were the standard, too. But don't you think a good community culture can make people maintain a good git history for this purpose? My daily job is a Linux kernel developer. I found that source codes are only the "What" part, git comments can and should state the…

I think both comments and Git messages will depend on culture; in my local / current software development culture, an emphasis is put on the code being readable enough to be obvious (this isn't true by the way, even if it's good code). Nobody reads comments, nobody reads git history - mostly because they will always be outdated / no longer relevant.

The assumption is that the original author knew what he was doing, and if not, there was a code review and anyone can fix it if they see a problem.

Finally, it's code that probably won't be around anymore five years down the line, so detailed commit messages etc feel like a waste.

(Mind you, I don't agree with the above. At the same time, I don't want to do this type of meaningless throwaway work anymore)

Re: Please do not attempt to simplify this code

#404

Post by kierenj »

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.

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?

Re: Please do not attempt to simplify this code

#405

Post by mdpopescu »

peter_retief wrote: post #356

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

Yes, I too like to send my own electric signals to the parallel port instead of using the print menu from Word. /s

Re: Please do not attempt to simplify this code

#407

Post by iamwil »

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…

Your language example, and the burger example seems flipped. I assume you prefer artisan burgers, which means you like no language restrictions.

Badly chosen restrictions are not good, we can all agree. But what do good restrictions look like? Back in the day, programmers prided themselves on being able to do their own memory management, and bristled at the idea of a compiler or the runtime doing it for them. Now, that's the exception, as most of the time, we don't think about memory management in most languages we program in.

As time marches on, we'll find more of these restrictions that we all eventually agree are good practices, and the next generation of programmers will take it as a given in programming.

As a look beyond functional programming restrictions, I encourage you to check out Peter Alvaro's talk on Distributed Systems. Here, he talks about how queries over distributed systems is really hard to reason about, because time is now relative--there's no central clock to measure time. However, if we restrict ourselves to a language whose queries cannot express negation, a lot of the hard stuff about distributed systems go away.

https://www.youtube.com/watch?v=R2Aa4PivG0g

Re: Please do not attempt to simplify this code

#408

Post by healsjnr1 »

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.

Given where they are, it seems that now the major abstraction they are missing is type safety. Strict types that allowed a monadic structure would simplify this whole mess into a series of maps and folds.

Not only does this add the stricture of a compiler enforcing correct return types for all conditionals, it is also idiomatic of any language that supports this.

Having said all that, changing languages is rarely an option. Maybe this is the best solution given the tool available. If so, it demonstrates that maybe this tool isn't right for this job.

Re: Please do not attempt to simplify this code

#409

Post by joe_momma »

andbberger wrote: post #227
joe_momma wrote: post #150

yesss thought I was the only one that thought this style was a good idea ... Makes my last company look foolish and explains why most of the devs weren't as productive as they could have been.

That sounds like some dangerous over-attribution

Dangerous is not delivering on time because you want the code to be fancier than it should be or needs to be when all you had to do was write it out plainly and leave obvious comments.

Re: Please do not attempt to simplify this code

#410

Post by tonyedgecombe »

Etheryte wrote: post #272
yongjik wrote: post #148

Obviously I'm not the intended audience, but I'm not sure it's wise to have CloudVolumeCreatedForClaimNamespaceTag, CloudVolumeCreatedForClaimNameTag, and CloudVolumeCreatedForVolumeNameTag in the same file. This is almost the worst of both worlds: the trouble of wading through a pile of words, together with the lack of clarity.

While I understand your sentiment, I don't think it's a real issue with pretty much any modern IDE.

I could imagine quickly scrolling and finding yourself editing code in the wrong function.
Post reply on HN