Who's that sane to prefer programming with stored procedures than an actual programming language?

I would like to touch that shit only for optimization reasons, but when you have a project being built up without proper ORMs this is the idea that comes out of 'seniors' -__-

SQL stored procedures? Haven’t used entity or anykind of that, so I’m using it, is it bad?

Aside from plsql being shitty, it's just bad to get a database doing extra work over reading and writing. May as well let the consuming program do the work instead to free up resources for more consumes

@devTea Yes. It's not so bad but still you're writing something that'll work only for that type of database, nothing that you can pursue in an abstracted way and that can make a switch to another database almost painless later on (of Microsoft fucks up big time)

@h4xx3r how likely is it a project would change a database? Not saying I don't use ORM but I have this question in the back of my head for a long time now.

@Frederick agree. Endure my brother.

@captainskippah I think it's up to the circumstances, the project may be not that much complex, so a change may never happen, but I've seen complex one just stump on it's own feet because initial demand/requirements were different from nowadays one.
So pick your poison, because in the industry there are examples where ORMs were bad options too ¯\_(ツ)_/¯

@h4xx3r i see. Basically it's YAGNI vs foresight then. Haven't had any experience with large project even in my 4yrs of being a dev so I can't really tell. But code wise, IME, you just know the balance between the 2. Like for example, you just kinda know when to stop hiding in interface.

I don’t prefer stored procedures (I always advocate to ban them in a project), buuuut I think that the industry has made a huge mistake just because plsql was a crappy language.

You should bring the code to the data and not the data to the code! This is why you write queries like “select sum(x) from y”. No amount of clever ORMing will be able to abstract the database completely.