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

Re: Simple, correct, fast: in that order

#111

Post by nine_k » Mon, Jul 09, 2018, 2:52 PM UTC

Dylan16807 wrote: post #92

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…

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

This seems to mix correctness and completeness.

A good program does only the correct thing in a particular area. It is known to be reliable in that area, sometimes even formally proved to be so.

Outside that area, an ideal program refuses to work, because it detects that it cannot obtain the correct result. This is normally called "error handling".

There's also some gray area where a program may fail to reliably detect whether it can produce the correct result, given the inputs / environment. A reasonably good program would warn the user about that, though.

A "garbage in, garbage out" program is only acceptable in very narrow set of circumstances (e.g. in cryptography).

Re: Simple, correct, fast: in that order

#112

Post by DannyB2 » Mon, Jul 09, 2018, 2:53 PM UTC

quadcore wrote: post #91

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…

How do you know it was more complex because from what I read it was slower which is different.

It has been too long. The book described both approaches that both programmers used. I simply no longer remember those details. As I recall, the working program, when explained gave you the "Ah Ha!" experience, and thus was simple enough. The focus of the entire book was more about psychology aspects. One chapter was about how programmers come to feel "ownership" of code.

Another thing: what was an entire program back then, is sometimes a mere function, or maybe a class or code library today.

Re: Simple, correct, fast: in that order

#113

Post by hawkice » Mon, Jul 09, 2018, 2:53 PM UTC

tumdum_ wrote: post #17

hawkice wrote: post #6

The simplest code is an empty file. And yet, we live in a world with complex software. There are tradeoffs, but this article doesn't help you make them.

> this article doesn't help you make them Sure it does. It clearly states that sometimes new features or performance optimisations have to be sacrificed to keep the software simple.

That's like saying, sometimes apples are so expensive you can't buy them. Perhaps surprising, if you haven't thought of it, but it is an obviously true statement about all tradeoffs. Sometimes you shouldn't make them. Still doesn't help you figure out when you should.

Re: Simple, correct, fast: in that order

#114

Post by ythn » Mon, Jul 09, 2018, 2:54 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.

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

Re: Simple, correct, fast: in that order

#115

Post by jandrewrogers » Mon, Jul 09, 2018, 2:54 PM UTC

Performance in most non-trivial software, and especially infrastructure software, is architectural. In many cases an architecture that will allow your software to be performant requires a commitment to a very substantial amount of software complexity upfront to ensure adding performance is much simpler (or even possible) later. There are also rarer cases where correctness is not simple, so there is no trivial path between the simple implementation and a rigorously correct one. While "simple" is easier for the software engineer, customers pay for "correct" and "fast".

In my own area of work (database engines), the common mistake is that inexperienced designers do focus on simplicity first, instead of correctness and performance, not understanding that it is at best difficult and sometimes impossible to add correctness and especially performance later. The fast win of "simple" can turn into nearly insurmountable technical debt when you are asked to deliver scale and performance. People often grossly underestimate the minimum amount of initial implementation complexity required for good architecture.

There are many types of software where "simple, correct, fast" is sound advice but it is far from universal.

Re: Simple, correct, fast: in that order

#116

Post by sgt101 » Mon, Jul 09, 2018, 2:54 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…

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

Re: Simple, correct, fast: in that order

#117

Post by kbsletten » Mon, Jul 09, 2018, 2:56 PM UTC

JackFr wrote: post #68

SamuelAdams wrote: post #2

I would argue that correct is more important than simple. Consider timezones: it's simpler to pretend there's 24 time zones, one for each hour. But the correct assertion is there's 37 time zones (as of this writing). So, the simple solution results in a third of your potential user base having issues. Other issues to pick: accessibility, cross-browser compatibility, legacy device compatibility... the list goes on.

> But the correct assertion is there's 37 time zones (as of this writing). So, the simple solution results in a third of your potential user base having issues. That assumes your user base is evenly distributed across time zones. The US has 6 time zones, but if you only handled 4, you'd cover 99.3% of people.

The US has more than 6. There's a big difference between Denver and Phoenix, even though they're both "Mountain Time". Grouping them together would be overly simplistic. Things like "weekdays at 10 A.M." mean different things half the year.

Re: Simple, correct, fast: in that order

#118

Post by Daycrawler2 » Mon, Jul 09, 2018, 2:57 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…

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.

Re: Simple, correct, fast: in that order

#119

Post by DannyB2 » Mon, Jul 09, 2018, 2:57 PM UTC

BlackFly wrote: post #101

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…

How sure are you that a given program is bug free? I feel that only very rarely would I ever assert 100%. In fact, I would generally assert with 100% confidence that there is some overlooked edge case. How many users that bug may affect... well I would generally give that a small percentage, but it still doesn't hit the boolean state of correct. So correctness is generally never satisfied in my mind. At any given mom…

I can not be sure the code was bug free. It was an anecdote in a book, the focus of which was more about the psychology of those who wrote the code. But it worked, and the first program did not work. The non working code's author took pride in the speed of his code.

Re: Simple, correct, fast: in that order

#120

Post by rbonvall » Mon, Jul 09, 2018, 2:59 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.

I know a couple of guys that would probably implement isLeap by checking that the lower two bits of the year are not set, then boast about how fast it was, and finally, when told that the logic was incorrect, push back because the additional checks would make it "slower".

In their minds, when things stop being simple, fast trumps correct.