Hacker News new | past | comments | ask | show | jobs | submit login

When dealing with a software bug you have to reproduce the issue before you can definitively "fix" it.



Not true. (It is often possible to understand the cause by just looking at the damn code.)


Humans, and every other life form have an undocumented, undesigned self executing specification that consists entirely of the most reticulated, self referential spaghetti code compatible with successful reproduction and it’s not just riddled with Heisenbugs, they’re core parts of the machinery of how everything works. We’ll get there eventually but it’s going to take an exceedingly long time.


You are looking at human readable and annotated code, not what is compiled for the computer to run. Imagine finding bugs by looking at binary. DNA is more complex than 1 or 0, it could be ATCG. There are 3.2 billion nucleotides in the human genome, and we are still a long way from understanding the nuances of the DNA 'programming language.'


Maybe for superficial bugs in small toy programs. But a real bug in any sophisticated program requires a bit more than looking at the code most of the time. User feedback, log/trace data, performance data, system events data, memory dumps, etc.

Of course the bug could be in proprietary software your code is using. How would you fix that by purely looking at your own code?




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: