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

151–160 of 349 posts

Re: Simple, correct, fast: in that order

#151

Post by masklinn »

Sir_Cmpwn wrote: post #135
jasode wrote: post #122

Earlier quoted context omitted.

>", you should instead store time in UTC everywhere It is not possible to store UTC unambiguously on the db server for all future local wall-clock times. (Previous comment about the erroneous assumption of "UTC everywhere" being a "simple solution".[1]) Therefore, redefining "correct" to be "store UTC everywhere" achieves the exact opposite: an incorrect and buggy program. That's because the "universal" in Universal…

You're right, future times are more complex and might require more attention to detail. But I think you can still achieve the requirements in a simple way, perhaps by storing it as UTC + lat/long and running a script to update future dates when someone changes their rules.

> But I think you can still achieve the requirements in a simple way, perhaps by storing it as UTC + lat/long and running a script to update future dates when someone changes their rules.

Congratulation, your emotional refusal to deal with zoned datetimes has led you to a non-standard ad-hoc reinvention of timezones, your misguided quest for simplicity and obstinate rejection of reality has thus led you to a system which is definitely more complex, probably less correct and likely less performant than if you'd just done the right thing in the first place.

Re: Simple, correct, fast: in that order

#152

Post by rhapsodic »

Sir_Cmpwn wrote: post #94
rhapsodic wrote: post #76

Earlier quoted context omitted.

> If you cannot achieve correct without simple, redefine correct. More hand-waving.

I disagree. I just can't get more specific without specific cases to examine. Like others have pointed out, take the matter of timezones: if "correct" is defined as "handling timezones", you should instead store time in UTC everywhere and redefine "correct" to be "convert times to local time when displayed and back again when input", which can be accomplished with much smaller, simpler, and focused tools.

>I disagree. I just can't get more specific without specific cases to examine.

You should probably mention somewhere that you're the author of the blog post under discussion. And it looks like you're going to make a reputation for yourself as the guy who argues that it's more important for software to be simple than for it to function correctly.

Good luck with that.

Re: Simple, correct, fast: in that order

#153

Post by KirinDave »

kibwen wrote: post #136
Daycrawler2 wrote: post #118

Earlier quoted context omitted.

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.

If that's the case then the author is attacking a straw man, because nobody (besides Dijkstra) is suggesting that we rewrite all the software in the world in Coq in order to 100% eliminate bugs at the cost of simplicity.

That's not what Coq would do, and a misrepresentation of Dijkstra's position. We certainly could use tools like TLA+ to assist us with existing code.

Folks are using "simple" and "easy" interchangeably here. That's probably inappropriate.

Re: Simple, correct, fast: in that order

#154

Post by yen223 »

wellpast wrote: post #61

This is great, but completely lost on the crowd if what Simple means isn't understood. One of the best clarifications of what it means to be Simple, to put it out there, is [1]; but the key point: Simple != Easy. Simple means minimal coupling, high-cohesion etc etc. Yet IME many developers do not understand the distinction and mistakenly believe that easy is the same as simple, and are willing to couple the hell out…

That talk transformed the way I think about software development. I highly recommend watching it.

Re: Simple, correct, fast: in that order

#155

Post by peterwwillis »

What's the right way to cut a bagel?

The obvious solution: Grab a knife, put the bagel on end, and get to slicing.

The commercial solution: Flat and flip. https://www.epicurious.com/expert-advice/best-way-to-cut-a-b...

The mathematician's solution: A Möbius bagel. https://www.youtube.com/watch?v=Ktfo8D3cCr0

The engineer's solution: The bagel jig. http://www.freepatentsonline.com/5228668.pdf http://www.freepatentsonline.com/3347296.pdf http://www.freepatentsonline.com/4807505.pdf http://www.freepatentsonline.com/4747331.pdf

The consumer solution: The bagel guillotine. https://www.surlatable.com/product/PRO-1036557/Sur+La+Table+...

Which is the correct solution? Depends on who you are.

Re: Simple, correct, fast: in that order

#156

Post by dredmorbius »

Some years ago I tracked down the origins of the phrase "complexity is the enemy", and learned three things:

1. The full phase is "complexity is the enemy of reliability".

2. It dates not to the 1980s or 11970s as I'd thought, but the 1950s.

3. It first appeared in print in The Economist newspaper, 18 January 1958, according to Google Books & Ngram viewer.

I'd very much like to have a copy of the article, though its proved resistant to obtaining. HN username at protonmail.com should anyone happen to have access to a PDF.

http://books.google.com/books?id=aDsiAQAAMAAJ&q=%22complexit...

Re: Simple, correct, fast: in that order

#157

Post by mlthoughts2018 »

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…

This is the most important part, and people advocating “correctness first” are missing this point.

“Simplicity first” means having a minimal skeleton code with glaring weaknesses, unimplemented features, and bugs, but having a simple design that sets you up well to absorb the inevitable shitstorm of changing priorities, pivots, revised performance constraints, feature wishlists, budget, deadlines, etc., and to manage extensibility, integration, or abstraction needs as they arrive in random, ad hoc ways.

Usually project stakeholders don’t care about absolute functional correctness, meeting performance criteria, or completeness until far far later in a project lifecycle, after those requirements have been thrashed around and whimsically changed several times.

Early on, they care about a tangible demo apparatus and solid documentation about the design and tentative plan of implementation. They want to see steady progress towards correctness & performance, but generally don’t care if intermediate work-in-progress lacks these things (often even for early releases or verson 1 of something, they’ll prioritize what bugs or missing features are OK for the sake of delivery).

In terms of interacting successfully with the business people who actually pay you and determine if your project lives on or gets scrapped, “simplicity first” is a total lifesaver, and matters far more than any of the notions of correctness discussed here.

Re: Simple, correct, fast: in that order

#158

Post by annabellish »

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…

None of them are absolutes. Just as we do not expect that "simple" before "fast" means "the code must be 100% as simple as it could possibly be before we begin even thinking about speed", we do not mean "the code must be 100% correct in every possible way before we even start thinking about simpleness"

It is relative preferences, more about what takes precedence over what than an absolute measure. Nothing is ever perfectly correct, nor perfectly simple nor perfectly fast.

Re: Simple, correct, fast: in that order

#159

Post by Sir_Cmpwn »

whack wrote: post #145
Sir_Cmpwn wrote: post #56

Earlier quoted context omitted.

The attitude of the CPU industry in this regard led to some recent well-publicized, very bad, and nigh-unfixable security vulnerabilities, as you might have heard.

And yet, I don't see you or anyone else committing to buy ultra-simple non-pipelined non-OOO desktop/server CPUs. If you insist on only hiring chauffeurs who drive at 100mph, you can hardly complain when they get into a few accidents.

The main problem is that most software leans on those misfeatures as a crutch to excuse heaping layers of abstractions. Unfortunately this problem comes from several places, so it's not as easily fixed.

That being said, consider me lined up to buy one of these CPUs.

Re: Simple, correct, fast: in that order

#160

Post by jpfr »

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 software design:
    One way is to make it so simple that there are obviously
    no deficiencies, and the other way is to make it so
    complicated that there are no obvious deficiencies. The
    first method is far more difficult. It demands the same
    skill, devotion, insight, and even inspiration as the
    discovery of the simple physical laws which underlie the
    complex phenomena of nature.
Source: 1980 Turing Award Lecture; Communications of the ACM 24 (2), (February 1981): pp. 75-83.
Post reply on HN