[kaba0]

Arguably, other disciplines doesn’t have to handle undecidable problems everywhere. Building a bridge can basically be “statically analyzed” completely, in that every requirement is known beforehand and there is a very constrained mutable state there. On the other hand, even the most basic program one can write will have properties not decidable without actually running the program. I would like to see much more rigorous testing/quality control in user-facing apps as well like websites, but lower level tools usually are written with much higher quality. You would be hard pressed to routinely find a bug in eg. the JVM — and writing formally verified programs is infeasible for any significant complexity.

[littlestymaar]

> Building a bridge can basically be “statically analyzed” completely

This. And even then, after the calculations are done the engineer add a “safety margin” (and it's not 10%, more like 500 or 1000%).

[kaba0]

Good point. And also, it is possible to add safety margins to other areas of engineering. One may be able to eg. store an array with padded nulls (actually we sort of do it at an OS level, just not with null but some “magic number”), but if it’s a loop/recursion, non-correct software will blow up either way - here it is more close to mathematics than science or engineering in my opinion.

[ncmncm]

We expect software to work, in places that are engineered. A SpaceX Falcon launch control system that encounters anything undecidable, whether in launch preparation or in flight, has utterly failed.

It was Microsoft that got people used to software failing on a routine basis, and "have you rebooted?". Before, anything that ever crashed, you sent back for a refund, or expected a tech to come out and fix it post-haste. Clearly MS could not make money that way, but getting people with no experience to believe failure was normal was quite cheap to arrange.