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

Re: Simple, correct, fast: in that order

#161

Post by kibwen » Mon, Jul 09, 2018, 3:40 PM UTC

KirinDave wrote: post #153

kibwen wrote: post #136

Earlier quoted context omitted.

If that's the case then the author is attacking a straw man, because nobody (besides Dijkstra) is suggesting that we rewrite all the software in the world in Coq in order to 100% eliminate bugs at the cost of simplicity.

That's not what Coq would do, and a misrepresentation of Dijkstra's position. We certainly could use tools like TLA+ to assist us with existing code. Folks are using "simple" and "easy" interchangeably here. That's probably inappropriate.

I apologize for using Coq speicifically, I just needed a scapegoat for formal verification that people might have actually ever heard of. :P I'm happy to debate definitions, which the author of the OP has regretfully omitted (and the contentious definition here is probably the OP's notion of correctness, rather than their notion of simplicity).

Re: Simple, correct, fast: in that order

#162

Post by DougBTX » Mon, Jul 09, 2018, 3:40 PM UTC

ythn wrote: post #114

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. Not always. Have you ever used a SNES emulator? There is one emulator that is more correct than all others combined - it's called BSNES and it's the most true to the original SNES hardware of all the available emulators. Yet it is horrifically memory/cpu hungry - that correctness comes at a huge cost. So no, correctness does not always come first, especially if you value other things like u…

The follow on from that is “performance is a feature”. If the emulator is supposed to emulate a fun, playable, game, then perf would be a required feature :-)

Re: Simple, correct, fast: in that order

#163

Post by SuddsMcDuff » Mon, Jul 09, 2018, 3:40 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…

The thing is, correctess is often a transient property. Requirements are frequently changing or evolving. What's correct on a Tuesday may no longer be correct by Friday. Under these conditions it's important that the software be amenable to change. It's for that reason I believe simplicity is more important than correctness.

Re: Simple, correct, fast: in that order

#164

Post by KirinDave » Mon, Jul 09, 2018, 3:41 PM UTC

ythn wrote: post #114

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. Not always. Have you ever used a SNES emulator? There is one emulator that is more correct than all others combined - it's called BSNES and it's the most true to the original SNES hardware of all the available emulators. Yet it is horrifically memory/cpu hungry - that correctness comes at a huge cost. So no, correctness does not always come first, especially if you value other things like u…

> So no, correctness does not always come first, especially if you value other things like user experience.

I think you're using a different definition of "correctness" than most other people in this thread. Which is understandable, a lot of folks are using different senses of it. What matters is not, "Does this perfectly and unobservably play hardware" in the definition of correctness for an emulator. What matters is, "Can this emulate the cart I want to play right now with a good experience?" and perhaps, "Will this allow a malware maker to own my entire computer if they run a cleverly crafted fake cart file?"

Re: Simple, correct, fast: in that order

#165

Post by silverbax88 » Mon, Jul 09, 2018, 3:41 PM UTC

Daycrawler2 wrote: post #118

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…

That was my first thought as well but then I realized that by correctness the author means "no bug", which is quite more ambitious than just making it "work". I think the author implicitly assumes the software basically works right from the beginning of the article.

I agree. What he means is, it should work first, as simply as possible. Then you worry about correctness- correctness is not referring to working/no working. Correctness means, 'how SHOULD this work?' or 'How should this logic or code be written to be most efficient or effective?'

Third is performance.

1. Write a working piece of software that does the job.

2. Refactor to make the working piece of software do the job more efficiently and elegantly.

3. Refactor to make the working piece of software do the job as fast as possible.

Re: Simple, correct, fast: in that order

#166

Post by dfxm12 » Mon, Jul 09, 2018, 3:41 PM UTC

"Correct" should, by definition, imply simple and fast. "Simple" tends to be the correct and fastest way to code. Code that runs fast might not be the "simple", but simple code will be the debugged/updated/ported the fastest. I think the author is saying this, but with a more controversial headline (and, intentional or not, controversy creates clicks). After all, this is the premise:

The reason is straightforward: if your solution is not simple, it will not be correct or fast.

This could be reworded in the following ways and the points made in the article would still follow:

If your solution is not correct, it won't be simple or fast. If your solution is not fast, it won't be simple or correct.

Re: Simple, correct, fast: in that order

#167

Post by p0nce » Mon, Jul 09, 2018, 3:41 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…

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

Re: Simple, correct, fast: in that order

#168

Post by aidenn0 » Mon, Jul 09, 2018, 3:42 PM UTC

kibwen wrote: post #144

Dylan16807 wrote: post #92

Earlier quoted context omitted.

> If the program doesn't have to work, I could make it read 100 cards per second. > Correctness comes first. Simplicity is highly desirable, adds additional cost, but always comes after correctness. Correctness isn't binary. Roughly no software today is 100% correct, but for most purposes you'd still pick the current version over a highly complex, slower, more-correct version. Simplicity can save you a lot of cost as…

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.

> Correctness is the destination of any piece of software

"Good enough" is the destination of any piece of software. Sometimes that means correct, but more often it means "oh yeah, sometimes it starts acting funny, just restart it when that happens"

Re: Simple, correct, fast: in that order

#169

Post by [deleted] » Mon, Jul 09, 2018, 3:42 PM UTC

ythn wrote: post #107

DannyB2 wrote: post #79

Earlier quoted context omitted.

But I could write a simpler (incorrect) leap year function than yours!

You missed the point of the article if you interpreted it as correctness being intentionally sacrificed for simplicity. Plus, a complete leap year implementation is already what I would consider simple and most standard libraries already have an implementation for it you can use directly.

[deleted]

Re: Simple, correct, fast: in that order

#170

Post by kibwen » Mon, Jul 09, 2018, 3:43 PM UTC

jpfr wrote: post #160

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…

Your example is a case of premature optimization. That is not what the author is concerned with. The problem are not the programs that obviously do not work or who break in a very visible fashion. Programs whose deficiencies are known can be fixed or worked around. The real problem are programs that appear to work correctly but aren't. To say it with the words of Tony Hoare: There are two ways of constructing a softw…

That quote actually refutes the OP by reinforcing that correctness is more important than simplicity. Achieving correctness is the whole point of making things simple, after all. To put simplicity before correctness would be missing the forest for the trees.