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

111–120 of 647 posts

Re: Please do not attempt to simplify this code

#111

Post by TeMPOraL »

the_af wrote: post #98
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 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. There is indeed a lesson here, but which one do you think it is? It's certainly not that McDonald's makes better (or "simpler") hamburgers: once you taste good hamburgers you can never go back to McDonald's (and yes…

> It's certainly not that McDonald's makes better (or "simpler") hamburgers

At the risk of derailing the thread, that would be the lesson I wish people would take away from that example.

Criticizing fast food like that is dumb signalling IMO; McDonald's!hamburger != homemade!hamburger. It's an entirely different product sharing the same name and some of the ingredients. It tastes different, and has a different form factor. People like this, even if many don't want to admit it to others (or themselves). When I go for a McD's hamburger instead of a foodtruck one, or when I say I prefer chain restaurant pizza over a home made one, it's because I want a different product. Treating the two as the same category is like treating tea and coffee as the same thing.

Re: Please do not attempt to simplify this code

#112

Post by endymi0n »

gizmo686 wrote: post #107
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…

If you a proffesional chef, I would hope you are fammilar with other methods of producing burgerz than McDonalds, even if they don't sell as well. Haskell is a highly opinionated reasearch language. This makes it a great languages to talk about. People could make many of the same points with, say Scala or Ocaml, but because those languages arent as opinionated, it is harder to use them as a basis for discussion than…

With all due respect, I wouldn't consider Golang any less opinionated than Haskell, just into a completely different direction. Whether or not that's a good thing: I don't know.

Re: Please do not attempt to simplify this code

#113

Post by TeMPOraL »

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!

Strongly agreed. Wrt. comments, the more I read this file, the more I see it as a reference of how good code should look like.

Re: Please do not attempt to simplify this code

#114

Post by mannykannot »

bdibs wrote: post #10
startupdiscuss wrote: post #3

The comment:code ratio is higher than anything I write or that I’ve seen. However, it does give me some comfort. When it’s not gamed, do other HNers also feel that a high comment:code ratio probably indicates quality? There are reasons why this may be the case. (More thought, more time and a large team etc) I don’t advocate using this measure to reward anyone because it would be gamed immediately.

I actually would say it’s almost the opposite, if you’re writing clean, expressive code it shouldn’t need explaining. And if your code is clean, you shouldn’t have a bunch of redundant comments explaining the obvious.

Well, let's consider an example from this very code:

  // The binding is two-step process. PV.Spec.ClaimRef is modified first and
  // PVC.Spec.VolumeName second. At any point of this transaction, the PV or PVC
  // can be modified by user or other controller or completely deleted. Also,
  // two (or more) controllers may try to bind different volumes to different
  // claims at the same time. The controller must recover from any conflicts
  // that may arise from these conditions.
How would you rewrite the code so that this information was explicit in the code alone, and as obvious as when it is stated in these comments? Note that simply being able to handle any conflicts that may arise from these conditions is not necessarily the same as saying that they can occur and must be handled, as any particular implementation is invariably an over-specification.

As for redundant comments explaining the obvious, that seems to be something of a straw man, at least in my experience - personally, I have very rarely seen such code. The person who is not motivated to write useful comments apparently prefers to write no comments rather than useless ones.

Re: Please do not attempt to simplify this code

#115

Post by geofft »

kraftman wrote: post #101
geofft wrote: post #55

Earlier quoted context omitted.

How do you successfully express "We need to treat all transactions on February 29 as happening on February 28, see customer ticket #4321 for rationale" in code?

By naming as much as possible. I'd need to know the rationale in the ticket to be able to try and codify it, but here's how I'd try and do the rest: https://codepen.io/anon/pen/Jwyzdv

I'm not sure that reducing the comments-to-code ratio by increasing the complexity of the code really helps anything. You've made the code more generic for what you currently think future changes are going to look like, which may or may not be accurate. And in the process you've split dateIsOnLeapDay and convertLeapDayToPreviousDay into separate functions, so if someone is tracking down a bug in line 10, they need to jump to lines 20 and 21 to figure out that the associated code is in line 15 (think "wait, did you say leap day? I meant leap second"). In a large program these would get even further separated over time - someone is going to decide that dateIsOnLeapDay should be in a common utils class because they want to use it somewhere else - and I think there's a lot of merit in keeping lines 4 and 5 next to each other.

Re: Please do not attempt to simplify this code

#116

Post by coldtea »

endymi0n wrote: post #50
dajonker wrote: post #16

"it became clear that we needed to ensure that every single condition was handled and accounted for in the code" This is a feature of several (mostly functional) programming languages, e.g. Haskell. Fun to see that often people figure out that these types of concepts are a smart way to write your code. Too bad it usually means many people reinvent the wheel instead of learning about computer science history and other…

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…

>But the closest I ever came to using a functionally developed product was RabbitMQ (written in Erlang). That one was _such_ a pain to use and operate — must have been the developers still dreaming in the purity of its code instead of writing some installation docs. I moved on to Kafka later and didn't regret it a minute.

Err, RabbitMQ is one of the easiest to setup and stabler queues/messaging systems. And I'm no user/fan of Erlang...

Re: Please do not attempt to simplify this code

#117

Post by iainmerrick »

This looks like pretty normal code. What is all the “space shuttle” stuff about?

The only unusual things I see are a) 8-space indentation, b) lots of “if err { return nil }”, and c) lots of comments.

Aren’t a) and b) standard for Go? How else is it possible to write Go code?

With less verbose error handling and 2- or 4- space indentation it wouldn’t look especially “branchy”.

Re: Please do not attempt to simplify this code

#118

Post by steveklabnik »

geofft wrote: post #99
almost_usual wrote: post #20

Earlier quoted context omitted.

Better to make blindly throwing exceptions impossible.

A good alternative is language-level support for returning early from a function with an error. Off the top of my head, both Rust and Haskell have good support for this. (I'm sure there are others, these are just the ones I know.) Rust has a macro try!(x) that takes a Result - a two-variant type, either a successful result of type T or an error of type E - and translates it to, if x is the first variant, evaluate the…

You missed the E in Result, by the way.

Re: Please do not attempt to simplify this code

#119

Post by coldtea »

TeMPOraL wrote: post #111
the_af wrote: post #98

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. There is indeed a lesson here, but which one do you think it is? It's certainly not that McDonald's makes better (or "simpler") hamburgers: once you taste good hamburgers you can never go back to McDonald's (and yes…

> It's certainly not that McDonald's makes better (or "simpler") hamburgers At the risk of derailing the thread, that would be the lesson I wish people would take away from that example. Criticizing fast food like that is dumb signalling IMO; McDonald's!hamburger != homemade!hamburger. It's an entirely different product sharing the same name and some of the ingredients. It tastes different, and has a different form f…

>People like this, even if many don't want to admit it to others (or themselves)

People only like the cheapness and the convenience (and perhaps the no-surprise factor).

Everything else being the same (price and time to prepare), nobody would eat McDonalds vs a quality burger (except the kind of people who eat Hot Pockets for the taste, but that's a much smaller demographic than McDonalds buyers).

Post reply on HN