Hacker News Reader

Comment by jpfr | Hacker News Reader

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.

View on HN

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.

> 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

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.

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

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

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

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

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").

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

    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.

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.

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.

Depending on interpretion of terms, I'd agree with either simplicity or correctness first. To disambiguate I would say:

  Working, simple, correct, optimized.

Would deffo agree to this.

My approach is usually sending out a PR as soon as I can to a group of reviewers / users and goes in following stages.

1) POC - proof of concept. It does 90% of things, some parts are ugly and messy but validates a hypothesis. The unknown unknowns are discovered. I want to stage this and get this in front of some alpha internal users as soon as I can. First pass reviewers give a on the plan of attack. Lots of sub TODO’s are listed in PR. The goal is to discover edge cases and unknown unknowns.

2) Simple - Go through PR and refactor any existing / new code so it’s readable and DRY. If reviewers don’t understand the “why” of some code, a comment is left. Now 90% of scenarios are covered, probably some edge cases may not work but the edge cases are known. The code is simple and at right layer of abstraction.

3) Correct, Testable - Edge cases are covered, tests are written, internal users have validated that the feature is working as expected.

4) Polish - if it’s slow, then slow internals are swapped out for fast parts. Tests would mostly work as is. Same with UI, css fixes to make it elegant and pretty.

Sometimes the process is a day, sometimes it’s a week.

> Your example is a case of premature optimization. That is not what the author is concerned with.

I think he is. Premature optimisation is putting the order: fast, simple, correct.

So although the author doesn't explicitly state it, premature optimisation is something that would be avoided if you followed his advice.

Reply on news.ycombinator.com