Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Simple, correct, fast: in that order

drewdevault.com

Post reply on HN
Print view View original

231–240 of 349 posts

Re: Simple, correct, fast: in that order

#231

Post by jasode »

Sir_Cmpwn wrote: post #211
jasode wrote: post #193

Earlier quoted context omitted.

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

The event's time has changed, though. The local representation of when it will occur has not changed, but if you set a timer today and they change their timezone tomorrow, the timer will expire at the wrong time. We should store the actual time of an event and update it when the scheduled time changes.

>, the timer will expire at the wrong time.

A countdown timer is a runtime concept.

Storing pure UTC and/or intended_localtime_plus_TZ in the database is a static concept of data-at-rest.

A timespan/timer is a different abstraction than a desired point-in-time.

Depending on the use case, the correct timer/timespan value can be derived from pure UTC (e.g. scientific celestial events) -- or -- user_specified_localtime_plus_TZ (recurring yoga class at 5:30pm every Wednesday, or take medication every morning at 7:00am).

For user calendaring and scheduling of social appointments, storing pure UTC will lead to data loss and errors. Instead of complicated mass updates of millions of db rows, it's much more straightforward to take a stored localtimeTZ, and then calculate an up-to-date UTC time at runtime, and then derive a countdown timer from that. The key insight is that the best time to use UTC is when the users need that timer at runtime -- and not when they store the row in the db.

Re: Simple, correct, fast: in that order

#232

Post by nickpsecurity »

kibwen wrote: post #202
jpfr wrote: post #200

Earlier quoted context omitted.

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

> That's... literally what the author said. Excellent, so we both agree with the author that correctness is the ultimate point and that simplicity is just a useful tool for achieving correctness. :) > Simplicity is a much better goal for the day-to-day work. Because it can be tracked, measured and evaluated for every individual change. How does one purport to measure simplicity?

I was considering ASM's for it:

http://pages.di.unipi.it/boerger/Papers/Methodology/BcsFacs0...

My thinking was like this. The complexity of software is synonmyous with us saying we don't know what it will do on given inputs. As complexity goes up, it gets more unpredictable. That's because of the input ranges, branching, feedback loops, etc. So, a decent measure of complexity might be simplifying all that down to purest form that we can still measure.

The ASM's are a fundamental model of computation basically representing states, transitions, and conditionals making them happen. So, those numbers for individual ASM's and combinations of them might be good indicator of complexity of an algorithm. And note that they can do imperative and functional programming.

What you think of that idea?

Re: Simple, correct, fast: in that order

#233

Post by k__ »

vinceguidry wrote: post #7
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.

Obviously to solve the problem, a certain amount of correctness is implied. But once that threshold is reached, simplicity is a better use of your time. At least, that's the thesis of the article.

True.

The problem is always, how to get enough correctness that your customers are happy, but don't spent too much time on it so that rivals won't overtake you.

Re: Simple, correct, fast: in that order

#234

Post by AstralStorm »

danesparza wrote: post #204
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…

This makes me think of the Donald Knuth quote, "Beware of bugs in the above code; I have only proved it correct, not tried it." More info here: https://en.wikiquote.org/wiki/Donald_Knuth

Which is why we now have automated theorem provers that can refine proofs into programs.

Re: Simple, correct, fast: in that order

#235

Post by mannykannot »

hinkley wrote: post #207
jpfr wrote: post #179

Earlier quoted context omitted.

Correctness is achieved by simplicity.

For every problem there is a solution that is simple, neat - and wrong.

Indeed - for example, you can make things look simple by leaving necessary parts out.

I think, however, that the more important part of this quote are the words 'problem' and 'solution'. Until you have an understanding of the problem that is correct, it is unlikely that you will come to a solution at all. Avoiding the introduction of gratuitous complexity is not necessary to reaching that understanding, but it sure helps.

Re: Simple, correct, fast: in that order

#236

Post by karmakaze »

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…

Depending on interpretion of terms, I'd agree with either simplicity or correctness first. To disambiguate I would say:

  Working, simple, correct, optimized.

Re: Simple, correct, fast: in that order

#237

Post by ginko »

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…

"A program that produces incorrect results twice as fast is infinitely slower."

- John Ousterhout

Re: Simple, correct, fast: in that order

#238

Post by jerf »

bhandziuk wrote: post #224
jerf wrote: post #121

Earlier quoted context omitted.

"without correctness you've got nothing." Sure... but define "correctness". Suppose my manager comes to me with some incredibly complicated problem. It's going to take six months to solve properly. Suppose in the first three weeks I implement a program that is 98% correct, and let's say it can detect the other 2% and kick it out for a human to solve. But it clearly does not fully and correctly eliminate the problem a…

But this is what ddellacosta is saying. I imagine his interpretation of this argument (and I agree) is that 98% correct IS prioritizing correctness. A very fast, simple solution that is 2% correct is an unacceptable balance.

"A very fast, simple solution that is 2% correct is an unacceptable balance."

That begs the question (in the original sense) of "unacceptable". If I banged out that 2% solution in an hour, and it lacked other costs that outweighed the benefits, it may still be something we ship! It is unlikely that we'd stop there, just because the numbers as you've given are unlikely to favor it because something else substantial would have to overcome the small amount of the problem we've solved, but to be firmly confident it's "unacceptable" you'd have to define "acceptable" a lot more carefully.

I understand the deep temptation to turn to discussions of the virtues of letting bugs through or something, but the costs/benefits framework completely handles that already. If you ship a buggy piece of "incorrect" shit, well, you've incurred a ton of costs with no benefits. That's wrong, by whatever standards you are measuring costs and benefits by. There isn't a "what if your 98% solution actually has a massive bug in it because you were unconcerned about 'correctness'?" argument to be made, because if it does have a massive bug, it's not a 98% solution.

Re: Simple, correct, fast: in that order

#239

Post by jsdalton »

I often repurpose a famous quote from Mark Twain (about letter writing) for the topic of simplicity:

> I didn't have time to write a simple program, so I wrote a complicated program instead.

This is in my experience more than just a clever turn of phrase: the vast majority of software projects (or features etc.) move from _simplistic_ to complicated, and rarely from there toward simplicity. The end result is exactly what this author describes -- a complex mess that's difficult to reason about and rarely performant.

Few of us (usually myself included) are willing to devote the time and effort required to achieve true simplicity.

Re: Simple, correct, fast: in that order

#240

Post by fwdpropaganda »

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.

I agree with this.

Interestingly, the post is very simple, and not correct. I prefer posts which are slightly more complex but correct, but those don't get as many upvotes.

Post reply on HN