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

Re: Simple, correct, fast: in that order

#341

Post by tzm » Tue, Jul 10, 2018, 1:52 PM UTC

kibwen wrote: post #170

jpfr wrote: post #160

Earlier quoted context omitted.

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…

That quote actually refutes the OP by reinforcing that correctness is more important than simplicity. Achieving correctness is the whole point of making things simple, after all. To put simplicity before correctness would be missing the forest for the trees.

In terms of designing solutions, I would say that "correctness" is relative to the problem statement at hand. It's also a degree and not an absolute. It may be correct and incorrect at the same time, depending on the context. From this I would prefer simplicity over correctness to allow for ease of optimization.

Re: Simple, correct, fast: in that order

#342

Post by nicbou » Tue, Jul 10, 2018, 4:28 PM UTC

Buttons840 wrote: post #260

michaelcampbell wrote: post #32

Earlier quoted context omitted.

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.

Sometimes I try to implement a common task in a new library, and I find that if I chain these 4 API calls and then extract some data with a regex, it will do what I want. I rarely actually implement the task this way though, because I know it's a common task, and there must be a better way. Sure enough, after some more research and reading of documentation I find one simple API call that does what I want. I take this…

This is good, because that process now becomes the API's problem and not yours. Their tests cover it, not yours, and it makes your work simpler.

Re: Simple, correct, fast: in that order

#343

Post by BatFastard » Tue, Jul 10, 2018, 4:45 PM UTC

I find it depends on how well you understand the problem space. If you are well versed in it than making a simple solution first is possible. Which can be corrected to handle edge cases later.

However if the problem space is new for you. I find I usually have to write more complex code to understand it first. Then I can come back and simplify the complex code.

Re: Simple, correct, fast: in that order

#344

Post by davidhariri » Tue, Jul 10, 2018, 5:20 PM UTC

I can't agree.

Simple is important, but it's not the most important thing. The overwhelming evidence is that there's plenty of working software, in use, that isn't simple. Users will shape their behaviour and memorize flows around a complex piece of software if there is sufficient motivation.

My own principles for design state this order:

Functional, Simple, Delightful

Does it do the job? Is it simple to use (nothing more than what's required)? Do people get excited to use it?

The first is non-negotiable and the last is optional. There's a lot of software that is functional, but over-complicated. Lots that is delightful, but doesn't work and everything in-between.

The software I admire most (and use daily) has a balance of all three.

Re: Simple, correct, fast: in that order

#345

Post by nerpderp83 » Tue, Jul 10, 2018, 6:48 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…

This book, "The Psychology of Computer Programming" is by Gerald Weinberg, an author that really explores the design and complexity of systems. I recommend his other books, esp, "On the Design of Stable Systems : A Companion Volume to an Introduction to General Systems Thinking"

http://www.ppig.org/library/book/psychology-computer-program...

Re: Simple, correct, fast: in that order

#346

Post by wellpast » Tue, Jul 10, 2018, 8:11 PM UTC

AstralStorm wrote: post #328

wellpast wrote: post #309

Earlier quoted context omitted.

I believe you're conflating simplicity/complexity with flexibility. _One_ hallmark of developer ability is the discretion/wisdom/experience to know how flexible to make the thing. (How to prioritize and limit feature-creep, etc.) But this is different than Simplicity. A general purpose programming language or database -- highly flexible/generic systems -- for example, can be built well/simple. But so can highly _spec…

Sometimes you just want a hammer, not a swiss army knife. And sometimes it is good to have a replaceable head on the hammer.

Yes! And the property of Simplicity is orthogonal to whether or not you chose to make the Knife or the Hammer.

A Hammer's construction can be Simple. A Knife's construction can be Simple. Or not.

Re: Simple, correct, fast: in that order

#347

Post by wellpast » Thu, Jul 12, 2018, 1:36 AM UTC

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.

Also it’s not about working harder; it’s about building smarter—building simple systems—which absolutely makes your world simpler. ‘Essential complexity’ is what sophomoric developers decry when they are unable to architect well—and are unwilling to do the hard work it takes to learn to architect well.

Re: Simple, correct, fast: in that order

#348

Post by hk__2 » Thu, Jul 12, 2018, 1:58 PM UTC

jpfr wrote: post #179

kibwen wrote: post #170

Earlier quoted context omitted.

That quote actually refutes the OP by reinforcing that correctness is more important than simplicity. Achieving correctness is the whole point of making things simple, after all. To put simplicity before correctness would be missing the forest for the trees.

Correctness is achieved by simplicity.

That doesn’t mean simplicity is more important than correctness. The simplest program ever is an empty file, and it doesn’t solve any problem.

Re: Simple, correct, fast: in that order

#349

Post by KarjamP » Sun, Jul 15, 2018, 2:21 PM UTC

ythn wrote: post #114

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

Correctness does come first, or else you can't play games the wa they're intended to be played, but the way BSNES does it is wrong.

I believe that it does so through attemptng to mimic the working circuit logic and chips, the physical hardware, within code alone, hens it requiring a powerful computer. This is an incredibly unoptimized way of doing it, especially since it's formed out of incorrect assumptions n what "accurate emulation" is.

It's the effects that we want, not the logic. If you're going to emulate something that, through common sense, shouldn't even require that much power, you're doing it wrong.

The saying goes, "keep it simple, stupid!" To overcomplicate things, like the programmer of BNES did, results in unweildy an unoptimized code.

Even Nintendo doesn't do this tactic with their official emulators. Yeah, sure, they're known to be inaccurate at times, but that's only because Nintendo's not aiming to build a general emulator to handle all case scenarios. Besides, much of the inaccuracies, as far as I could understand, deal with undefined behaviors of the system, something only things like glitches and bugs ever take advantage of.