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

Re: Please do not attempt to simplify this code

#601

Post by james_s_tayler » Sat, Dec 29, 2018, 12:46 AM UTC

nailer wrote: post #597

james_s_tayler wrote: post #519

Earlier quoted context omitted.

Invoke gauge theory to set the floor from which we measure, so that the tautology always holds.

I don't understand what this means.

Well people keep picking arbitrary starting points in the coordinate system. I'm saying for any arbitrarily picked starting point in the coordinate system, the time taken is always twice that of getting from the arbitrarily picked starting point to the halfway mark.

A tautology is a tautology.

How long is a piece of string?

Re: Please do not attempt to simplify this code

#602

Post by AlexCoventry » Sat, Dec 29, 2018, 1:53 AM UTC

mdpopescu wrote: post #402

macintux wrote: post #54

Earlier quoted context omitted.

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

In an actual teaching context, a comment like that can make sense.

Re: Please do not attempt to simplify this code

#603

Post by garmaine » Sat, Dec 29, 2018, 2:14 AM UTC

garmaine wrote: post #528

ozim wrote: post #501

Earlier quoted context omitted.

I don't think downvoting is good way for showing disagreement. I disagree with what you wrote. It does not waste developers time, it wastes money of business owners. Developers are usually paid for their time even if they are reading HN instead of working. Now question is to people who pay money if they want to pay for "something in the future maybe will be useful". They will say hell no! They want time to market to…

Bad advice should be kept highly visible.

Er, "should not".

Re: Please do not attempt to simplify this code

#604

Post by garmaine » Sat, Dec 29, 2018, 2:17 AM UTC

liamfd wrote: post #537

garmaine wrote: post #423

Earlier quoted context omitted.

Cute, but objectively not true.. using the right tool, or right approach can drastically simplify the solution, sometimes even making intractable problems solvable.

> I take this more to mean that the logic you're trying to implement has a fixed, non-zero level of complexity (sometimes called "essential" or "inherent" complexity), which forms the complexity floor of your application. On top of that, your implementation adds additional complexity (sometimes called "accidental" or "incidental" complexity), which is not-zero but not fixed. So, my reading is that in saying "every ap…

What I'm objecting to is the notion that there is a "fixed, non-zero level of complexity." Often real innovations in organization and structure allow for fundamentally simpler implementations. I'm reminded of physics: there's an inherent complexity in solving a rotational problem. But introduce polar coordinates and you fundamentally change the game, removing a dimension from your analysis for some problems, and making the solution trivial.

Re: Please do not attempt to simplify this code

#605

Post by chris_wot » Sat, Dec 29, 2018, 2:27 AM UTC

james_s_tayler wrote: post #260

chris_wot wrote: post #211

Earlier quoted context omitted.

It’s much worse in codebases that predate version control. At least a commit shows the context of why it was added.

Yeah and over the course of 2 or 3 decades of development a lot of software has moved through several different version control,ticketing systems and developers. So you wind up with files stating an author who no longer works there with an email address that the company used 3 acquisitions ago, a ticket number you aren't even sure what system it was for but you just know it isn't being used anymore and source control…

You just described LibreOffice!

Re: Please do not attempt to simplify this code

#606

Post by AlexCoventry » Sat, Dec 29, 2018, 3:49 AM UTC

germainelong wrote: post #170

geofft wrote: post #147

Earlier quoted context omitted.

I think you can syntactically state that anything where the check is on the second return value (which is, by convention, the error return) is a "simple error check", and their rule for if statements is always for things that come from a first return value. For instance, this would not be a simple error check: server, err := find_current_server() if server != nil { ... } because if find_current_server() believes that…

What if the second returned variable is not err, but the code using it assumes it is? (the code breaks the convention) This will not be accounted for. This means with that in mind a lot more discipline must be used to analyse the code that is being used in that module.

Go pretty much assumes decent editor support, which should inform you of the type of err as you use it. It's not perfect, but it hasn't been a problem for me in practice, so far.

Re: Please do not attempt to simplify this code

#607

Post by bb88 » Sat, Dec 29, 2018, 5:29 AM UTC

Tehnix wrote: post #421

bb88 wrote: post #132

Earlier quoted context omitted.

> 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…

> 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 get your code to compile in the first place. > ...or your fucking with the language restrictions to get your code to compile in the first place I think that's a wrong and outdated view on strong type systems. A good type system is also an ergo…

> I think that's a wrong and outdated view on strong type systems.

I wasn't really talking about type systems specifically, I was thinking along the lines of the Rust borrow checker here, and lower level programming like assembly and C.

> A good type system is also an ergonomic one. What people start to experience is that the compiler is actually a friend that helps you write code and keep yourself true to your own promises.

I see a lot of people make the mistake that type safe code is bug free code. "It compiles, therefore ship it."

> It doesn't come down to trust, it comes down to the realization that your mind can keep track of less information than a computer, and that you, as a programmer, are forgetful and make mistakes. The compiler is there to help you when you stumble over your own feet.

You trust the compiler to find bugs. Awesome. Luck be to you. I trust unit tests more than the compiler. Mostly because I wrote them. The compiler, I didn't.

Re: Please do not attempt to simplify this code

#608

Post by firethief » Sat, Dec 29, 2018, 5:47 AM UTC

garmaine wrote: post #604

liamfd wrote: post #537

Earlier quoted context omitted.

> I take this more to mean that the logic you're trying to implement has a fixed, non-zero level of complexity (sometimes called "essential" or "inherent" complexity), which forms the complexity floor of your application. On top of that, your implementation adds additional complexity (sometimes called "accidental" or "incidental" complexity), which is not-zero but not fixed. So, my reading is that in saying "every ap…

What I'm objecting to is the notion that there is a "fixed, non-zero level of complexity." Often real innovations in organization and structure allow for fundamentally simpler implementations. I'm reminded of physics: there's an inherent complexity in solving a rotational problem. But introduce polar coordinates and you fundamentally change the game, removing a dimension from your analysis for some problems, and maki…

In this case your original estimate of the complexity was high due to a choice of coordinates increasing the incidental complexity of the solution

Re: Please do not attempt to simplify this code

#609

Post by lgunsch » Sat, Dec 29, 2018, 6:02 AM UTC

lmm wrote: post #453

beefeater wrote: post #196

Earlier quoted context omitted.

If you need to make sure every condition is handled, write a test for every condition.

Why? That's both more work and more error-prone than just using a language that will ensure it.

If every condition is important to the business, as is implied in this case, it would be very valuable to have tests to cover them.

Re: Please do not attempt to simplify this code

#610

Post by arduanika » Sat, Dec 29, 2018, 6:51 AM UTC

rakoo wrote: post #435

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…

So basically complexity would go in the language

This is a misreading, almost diametric, of what I wrote:

Me: "complexity is not conserved as we choose beween implementations"

You: "So basically complexity is conserved"

Maybe we're getting confused by this word "complexity", so let's break it down into two things: complexity of task handled (COTH) and complexity for programmer (CFP). For a given task of a given complexity, COTH is tautologically the same no matter how you choose to implement. The level of CFP, on the other hand, depends on how you decide to handle complexity. Implementing it in assembly language? High CFP. Implementing it with i/t/e, and commenting loudly your intention to handle all cases? Medium CFP. Enforcing these good, exhaustive standards with the type system? Low CFP. Why does CFP differ? Because the tradeoff matters. In particular, my point was that sum types add a tiny bit of complexity to the language, and remove a TON of complexity from the code. It's not a wash, or even a close contest.

(Notice that I don't make any super-radical suggestions, e.g. that their discipline around mutation/purity should be enforced with types or monads instead of exclamatory comments -- in which case, the CFP added to the language might outweigh the CFP alleviated from the typical file. But my point holds: CFP is not conserved)