Why bad scientific code beats code following "best practices"

Re:Why bad scientific code beats code following "best practi... by klmr on Monday May 12, 2014 @01:55PM (#7734300)

I think the comment is implicit: bad code leads to wrong code. Or rather: with bad code, how can you tell either way?

> In this sense, the sins of the scientific programmer might actually be important

No, you’re turning facts on their head: “fail early”, as described by you, is not a “sin”, on the contrary, it’s a hallmark of good software engineering [1]. Of course a nicely formatted error message is preferred to a coredump, but the end result is similar. But that’s not what (a lot of) bad scientific code does. Instead, it veers into the realm of undefined or unpredictable behaviour by failing to recognise the existence of a problem.

[1] https://en.wikipedia.org/wiki/Fail-fast

[ Parent | on HN ]

Re:Why bad scientific code beats code following "best practi... by apw on Monday May 12, 2014 @09:10PM (#7736193)

It's not clear that a nicely formatted error message is preferable to a core dump.

With a core dump one can explore the execution environment at the time of the crash.

A nice compromise is a macro that prints an error message and then calls __builtin_trap().

[ Parent | on HN ]

Re:Why bad scientific code beats code following "best practi... by afarrell on Tuesday May 13, 2014 @12:21PM (#7738932)

But a nicely formatted error message, so long as it is correct, can be read by many more people than a core dump.

I don't know how I would read a core dump of an error in a python program to understand where an exception came from.

[ Parent | on HN ]