Hacker News Reader

Comment by kibwen | Hacker News Reader

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.

View on HN

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.

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.

Clearly, that solution isn't simple enough.

> Correctness is achieved by simplicity.

That's... literally what I just said? "Achieving correctness is the whole point of making things simple, after all."

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 goal for the day-to-day work. Because it can be tracked, measured and evaluated for every individual change.

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

> ...reinforcing that correctness is more important than simplicity

It's the other way around. Correctness is obviously the goal (and likely performance too, depending on your use case), but the way to achieve it is through simplicity. So simplicity should be prioritized - as it allows you to ensure correctness.

I'm glad that we can agree that correctness is the goal, though I still take umbrage to the blog post's title, thesis, and conclusion. :P

By that logic, "fast" goes before "correct"; you can't print the answer quickly if you don't have the answer, after all.

> if your solution is not simple, it will not be correct or fast.

The point of the article is that "simple" is a prerequisite of "correct" (and "fast").

We reached the maximum thread depth.

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

There's 40 years of research into that. And loads of tools to support dev teams.

You can start here: https://en.wikipedia.org/wiki/Cyclomatic_complexity

Also related are costing models: https://en.wikipedia.org/wiki/COCOMO

Derek Jones argues McCabe Complexity and COCOMO were scientifically unsupported with little bandwagons pushing them for reasons of fame and/or funding:

http://shape-of-code.coding-guidelines.com/2018/03/27/mccabe...

http://shape-of-code.coding-guidelines.com/2016/05/19/cocomo...

We also have 40 years of research into improving program correctness, e.g. static analysis, test suites (unit, integration, etc.), fuzzing/mutation testing, and the benefits of code review. The idea that simplicity (which I'm pretty sure that nobody in here is using to specifically mean "the lack of cyclomatic complexity") can be measurably improved but that correctness cannot is incorrect.

> The idea that simplicity (which I'm pretty sure that nobody in here is using to specifically mean "the lack of cyclomatic complexity") can be measurably improved but that correctness cannot is incorrect.

Have you seen a program that comes with a formal proof of correctness? I have. And boy, they are really simple.

The end result can be complicated. But the program is broken up into small, simple, easy-to-understand pieces that are then composed.

http://spinroot.com

https://frama-c.com

I think maybe you mistakenly assumed that response was in opposition to your comment, I read it as a simplification and restatement of what you said.

Yes but I think OP is saying that, paradoxically, prioritizing correctness over simplicity actually makes correctness more elusive than if simplicity were prioritized.

No, that's just the easiest path to it if your only tool is an unaided human brain.

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.

Reply on news.ycombinator.com