Hacker News new | ask | show | jobs
by KingMob 3979 days ago
Which is why it was a great fit for MySQL, which would silently store invalid dates and truncate over-long strings with no warnings.
4 comments

You joke, but I'm pretty sure this is one of the reasons why that stack was so successful. Same principle behind HTML rendering. "It's displaying something, isn't it? Errors are only suggestions."
I'm not so sure. It's kind of true for HTML (forgiveness was not "good" property of the format, but of the browser: 1 site works in one browser, but not in the other, and user will blame the browser, so let's display whatever the hell we can). But PHP in the early days was kinda handy (even though hacky) tool, allowing to use simple syntax to render HTML instead of custom Perl-scripts. And then it just got popular.

MySQL was once actually superior open-source database, being more performant and simpler to setup and use than PostgreSQL. And then, once again, it just got popular.

I don't think being faulty helped these technologies, although it sometimes is the case.

There are warnings. Most people just ignore them in their APIs
Trying to insert over-large data should have been an error by default from the outset, never a warning. Ilooked at MySQL in 2000 and went "You had one job, database; protect my data."
This is so true. It is the main reason I switched to PostgreSQL and never looked back.
... and accept nonsensical SQL queries, returning whatever it feels like.