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

Re: Simple, correct, fast: in that order

#171

Post by zzzcpan » Mon, Jul 09, 2018, 3:46 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.

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.

Re: Simple, correct, fast: in that order

#172

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

SuddsMcDuff wrote: post #163

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.

Simplicity is also a transient property.

> Under these conditions it's important that the software be amenable to change.

At the same time, under all conditions, it is important that the software actually works (i.e. correctness), which is why it's more important than simplicity. Irate users who come to us telling us that our program doesn't work will find little comfort as we regale them with how simple it is.

First, make it correct. Then, make it simple. If requirements change what correctness means, then make it correct again, then make it simple again.

Re: Simple, correct, fast: in that order

#173

Post by zzzcpan » Mon, Jul 09, 2018, 3:48 PM UTC

aidenn0 wrote: post #168

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.

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

It never means "correct". Not to mention that 100% correctness is even impossible.

Re: Simple, correct, fast: in that order

#174

Post by cpburns2009 » Mon, Jul 09, 2018, 3:50 PM UTC

mindB wrote: post #127

Interesting that he hit on the top three points in the pony philosophy[1] but in a very different order than they chose. For pony, the order is: 1. Correctness 2. Performance 3. Simplicity 4. Consistency 5. Completeness I think I tend to agree with that order more. While simplicity tends to be helpful with performance and correctness, there are very few cases where you'd sacrifice correctness/performance for simplici…

I think I agree with these points but I have a question. What is "consistency" in this case? The article only says,

> Consistency can be sacrificed for simplicity or performance. Don’t let excessive consistency get in the way of getting stuff done.

I take consistency to mean consistency of results being correct. Wouldn't that make consistency a subset of correctness?

Re: Simple, correct, fast: in that order

#175

Post by kibwen » Mon, Jul 09, 2018, 3:51 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.

> Why do you equate working software with correctness?

Because the original author neglected to provide an adequate definition of correctness, thereby inspiring an epic HN flamewar as people now must run around endlessly debating semantics. :P

Re: Simple, correct, fast: in that order

#176

Post by nickjj » Mon, Jul 09, 2018, 3:52 PM UTC

I wish more people followed those 3 steps for deploying apps.

A lot of people want to jump straight to the auto scaling, self healing, super deluxe cluster + tax edition to handle a billion requests a week before their app even has 1 visitor.

Re: Simple, correct, fast: in that order

#177

Post by p0nce » Mon, Jul 09, 2018, 3:52 PM UTC

quadcore wrote: post #98

I've found that what keeps more programmers from simplicity is that people like things to be in order. Like their desks or their living room. I've found that seemingly messy code that are actually simple perform better than complex supposedly in-order code.

Another problem is reliance on "big" frameworks as if those being big and successful would make your particular application successful. No it's just a bunch of code you don't understand and can't fix.

Re: Simple, correct, fast: in that order

#178

Post by pofilat » Mon, Jul 09, 2018, 3:54 PM UTC

DannyB2 wrote: post #38

martingxx wrote: post #12

Earlier quoted context omitted.

Correctness (and any other kind of change in behaviour) is easier to achieve if things are simple. Changes are not necessarily easy or even possible to make safely if things are correct but not simple. "Simple" is a proxy for "can be changed safely" and so IMO is the most important quality to have.

I think you do whatever it takes to achieve correctness. If simplicity helps achieve correctness, then great. But correctness is not always simple. Most people think there is a leap year every four years. They are wrong.

My calculator watch worked perfectly for 50 years on that "wrong" assumption.

Re: Simple, correct, fast: in that order

#179

Post by jpfr » Mon, Jul 09, 2018, 3:55 PM UTC

kibwen wrote: post #170

jpfr wrote: post #160

Earlier quoted context omitted.

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.

Correctness is achieved by simplicity.

Re: Simple, correct, fast: in that order

#180

Post by mlthoughts2018 » Mon, Jul 09, 2018, 3:56 PM UTC

kibwen wrote: post #128

sgt101 wrote: post #116

Earlier quoted context omitted.

Works today , but tomorrow the complex solution does not do what is needed and presents a barrier to delivering what is needed now. In a static environment you are right, but static environments are vanishingly rare for software, by definition (because with stops after one iteration!)

What is this comment trying to say? That a simple program that doesn't work today is better than a complex program that works today, but that might not work in some nebulous future? Not all complexity is reducible. The point of software is to work correctly, not to satisfy the author's aesthetic notions, which is what most of the modern hype over simplicity boils down to.

I think you missed the parent comment’s point, which is that a highly complex implementation might have problems very similar to overfitting in statistics. Simplicity in some sense means “room to expand to handle future unseen cases.” If an implementation is very complex, chances are it has some assumptions baked in somewhere and when it hits the wrong corner case or a new requirement is added, it manifests not as some mere refactoring annoyance, but as a complete meltdown where the system is revealed to be incapable entirely, and has to undergo major delays due to huge refactoring that can lead to ripple effect problems in other parts of the system.

In that sense, simplicity is like insurance against the future, and so at any given moment you don’t solely care about the system’s total correctness or performance right now but also you care about some diversification benefit of investing in simplicity too.

Very much like how you don’t choose stocks based solely on what will have the highest expected return right now, but instead you also incorporate some notion of risk management when optimizing.