Nah, the problem is PHP.

See: http://blog.codinghorror.com/falling-into-the-pit-of-success...

> When you write code in [PHP], you're always circling the pit of despair, just one misstep away from plunging to your doom.

I'd be willing to say this is true for any language in varying ways.

But to widely varying degrees. This kind of problem is a direct consequence of having a relatively weak and dynamic type system (or other semantics that mean you might as well have).

Plenty of people have warned about this kind of danger for a very long time. However, there seems to be a significant subset of the web development community that only has experience with languages like JS and PHP and to a lesser extent other dynamic languages like Ruby and Python, who simply fail to realise how many of these bugs should have been entirely prevented by using better tools by now. The usual counter seems to be something about unit tests, at which point anyone following the discussion who actually knows anything about type systems and the wider world of programming languages dies a little inside.

It is entirely fair to criticise bad tools for being bad, particularly in specific ways and with clearly identified problems that can result as in this case. It's bad enough that we are stuck with JS for front-end web development these days, but there aren't many good arguments for using something as bad as PHP on the back-end in 2015.

And what is gained from doing so? We must remain critical.

No, the problem is using a shitty function like MD5 for any practical purpose.

The hash function is completely irrelevant to this bug - whether you use a hash that returns 0 for every input, or invent a hash function that returns a perfectly unique and unpredictable hash for all inputs, PHP will still shoot you in the foot.

I didn't hear him blaming PHP. Defensive, are we?

He didn't blame PHP, just never used it again for anything important. Did we read the same comment?

Please, read "The Design of Everyday Things": http://www.amazon.com/Design-Everyday-Things-Donald-Norman/d...

If you don't like "keep it simple stupid" and determinism in your language of choice (much less immutability)... you're basically everything wrong with programming in the year 2015

You bought a new car. You took it out for a ride. a tree falls before you. You brake, but the car proceeded to hit the tree anyway.

You call the car company and talk to their engineers. One of them ask. 'Did this happen on a Friday evening, when it was raining?' You say 'Yes, how do you know?'

The engineer replies.

"Our brakes does not work on rainy Friday evenings. If you REALLY want to brake on a rainy Friday evening, you should also pull the lever under the dash board that is normally used to open the hood. It is very clearly printed on our manual. Didn't you read it? Our car is not the problem. You are the problem"

You were enlightened. You came back home. You never took the car out on rainy Friday evenings. When Somebody asks about the car, You said. "Yea, it is a great car. But you got to know how to use it".

You took great pride in knowing how to drive this car, which can easily kill someone who hasn't read the manual. When you hear that someone got killed while driving this car, you simply said. 'That car is Ok. but you should really know how to drive it, sadly this guy didn't. He was the problem, the car ain't...

From now on, when I write “RTFM,” I will also link to this comment.

> You bought a new car.

There's your problem, wasting money on something that only depreciates in value. Tsk tsk.

It's not the complexity of the car manual, but the falling tree that I fear.

sure, everything should be done perfectly or not at all ...

We can accept that perfection may be impossible, difficult to obtain, or a poor tradeoff against other factors.

But that doesn’t mean that all imperfect designs are of equal merit.