Simple, correct, fast: in that order • Hacker News Board

Re: Simple, correct, fast: in that order

#191

Post by extralego » Mon, Jul 09, 2018, 4:12 PM UTC

DannyB2 wrote: post #71

When I was in school in the 70's. (That's NINTEEN seventies.) There was this book called The Psychology of Computer Programming. This predates the microcomputer era as we know it. Punched cards were still common when the book was written. A computer was to control a new assembly line for a car company. They couldn't get the software to work. They called in an outside insultant. The outsider developed a program that w…

Does the time it takes to write come into play here at all?

I’m a novice of sorts. Thanks.

Re: Simple, correct, fast: in that order

#192

Post by an_d_rew » Mon, Jul 09, 2018, 4:14 PM UTC

I disagree. Correct, THEN simple, then fast.

Why? Aside from the excellent reasons given by others below, remember that even conceptually simple systems can and often have surprisingly complex behaviours.

The emergent complexity of interacting simple systems is... often breathtaking in the scope of how whacked out the unexpected can be.

tl;dr - "simple" programs do not necessarily have "simple" behaviour or "simple" interactions with other "simple" systems.

Make sure the damn thing works before simplifying it.

Re: Simple, correct, fast: in that order

#193

Post by jasode » Mon, Jul 09, 2018, 4:17 PM UTC

Sir_Cmpwn wrote: post #135

jasode wrote: post #122

Earlier quoted context omitted.

>", you should instead store time in UTC everywhere It is not possible to store UTC unambiguously on the db server for all future local wall-clock times. (Previous comment about the erroneous assumption of "UTC everywhere" being a "simple solution".[1]) Therefore, redefining "correct" to be "store UTC everywhere" achieves the exact opposite: an incorrect and buggy program. That's because the "universal" in Universal…

You're right, future times are more complex and might require more attention to detail. But I think you can still achieve the requirements in a simple way, perhaps by storing it as UTC + lat/long and running a script to update future dates when someone changes their rules.

>a simple way, [...] and running a script to update future dates

I've commented previously that it's not a good idea to change the rows of UTC times in the database.[1]

Designing "system correctness" to depend on on the reliability of a correctly written SQL statements completing atomic transactions for millions of rows is not a good idea. In addition to batch db updates of UTC being extremely fragile, it's also not simple.

(It's fascinating to note that the multiple programmers independently arrive at the approach to update database rows of UTC times. There's something about it that's cognitively satisfying that attracts repeated reinvention.)

[1] https://news.ycombinator.com/item?id=10991894

Re: Simple, correct, fast: in that order

#194

Post by mwkaufma » Mon, Jul 09, 2018, 4:17 PM UTC

OP opines, but cites no evidence, examples, or even anecdotes. If your work is slow and incorrect, your work isn't simple, it's incomplete. Also, some problems are irreducibly complex. Save us from "simple" and "lightweight" "solutions."

Re: Simple, correct, fast: in that order

#195

Post by mooktakim » Mon, Jul 09, 2018, 4:19 PM UTC

DannyB2 wrote: post #71

When I was in school in the 70's. (That's NINTEEN seventies.) There was this book called The Psychology of Computer Programming. This predates the microcomputer era as we know it. Punched cards were still common when the book was written. A computer was to control a new assembly line for a car company. They couldn't get the software to work. They called in an outside insultant. The outsider developed a program that w…

> Correctness comes first. Simplicity is highly desirable, adds additional cost, but always comes after correctness.

Yes, but what is "Correctness". Its not usually so binary. Get to "good enough" and move onto the next thing.

Re: Simple, correct, fast: in that order

#196

Post by zzzcpan » Mon, Jul 09, 2018, 4:19 PM UTC

kibwen wrote: post #190

ptero wrote: post #184

Earlier quoted context omitted.

> Correctness comes first. Simplicity is highly desirable, adds additional cost, but always comes after correctness This may be a matter of definitions. It may be worthwhile distinguish between general correctness and full, as close to 100% provable correctness as you can get. That way allows us to dismiss clearly degenerate cases (you can always do a one-statement no-op program that will be simple but do nothing). G…

> It may be worthwhile distinguish between general correctness and full, as close to 100% provable correctness as you can get. Which is the root of the endless back-and-forth in this thread: a program has to do what it says on the tin ("general correctness") before anything else, and then probably be as simple and as "fully correct" as possible. But it's easier said than done for us to posit a distinction between gen…

There is no line between the two. It's something that depends on how much effort and time is put into this, what methods were used, etc. But, the world doesn't actually care about this specific property, as it has no inherent value. Instead we have various levels of assurance of more practical properties, like safety, but not correctness.

Re: Simple, correct, fast: in that order

#197

Post by [deleted] » Mon, Jul 09, 2018, 4:19 PM UTC

zzzcpan wrote: post #171

kibwen wrote: post #144

Earlier quoted context omitted.

Simplicity (however it is vaguely defined) is desirable, but at the end of the day it is a vehicle for correctness, and hence necessarily subordinate to it. Correctness is the destination of any piece of software (ultimately the goal of any piece of software is to work), and simplicity is just one route to it.

Why do you equate working software with correctness? Software that works is never correct by any definition of correctness. Because working software is a system that exists in the real world and therefore can never have a specification against it.

[deleted]

Re: Simple, correct, fast: in that order

#198

Post by kibwen » Mon, Jul 09, 2018, 4:19 PM UTC

p0nce wrote: post #167

DannyB2 wrote: post #71

When I was in school in the 70's. (That's NINTEEN seventies.) There was this book called The Psychology of Computer Programming. This predates the microcomputer era as we know it. Punched cards were still common when the book was written. A computer was to control a new assembly line for a car company. They couldn't get the software to work. They called in an outside insultant. The outsider developed a program that w…

> Simplicity always comes after correctness. Strong disagreement here. A program that isn't kept simple will stop being correct, fast, or any desirable quality over time.

Nobody's saying that simplicity is unimportant, but if the failure mode of a loss of simplicity is that the program is no longer correct, then it inherently suggests that correctness is the primary metric to strive for. :P

Re: Simple, correct, fast: in that order

#199

Post by asragab » Mon, Jul 09, 2018, 4:21 PM UTC

I think to those that are asserting that correctness comes first are somewhat missing the point. One, a simple solution is still a solution, that is if your code doesn't solve the problem, you can't stop. I think the author is suggesting that truly _correct_ code (code that produces the correct output under all circumstances) is only attainable iteratively, and if your code is not simple (and let's also remember here: that simple ain't easy!) than reaching correctness or performance will, in the main, be quite difficult. Not only will it be increasingly more difficult to reach a state of correctness again after a bug is found, and it will be found, but even measuring performance will become increasingly challenging. At least that's the lesson I take.

Re: Simple, correct, fast: in that order

#200

Post by jpfr » Mon, Jul 09, 2018, 4:22 PM UTC

kibwen wrote: post #186

jpfr wrote: post #179

Earlier quoted context omitted.

Correctness is achieved by simplicity.

> Correctness is achieved by simplicity. That's... literally what I just said? "Achieving correctness is the whole point of making things simple, after all."

That's... literally what the author said.

    If your solution is not simple, it will not be correct or fast.

Correctness may be the end-goal. But correctness is absolute. So it is a bad performance indicator to set as the goal. Yes, we can track bugs. But the absence of open bugs is no guarantee for correctness.

I can never say "We are 5% more correct than last week. Keep up the good work!"

Simplicity is a much better goal for the day-to-day work. Because it can be tracked, measured and evaluated for every individual change.