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

101–110 of 349 posts

Re: Simple, correct, fast: in that order

#101

Post by BlackFly »

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 moment, the programs I am working on are in some way broken in my mind. Even if the other programmers thought that correctness was priority number 1, I will never consider the program correct. I will always suspect there is some snake in the grasses.

I suppose you could feel the same way about simplicity. I think the most charitable stance would be to give them the same level of importance. Overtly complex code cannot easily be proven to be correct amid changing business requirements. Easily testable, complex code with a full functional test suite is at less simple in one sense. Patently incorrect code is hardly valuable regardless of how easily one can understand its function.

Re: Simple, correct, fast: in that order

#102

Post by DannyB2 »

karma_fountain wrote: post #85
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…

Seen this several times when someone refactors. The code is much simpler and easier to read, but does not actually work for several important test cases anymore. I've never thought of simplicity adding upfront cost. That's probably true, but also true that it pays dividends later on in the project.

Simplicity is ALWAYS something desirable to achieve. Correctness comes first.

As code is originally written, people are (or should be) using the most "obviously" simple approach.

A Breakthrough in simplicity is often the result of additional thinking and hard work. (And cost)

Re: Simple, correct, fast: in that order

#103

Post by bluetomcat »

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…

In a way, simplicity is the end result of reducing the complex and correct solution without affecting its correctness.

As in math, you come up with the "simple" solution of 0.5 only after you've realized that the "complex" solution is, for example, "sin(pi/4) * cos(pi/4)". There might be no other way to discover the simple solution.

Re: Simple, correct, fast: in that order

#104

Post by tchaffee »

My version of this is test cases (e.g correct), simple, fast: in that order. With test cases you can refactor your initially complex and naive solution as many times as needed until the solution is easy to understand and elegant. I've rarely made something simple the first time around. To get to simple I need to work at it. And I'd like to know I'm not breaking things when I do that work.

Re: Simple, correct, fast: in that order

#105

Post by sgt101 »

Software is rarely correct, because if it is not correct today it will only be correct tomorrow due to skilled interventions, and if it is correct today then it will almost certainty not he correct tomorrow without skilled intervention. The chance of skilled intervention is always low.

Simple software reduces the skill required to intervene.

Re: Simple, correct, fast: in that order

#106

Post by jstimpfle »

whack wrote: post #41

The OP's advice, if applied in CPU industry, would be disastrous. Modern desktop/server CPUs are incredible complex... in order to drive maximum performance. Pipelining, OOO execution, branch prediction and speculative execution: these are all features that introduce tremendous amount of architectural and design complexity. In many cases, they also harm correctness, because they can lead to functional and security bu…

In the free software world, this is not a huge problem. You can make new CPUs and recompile programs with far fewer effort. All that complexity really comes from monetization.

Re: Simple, correct, fast: in that order

#107

Post by ythn »

DannyB2 wrote: post #79
ythn wrote: post #50

Earlier quoted context omitted.

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!

You missed the point of the article if you interpreted it as correctness being intentionally sacrificed for simplicity.

Plus, a complete leap year implementation is already what I would consider simple and most standard libraries already have an implementation for it you can use directly.

Re: Simple, correct, fast: in that order

#108

Post by DannyB2 »

Dylan16807 wrote: post #92
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…

> 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. Correctness isn't binary. Roughly no software today is 100% correct, but for most purposes you'd still pick the current version over a highly complex, slower, more-correct version. Simplicity can save you a lot of cost as…

If correctness is some kind of continuum rather than a binary choice, then pick whatever trade offs, cost, and other factors you want.

Plenty of times correctness is binary. In some cases it would be: passes all tests. Or: meets all requirements. Even if it could be "more" correct (or "more" simple), but those aren't part of the tests / requirements.

Re: Simple, correct, fast: in that order

#110

Post by xbtsw »

The article and lot of comments implicitly have the assumption of you must sacrifice something to get simplicity or correctness, at least at beginning. Performance can only be picked up “later”.

The fact is retrofit performance into a sufficiently complex system is hard, more often then not the system has to be redesigned and rewritten to achieve it, as we have seen with so many OSS project.

I think with right amount of forethought, all three can be achieved. That doesn’t mean you never need to iterate on your software, because requirement always involves.

Post reply on HN