it's pretty hard to write even a simple smart contract that doesn't have horrible vulnerabilities. far harder, I would say, than writing C code that can't be buffer-overflowed on an old system with no protections in place. and solidity the language does NOT make this any easier. read all the resources you can. there are really counterintuitive best practices.
the reason for all these hacks is not stupidity or laziness of the developers. the EVM execution model just makes it very easy to write vulnerable code.
Quite the exaggeration, this silly meme has to stop. You make it sound like writing even a hello world would have horrible vulnerabilities or something. There are thousands of perfectly safe contracts deployed, one can't take some isolated incidents and make such conclusions from such a small sample.
maybe not a hello world, but even very rudimentary 20 LoC contracts for, say, keeping account balances can have reentrancy vulnerabilities when written in the obvious way. so your customer could just give themselves an infinite balance.
i don't think it's impossible to write secure smart contracts but it takes quite a bit of care even for simple stuff.
there are many issues that arise because your functions might be called by an adversary who has set up the stack in an evil way.
Agree with this, especially with the "it takes quite a bit of care even for simple stuff", but this should not discourage developers to do so.
One of the reasons to build this kind of infrastructure is to set proper standards for smart contracts development which are currently missing.
As long as we are aware that we need to be careful, and we raise the quality of the code and keep on developing tools to improve development as a whole things should keep on moving forward.
the reason for all these hacks is not stupidity or laziness of the developers. the EVM execution model just makes it very easy to write vulnerable code.