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

Re: Simple, correct, fast: in that order

#71

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

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 worked. (It was more complex.) The book was about the psychology part: The original programmer says: "How fast does YOUR program process a punched card?". Answer: "About one card per second." "Ah!" said the original programmner, "but MY program processes ten cards per second!"

The outsider said, "Yes, but MY program ACTUALLY WORKS". 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.

Re: Simple, correct, fast: in that order

#72

Post by jstimpfle » Mon, Jul 09, 2018, 2:35 PM UTC

lopatin wrote: post #26

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.

I think it's more in the spirit of the article to say, forget timezones, use UTC millis everywhere. If the server doesn't speak in timezones, then you eliminated all bugs where the server mishandles timezones.

But no, what about UTC leap seconds? Use TAI! :)))

Re: Simple, correct, fast: in that order

#73

Post by d__k » Mon, Jul 09, 2018, 2:35 PM UTC

DannyB2 wrote: post #51

d__k wrote: post #34

Some other formulations: - Occam's razor https://en.wikipedia.org/wiki/Occam%27s_razor - "Simplicity is the ultimate sophistication" (Leonardo da Vinci) - "Less is more" (Mies Van Der Rohe) - "Make everything as simple as possible, but not simpler" (Albert Einstein)

All four of those are great! But if they are wrong, then it is still wrong no matter how simple. Like saying leap years occur every four years. Simple!

The author assumes that simplicity is a prerequisite for correctness which is in general true but it does not say when exactly a simple system is turned into a complex system. I would say that if the complexity of your system is still under control then it is qualified as a simple system.

Re: Simple, correct, fast: in that order

#74

Post by cbsmith » Mon, Jul 09, 2018, 2:35 PM UTC

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.

Noop is pretty simple...

Re: Simple, correct, fast: in that order

#75

Post by newswriter99 » Mon, Jul 09, 2018, 2:36 PM UTC

These are also the attributes that news should follow.

Re: Simple, correct, fast: in that order

#76

Post by rhapsodic » Mon, Jul 09, 2018, 2:36 PM UTC

Sir_Cmpwn wrote: post #55

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.

If you cannot achieve correct without simple, redefine correct.

> If you cannot achieve correct without simple, redefine correct.

More hand-waving.

Re: Simple, correct, fast: in that order

#77

Post by agentultra » Mon, Jul 09, 2018, 2:37 PM UTC

I think this is lacking a definition of simple. And where in the problem space do we desire simplicity? Simple in the implementation (and conversely complex in the interface? ie: C-style libraries?) Or complex in the implementation but simple in the interface? (ie: Haskell/FP style libraries?)

My definition of simple software is software that I can validate the correctness of using only equational reasoning and the mathematical tools used to carry it out without any specialized knowledge or verification systems.

If I have to learn a new way to reason about a software system in order to understand it then it is complex.

A priori any system written in C fails this litmus test: one must understand and identify the many ways that undefined behavior can enter into their program and be leveraged by their compiler. One cannot reason about a local expression in the presence of global effects and unchecked side-effects. And if it is possible to write a correct C program it takes considerable effort and the use of very specialized verification tools.

There are many reasons to prefer C however; if we're willing to live within some tolerance of "correct" and "incorrect" then we can leverage a tool-chain that can produce highly performant code... but then we're forced to restrain ourselves from introducing complexity instead of spending that effort on other things.

Re: Simple, correct, fast: in that order

#78

Post by taneq » Mon, Jul 09, 2018, 2:37 PM UTC

michaelcampbell wrote: post #32

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.

The old yarn I'd heard for years is close to this. Make it work. Make it work right. Make it work fast. In that order. Now it could be argued that "work right" can be read as "make it (work right)", or "(make it work) right", or both, but I think the point of this saying is that the "fast" part should always come later.

Yep, this is the version I heard. I think the distinction between "make it work" and "make it work right" is important, though - where "work" means "solve the problem", and "work right" means "solve the problem in a robust and reliable manner."

If your software doesn't solve the problem, it's useless, no matter how correct or fast it is. Once it solves the problem, then you can work on making it bug free and elegant. Once you're done with that, only then should you look at making it fast.

Note, of course, that "make it fast" refers to gratuitous optimisation. If it's too slow to solve the problem, then it doesn't work, and that needs to be fixed.

A similar adage states the rules of code optimisation:

1) Don't.

2) (For experts only) Do it later.

Re: Simple, correct, fast: in that order

#79

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

ythn wrote: post #50

DannyB2 wrote: post #38

Earlier quoted context omitted.

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.

The simple thing to do then is to call an `isLeapYear` function that abstracts any complexity. Abstraction allows you to hide complexity and make it a simple, reusable part again.

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

Re: Simple, correct, fast: in that order

#80

Post by kyleperik » Mon, Jul 09, 2018, 2:38 PM UTC

Something I would add that helps when writing simple software is testing. You have to close the feedback loop early and often. Until you see what your program does you won't really understand it.

Thinking you understand what you're making before you really know is one of the worst mistakes you can make. It's under that misunderstanding that you'll think you need to add to your program to make it more correct and fast, when really you're over complicating it and making your life worse when you actually need to get it running.

In contrast, when you can run a test as soon as possible, that's where I usually see an alternative way of writing it that may be shorter, more correct or faster

You'll never get to this point of course if it isn't simple in the first place.