I suppose so, but this heavily relies on no one in your operation having made a mistake, or that mistake having been caught before it was pushed live.
You have to be lucky every time, an attacker only needs to be lucky once.
You have to be lucky every time, an attacker only needs to be lucky once.
SQL injections are just one class of many. There are ways to vastly reduce SQL injection risks but that still leaves many other venues of attack.
Even Haskell is not a silver bullet against every kind of security problem. Didn't Snap have a directory traversal bug a while back?
You could have been informative and made your original point tactfully. Instead, you badmouthed a certain technology without even naming the stuff that was supposedly better. I'm a Haskell evangelist and agree with you 100%, and you came off like a jerk even to me.
Your assertion that whatever problems I deal with are solved problems is absolutely insane. Please, tell me how problems like interpreting customers requirements are "solved" and what technology I can use to ensure that all the code I write will 100% always match the users mental picture of what they wanted.
Criticizing the choice to deliberately create security holes for convenience is not "badmouthing", and "I'm offended" is not a productive response. It literally conveys no useful information at all.