6 ms·

doesnt meant the syntax isnt a pile of dog farts

drfloyd51 25d ago
Are we really this devolved as coders? We can’t handle different syntaxes? We need LLMs to write queries? What the heck is going on with our industry? Old man rant off.
- g-b-r 25d ago
  Syntax affects readability and writing speed a lot
  - ako 23d ago
    Writing speed is not really relevant anymore, LLMs do it. Reading is what matters most.
    - g-b-r 22d ago
      :rolleyes:
- 3eb7988a1663 25d ago
  I don't take it as too-much-syntax in the brain[0], but all of the problems bad syntax causes. We could still be writing code in assembly, but we have found that different languages make things easier or safer to construct. I can trivially handle having to repeatedly bounce to the top-then-to-the-bottom of a query I am writing because I want to change the group-by or sorting order, but that is annoying friction. Since the language does not compose well, you need to keep most of the query in your head and cannot build it up piecemeal as easily as something like PRQL (https://prql-lang.org/ https://prql-lang.org/) [0] Although, it would be incredible if I could write timestamp formatting without having to look up the bespoke vendor incantation every time I switch dialects.
  - DenisM 24d ago
    Does CTE not allow composability?
- goatlover 24d ago
  Not even an old man rant SQL isn't that hard to learn. I never had a problem with the syntax. Not everything needs to look like C. Remember when every complained about Python's whitespace indenting? Seems like everyone got over it.
- zbentley 24d ago
  The difficulties that even experienced programmers have with SQL are far more than just the syntax. And, given what most people need the database for, that difficulty is pretty disproportionate to the complexity of the task. I think the “it’s just syntax bro, learn it!” critique is about as ill-fitting as the claim that embedding a scripting language in a larger program is pointless because “assembly/C89 is just syntax bro, learn it!”
  - grebc 24d ago
    I take what you’re saying about difficulty being disproportionate to the task as an indicator of ability. It’s literally so damn simple to knock out a database & some crud functions either as a desktop app or a website that the complaints in this thread are hilarious.
    - zbentley 24d ago
      That comes across as arrogant and rude. Assuming you actually want to engage, I discussed some of the reasons that this can be hard here: https://news.ycombinator.com/item?id=49411927 https://news.ycombinator.com/item?id=49411927 The link in the top comment further expands on the cognitive overhead: https://www.scattered-thoughts.net/writing/against-sql https://www.scattered-thoughts.net/writing/against-sql Particularly relevant is the part of that link which discusses having to pervasively refactor queries to add even a simple synthetic join or computed column. That’s a pain in the ass even for experienced DBAs, and is fundamentally not time well spent for row-at-a-time cases that are often, as you said, simple CRUD. Are you sure you aren’t overfitting based on working on only one small, simple subset of the things people commonly use SQL for?
      - grebc 24d ago
        The example of pervasive refactor is a bit of a contrived example to be honest. Get the id of the record you're discussing with your pre-conditions and then retrieve the data you're after. At least in SQL Server select x2 from foo group by x+1 as x2 you'd use select x+1 as x2 from foo group by x. I've read your article and it's written well enough, I'm just not sure that's as big a hit piece as you think it is nor do I think here is the place to post a full rebuttal. >Are you sure you aren’t overfitting based on working on only one small, simple subset of the things people commonly use SQL for? I think on the contrary that esoteric features not used as commonly utilised deserve to be esoteric to use. The common path should be the easiest. That SQL is used by different professions and not just IT related ones is testament to a good language. You won't find BA's using C to write reports for instance. There's A LOT of value in that.
- euroderf 24d ago
  Is it really THAT terribly difficult to replace "SELECT vars FROM table..." with "FROM table SELECT vars...", so that tools can provide suggestions ?
YuechenLi 25d ago
I agree, yeah, SQL syntax is awful. But the easier solution is what pretty much what backend has converged on, have something in your backend programming language that lowers to SQL so you never have to write any raw SQL at all except as a low-level escape hatch, so that in most instances SQL just becomes an IR that nobody really needs to think about in normal application code.

Are we really this devolved as coders? We can’t handle different syntaxes? We need LLMs to write queries? What the heck is going on with our industry? Old man rant off.

g-b-r 25d ago
Syntax affects readability and writing speed a lot
- ako 23d ago
  Writing speed is not really relevant anymore, LLMs do it. Reading is what matters most.
  - g-b-r 22d ago
    :rolleyes:
3eb7988a1663 25d ago
I don't take it as too-much-syntax in the brain[0], but all of the problems bad syntax causes. We could still be writing code in assembly, but we have found that different languages make things easier or safer to construct. I can trivially handle having to repeatedly bounce to the top-then-to-the-bottom of a query I am writing because I want to change the group-by or sorting order, but that is annoying friction. Since the language does not compose well, you need to keep most of the query in your head and cannot build it up piecemeal as easily as something like PRQL (https://prql-lang.org/ https://prql-lang.org/) [0] Although, it would be incredible if I could write timestamp formatting without having to look up the bespoke vendor incantation every time I switch dialects.
- DenisM 24d ago
  Does CTE not allow composability?
goatlover 24d ago
Not even an old man rant SQL isn't that hard to learn. I never had a problem with the syntax. Not everything needs to look like C. Remember when every complained about Python's whitespace indenting? Seems like everyone got over it.
zbentley 24d ago
The difficulties that even experienced programmers have with SQL are far more than just the syntax. And, given what most people need the database for, that difficulty is pretty disproportionate to the complexity of the task. I think the “it’s just syntax bro, learn it!” critique is about as ill-fitting as the claim that embedding a scripting language in a larger program is pointless because “assembly/C89 is just syntax bro, learn it!”
- grebc 24d ago
  I take what you’re saying about difficulty being disproportionate to the task as an indicator of ability. It’s literally so damn simple to knock out a database & some crud functions either as a desktop app or a website that the complaints in this thread are hilarious.
  - zbentley 24d ago
    That comes across as arrogant and rude. Assuming you actually want to engage, I discussed some of the reasons that this can be hard here: https://news.ycombinator.com/item?id=49411927 https://news.ycombinator.com/item?id=49411927 The link in the top comment further expands on the cognitive overhead: https://www.scattered-thoughts.net/writing/against-sql https://www.scattered-thoughts.net/writing/against-sql Particularly relevant is the part of that link which discusses having to pervasively refactor queries to add even a simple synthetic join or computed column. That’s a pain in the ass even for experienced DBAs, and is fundamentally not time well spent for row-at-a-time cases that are often, as you said, simple CRUD. Are you sure you aren’t overfitting based on working on only one small, simple subset of the things people commonly use SQL for?
    - grebc 24d ago
      The example of pervasive refactor is a bit of a contrived example to be honest. Get the id of the record you're discussing with your pre-conditions and then retrieve the data you're after. At least in SQL Server select x2 from foo group by x+1 as x2 you'd use select x+1 as x2 from foo group by x. I've read your article and it's written well enough, I'm just not sure that's as big a hit piece as you think it is nor do I think here is the place to post a full rebuttal. >Are you sure you aren’t overfitting based on working on only one small, simple subset of the things people commonly use SQL for? I think on the contrary that esoteric features not used as commonly utilised deserve to be esoteric to use. The common path should be the easiest. That SQL is used by different professions and not just IT related ones is testament to a good language. You won't find BA's using C to write reports for instance. There's A LOT of value in that.
euroderf 24d ago
Is it really THAT terribly difficult to replace "SELECT vars FROM table..." with "FROM table SELECT vars...", so that tools can provide suggestions ?

YuechenLi 25d ago

I agree, yeah, SQL syntax is awful. But the easier solution is what pretty much what backend has converged on, have something in your backend programming language that lowers to SQL so you never have to write any raw SQL at all except as a low-level escape hatch, so that in most instances SQL just becomes an IR that nobody really needs to think about in normal application code.