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

281–290 of 349 posts

Re: Simple, correct, fast: in that order

#281

Post by mindB »

cpburns2009 wrote: post #174
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?

Pony is a programming language, so I take consistency to be about how consistent the pony programming language feels to the user (principle of least surprise, etc.). That said, I'm not part of the pony core team; if you really want an answer, you could stop by #ponylang on irc and ask.

Re: Simple, correct, fast: in that order

#282

Post by falcolas »

majewsky wrote: post #96
taeric wrote: post #62

Earlier quoted context omitted.

This works for things that have happened. It doesn't work too well for schedules. In those cases, the timezone of the source matters, heavily.

For example, a task that occurs "daily at 15:00" does not always happen every 24 hours. When DST comes into effect, the interval shortens to 23 hours once.

Or, at "2:30 am" in the continental US can occur twice in a day, or not at all. Of course, even that isn't guaranteed, if you're in AZ.

Even "notify me in exactly 24 hours has its own complications. Leap seconds will screw up your day (as will the vague request of "exactly 24 hours").

Corner cases, the bane of simplicity everywhere.

Re: Simple, correct, fast: in that order

#283

Post by [deleted] »

jasode wrote: post #231
Sir_Cmpwn wrote: post #211

Earlier quoted context omitted.

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…

[deleted]

Re: Simple, correct, fast: in that order

#284

Post by cromano »

wellpast wrote: post #251
tacon wrote: post #248

Is the software engineering profession doomed to lose its memory every generation? The premise of this post is ridiculous: >The single most important quality in a piece of software is simplicity. How panglossian, imagining the best of all possible worlds. Well, the world is intrinsically complex, as Fred Brooks explained in his No Silver Bullet essay from 1986[0]. "The complexity of software is an essential property,…

Anyone who has spent any time developing anything but a tiny software system knows that the biggest impediment to productivity (feature delivery, bug fixing, etc) is the complexity of the system at hand. In a sense, this post is simply stating the obvious. The biggest differentiator of skilled software practitioners is the ability to construct simple systems. To call this claim panglossian or meaningless is to hold t…

> The biggest differentiator of skilled software practitioners is the ability to construct simple systems.

I would say it's to construct simple enough systems, and the hallmark of skill is a developer's ability to define enough.

Re: Simple, correct, fast: in that order

#285

Post by falcolas »

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.

> We should store the actual time of an event and update it when the scheduled time changes.

I would love to see some (simple) code which will send a single alert to me at 1:30 am and another at 2:30am. My client registered me as MST (-7) when I set these two alarms in Feburary.

Of particular note for corner cases: Nov 4th and Mar 10, 2019.

The "scheduled time" will change, for many locations, twice yearly.

EDIT: For added fun, instead consider the registration date as May 10th with the same timezone.

Re: Simple, correct, fast: in that order

#286

Post by rhapsodic »

jerf wrote: post #121
ddellacosta wrote: post #64

I can't really understand the equivocating tone a lot of folks are taking in response to this, and more importantly I can't wrap my head around how you could make such a statement in the first place: without correctness you've got nothing. Stating authoritatively that correctness comes after...anything is incomprehensible to me. It's possible to have a correct solution that is neither simple nor fast, and it can be w…

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

>Sure... but define "correctness".

How about this, for example:

The patient lives.

Re: Simple, correct, fast: in that order

#287

Post by l0b0 »

Looks like the point about correctness is misunderstood. The post argues that 1) perfect simplicity, correctness or speed is unachievable in most software of any complexity and 2) given that there is necessarily going to be a trade-off, focusing on simplicity makes the other two easier to solve. There is nothing in there about simply writing `return 1` and considering that the perfect solution.

Re: Simple, correct, fast: in that order

#288

Post by jerf »

rhapsodic wrote: post #286
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…

>Sure... but define "correctness". How about this, for example: The patient lives.

A nice snarky reply.

But I would put $10 down that if I asked you to assert that all medical software in current use that has never killed a patient because of its software issues is therefore "correct", you'd walk back hard. You'd have to be crazy to assert that all such software is "correct".

Unless you are willing to make that assertion, you don't really mean that as a definition.

This is also an example of what I mean in my cousin message about the temptation to turn this into a discussion about attention-grabbing bugs. But my framework already encompasses that. Software that kills patients is software very high on the costs side. There's a complicated discussion to be had about how to exactly quantify probabilities of failure vs. cost, but you can't have that discussion if you're stuck in a "correct or not correct" mindset.

Re: Simple, correct, fast: in that order

#289

Post by red75prime »

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)

I would say that the last one places correctness first.

BTW, the quote is usually attributed to Einstein, but it seems he did't say it.

Re: Simple, correct, fast: in that order

#290

Post by wellpast »

tacon wrote: post #257
wellpast wrote: post #251

Earlier quoted context omitted.

Anyone who has spent any time developing anything but a tiny software system knows that the biggest impediment to productivity (feature delivery, bug fixing, etc) is the complexity of the system at hand. In a sense, this post is simply stating the obvious. The biggest differentiator of skilled software practitioners is the ability to construct simple systems. To call this claim panglossian or meaningless is to hold t…

You are making the common mistake of confounding essential complexity with accidental complexity. One you are stuck managing and one you can eliminate with skill. The world isn't getting less complex just because you work harder on your software.

The world, from software’s perspective at least, isn’t growing in complexity. What leads one to that?
Post reply on HN