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

>If I expect a program to do something (eg. handle IO errors) that its code says very clearly that it doesn't, that's not the programs fault.

Is there no such thing as a bug then? The program does what the code says so every "misbehavior" and crash is expected behavior.




There is a difference between a program with a specification/documentation outlining what it should do, and one that doesn't have a spec.

AFAIK, hello.c doesn't have a spec, so the code is the spec. If I am using it, I have to read the code to know what it does.


So if I don't write a spec, I have no bugs. Got it.


Where did I say that?

I said if a software doesn't have a spec, the code IS the spec.

If I hand out a sheet of paper saying "the program returns X", but running it returns Y instead, the program is buggy.

If I hand out a piece of code which says "return X", and someone runs it expecting it to return Y, thats not the codes problem.


This Porsche has a design flaw: I can only go 22,500 kilometers before I have to replace the tires.

This VW bus has a design flaw: I can't pull more than 1G on the race track.


Speak for yourself on the bus...


If we're going to reductio ad absurdum then OS's shouldn't let programs run if they interact with a device and don't explicitly handle exceptions for those devices. The OS is just a program and if it allows programs to crash it, isn't that the OS's fault?




Join us for AI Startup School this June 16-17 in San Francisco!

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

Search: