People wonder why I like ORMs even when they're unnecessary. Firstly, I've never liked SQL. I think that writing queries to a RDBMS is something that a computer should do, akin to compilation. In the few times when extreme optimization is warranted, low level code can be generated to suit that specific case. In other times, ORMs usually provide a more natural interface to data that increases readability and code flow.
@emacsen I hate SQL enough that I think there should be a better way to interface with a database, like one that's not so prone to injection and it might as well just be a binary-oriented format.
I entirely agree. SQL feels like a poor abstraction, one that should be relegated to the past, with a standard binary interface being offered, first optionally, then SQL being deprecated.
@emacsen@lanodan
I don’t mean for this to come across as condescending, so please don’t take it that way.
You are both talking about a language that you do not understand and don’t know how to use. In particular, you seem to want to tell the database how to do its job instead of just declaring the results you want. There are hundreds if not thousands of person-hours put in to optimizing queries, and your “I’ll do it in my own code” is no match for that.
@xocolatl@emacsen
> I don’t mean for this to come across as condescending, so please don’t take it that way.
Then please rephrase or rethink entirely how you want to lay your post out because that's 100% how you're putting it.
Specially as: The whole reason I want SQL to be replaced with another language is because I know it enough to know too much of it's quirks.
And it's not that I want existing databases like PostgreSQL or MariaDB to go away, you can change the interface language of a software without having to rewrite something entirely (heck, I'm writing this post on Pleroma, which changed both of client API and server API).
@lanodan@emacsen@xocolatl ORMs are great as long as you're just doing basic CRUD operations. Thankfully, that's 99% of the operations you'll ever need to do.
For the 1% of really complicated queries, that's when SQL will always be better because of how purpose build it is to return tables/do complex updates and deletes. You can do them in ORMs but it starts turning into a contortionist exercise at that point because even the best ORMs aren't made with those in mind. (Also for stuff that needs really optimized queries - ORMs may not choose the most optimal retrieval methods for a complex query.)
And even then it's all being bolted on top of some pretty awful design choices that should be changed cuz we've learned more about how to properly design a language since the 90s.
SQL queries via string formatting + basic helper functions: Good luck not accidentally doing something broken
ORMs: Generates unreadable code, tends to encourage making bad code
A better query language would allow queries to be properly checked and not warrant such bad abstraction layers.
That's why people like me want a replacement to SQL, even after having used it for years. Meanwhile your position sounds like "Please don't replace C or Bourne Shell".
@xocolatl@emacsen Well after having slept on it: SQL usage could also just separate data from code cleanly and get a nice subset that's just data, then get a clean way to separate between the two.
Like how JavaScript (code) got JSON (data) with a dedicated parser instead of eval or code concatenation, which allows to pass external data including wild ones like text in a way that's nearly always going to be safe, even if your JSON encoder screwed up and forgot to escape some characters (where then it's either extra variables or a syntax error, not code injection).
@xocolatl@emacsen Yeah, input from a user, where there's been a constant stream of code injections for decades basically whenever an ORM isn't used and the data in question isn't simple to validate (like free-form text for example).
@lanodan@emacsen
This is an example of not knowing SQL.
The constant stream of injections for decades is because people are not using parameterized queries and once again trying to do the DB’s job in their own code.
This is not SQL’s fault, it’s the developers’ fault for not learning SQL.
@xocolatl@emacsen That would be understandable if you where providing hammers, which you're not.
There needs to be tools to say "nope, this code is busted" not sheer elitism like "nope, a large part of people using SQL are entirely at fault"
Add comment