Conversation

Notices

1. Embed this notice
   Emacsen (emacsen@emacsen.net)'s status on Monday, 31-Jul-2023 15:16:02 JST Emacsen

   A bit of a programmer rant...

   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.

   #programming #rant #sql #databases #orm

   1/2

   • Haelwenn /элвэн/ :triskell: likes this.
   • Embed this notice
     Haelwenn /элвэн/ :triskell: (lanodan@queer.hacktivis.me)'s status on Monday, 31-Jul-2023 15:17:00 JST Haelwenn /элвэн/ :triskell:

     in reply to
     @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.
   • Embed this notice
     Haelwenn /элвэн/ :triskell: (lanodan@queer.hacktivis.me)'s status on Tuesday, 01-Aug-2023 20:21:46 JST Haelwenn /элвэн/ :triskell:

     in reply to

     • Vik Fearing
     @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).
   • Embed this notice
     Vik Fearing (xocolatl@mastodon.social)'s status on Tuesday, 01-Aug-2023 20:21:47 JST Vik Fearing

     in reply to

     • Haelwenn /элвэн/ :triskell:

     @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.

   • Embed this notice
     Emacsen (emacsen@emacsen.net)'s status on Tuesday, 01-Aug-2023 20:21:48 JST Emacsen

     in reply to

     • Haelwenn /элвэн/ :triskell:

     @lanodan

     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.

   • Embed this notice
     Haelwenn /элвэн/ :triskell: (lanodan@queer.hacktivis.me)'s status on Tuesday, 01-Aug-2023 20:32:18 JST Haelwenn /элвэн/ :triskell:

     in reply to

     • Glitch
     • Vik Fearing
     @glitch @emacsen @xocolatl Please do not explain shit that I know.
   • Embed this notice
     Glitch (glitch@pl.glitch.pm)'s status on Tuesday, 01-Aug-2023 20:32:19 JST Glitch

     in reply to

     • Haelwenn /элвэн/ :triskell:
     • Vik Fearing
     @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.
   • Embed this notice
     Vik Fearing (xocolatl@mastodon.social)'s status on Tuesday, 01-Aug-2023 22:57:08 JST Vik Fearing

     in reply to

     • Haelwenn /элвэн/ :triskell:

     @lanodan @emacsen
     I don’t know how to put “you don’t know what you are talking about and should read a book or something” more delicately.

   • Embed this notice
     Haelwenn /элвэн/ :triskell: (lanodan@queer.hacktivis.me)'s status on Tuesday, 01-Aug-2023 22:57:08 JST Haelwenn /элвэн/ :triskell:

     in reply to

     • Vik Fearing
     @xocolatl @emacsen
     Consider:
     - 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".
   • Embed this notice
     Haelwenn /элвэн/ :triskell: (lanodan@queer.hacktivis.me)'s status on Wednesday, 02-Aug-2023 11:55:13 JST Haelwenn /элвэн/ :triskell:

     in reply to

     • Haelwenn /элвэн/ :triskell:
     • Vik Fearing
     @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).
   • Embed this notice
     Haelwenn /элвэн/ :triskell: (lanodan@queer.hacktivis.me)'s status on Wednesday, 02-Aug-2023 18:19:47 JST Haelwenn /элвэн/ :triskell:

     in reply to

     • Vik Fearing
     @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).
   • Embed this notice
     Vik Fearing (xocolatl@mastodon.social)'s status on Wednesday, 02-Aug-2023 18:19:48 JST Vik Fearing

     in reply to

     • Haelwenn /элвэн/ :triskell:

     @lanodan @emacsen
     I am not sure exactly what you mean by separating code and data. Data is the result of the code.

     Unless you mean when you provide data, like input from a user or something. That has existed for over 30 years now.

   • Embed this notice
     Vik Fearing (xocolatl@mastodon.social)'s status on Wednesday, 02-Aug-2023 18:28:49 JST Vik Fearing

     in reply to

     • Haelwenn /элвэн/ :triskell:

     @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.

   • Embed this notice
     Haelwenn /элвэн/ :triskell: (lanodan@queer.hacktivis.me)'s status on Wednesday, 02-Aug-2023 18:28:49 JST Haelwenn /элвэн/ :triskell:

     in reply to

     • Vik Fearing
     @xocolatl @emacsen And blaming the users is a blatant example of design failure, even for languages.
   • Embed this notice
     Haelwenn /элвэн/ :triskell: (lanodan@queer.hacktivis.me)'s status on Wednesday, 02-Aug-2023 18:38:09 JST Haelwenn /элвэн/ :triskell:

     in reply to

     • Vik Fearing
     @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"
   • Embed this notice
     Vik Fearing (xocolatl@mastodon.social)'s status on Wednesday, 02-Aug-2023 18:38:10 JST Vik Fearing

     in reply to

     • Haelwenn /элвэн/ :triskell:

     @lanodan @emacsen
     Sorry. Blaming your tools just because you don’t know how to use them is not a design failure with the tools.

   • Embed this notice
     Haelwenn /элвэн/ :triskell: (lanodan@queer.hacktivis.me)'s status on Wednesday, 02-Aug-2023 18:45:27 JST Haelwenn /элвэн/ :triskell:

     in reply to

     • Vik Fearing
     @xocolatl @emacsen And user errors should be errors, either at runtime or with some other way like static analysis.
   • Embed this notice
     Vik Fearing (xocolatl@mastodon.social)'s status on Wednesday, 02-Aug-2023 18:45:28 JST Vik Fearing

     in reply to

     • Haelwenn /элвэн/ :triskell:

     @lanodan @emacsen
     I criticize #SQL all the time—and there is much to be critical about—but the “problems” you are describing are purely user-error.

   • Embed this notice
     Mike Kutz (mkutz1492@mastodon.world)'s status on Wednesday, 02-Aug-2023 20:40:33 JST Mike Kutz

     in reply to

     • Haelwenn /элвэн/ :triskell:
     • Vik Fearing

     @xocolatl @lanodan @emacsen

     - declarative languages (sql)
     - objective code (ORM)
     - hierarchical file format (JSON, XML)

     All 3 are different ways to describe the same thing. It should be easy to translate between.

     Each solves a different set of problems better than the others.

     Don't hate one because you don't run into the problem it solved best.

     IMO

     Haelwenn /элвэн/ :triskell: likes this.