Showing my age here but YES. The whining seems to come from those who have very quiet keyboards and mouths that swing between their ears like a skipping rope.

I come from an era where stored procs were widely considered to make things easier. Think of it as a public or friend method and tables/views as a private objects.

The hypocrisy of saying SQL stands for "Scarcely Qualifies as a Language" to saying that maintaining stored procs is "too hard"!!!!!

Have you tried reading Java code pre Java8?!?!? Clojure anyone? C++ is not one for the faint hearted. I know that the older we get the better we were but I don't remember old school developers moaning so much. Applications don't seem to be developed any faster although there seems to be a plethora of tools and frameworks to help.

I've found that ORMs can work perfectly acceptably to all concerned but it takes a competent DBA and a competent developer (if they aren't the same person) to configure them and establish good working practices for the development teams (consisting of multi-skilled practitioners). PBCAK.

Most OLTP stored procs are of simple to moderate complexity. The "too hard" stuff I've seen has generally been in the overnight maintenance and data prep jobs.

Business logic in the database? What if what you want to do is naturally set based? Are you going to use a purist argument as an excuse for doing something just plain daft!?!!?

I had a meeting with someone who, when asked why they use Hive/Impala rather than MapReduce or some of the newer programming frameworks, turned round and said that although the frameworks were technically superior, SQL got the job done in the timescales the customer needed and successfully delivered revenue and could be easily modified if required. The skills gap between SQL and the business was tiny compared to the skills gap between MapReduce and the business. I can't tell you who the person was due to NDA but most people would kill to get to see him talk at QCON.