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

I don't have a strong opinion either way, but I don't think #1 is a given.

You describe one reasonable approach to building things: bad shit should blow up quickly, forcing fixes. But another reasonable way is working to make sure something reasonable happens. E.g., Postel's Robustness Principle: http://en.wikipedia.org/wiki/Robustness_principle

My understanding is that PHP started out as a noob-friendly page scripting language. For that kind of system, do-what-I-mean coding is reasonable. You're not trying to force amateurs to be pros; you're just trying to help them get something up and working. But maybe the PHP audience has shifted enough that the break-early-break-often approach is the right one these days.

I'm perfectly fine with the robustness principle being applied, but it seems as if it gives people who write poorly thought out projects a convenient excuse for bad design decisions. I've been using PHP since the early 4.x days, so I've seen the project change over the years and I can honestly say I don't think the robustness principle was ever consciously applied across the project, it just ended up that way. If it was a conscious decision then there would be at a very minimum a standard output for invalid input across all functions. Instead, every function returns something different (FALSE, 0, '', '0', NULL). Sometimes the output for invalid data is documented, sometimes it isn't, sometimes it changes without any notice or modification of the documentation. This doesn't seem like a design choice to me.

If they were going to take that approach, it should have returned 0 then.

I think of this as "garbage in, garbage out". The function will return a numeric value -- if you give it proper input.

On two occasions I have been asked,—"Pray, Mr. Babbage, if you put into the machine wrong figures, will the right answers come out?" In one case a member of the Upper, and in the other a member of the Lower, House put this question. I am not able rightly to apprehend the kind of confusion of ideas that could provoke such a question.

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