Good luck trying to get the joins to work though.

Not that joins in SQL use a particularly intuitive notation. At the very least it doesn't make it obvious you can usually swap the order of joins around without affecting the end result.

Joins can certainly work in a data format like YAML. For an example, see Honey SQL from the Clojure community [0] (though without something to contrast strings like Clojure's keywords, you miss out on the automatic parameterization).

You mentioned moving JOINs around, so I'll mention that if represented as structured data, you can move any of the top level components around, so you could more closely follow the "true order of SQL" [1]. For example, I would love to be able to put FROM before SELECT in all or almost all cases. There's also being able to share and add to something like a complicated WHERE clause, where essentially all programming languages have built-in facilities for robustly manipulating ordered and associative data compared to string manipulation, which is not well-suited for the task.

Now don't get me wrong, I don't particularly care for YAML (though it doesn't bother me that much), but as someone who's done their fair share of programmatic SQL creation and manipulation in strings, not having a native way to represent SQL as data is a mistake in my opinion.

0: https://github.com/seancorfield/honeysql#big-complicated-exa... 1: https://blog.jooq.org/a-beginners-guide-to-the-true-order-of...

Yeah those examples aren't really fixing the problem I was referring to, if anything they're making it worse.

What I was referring to is that 'SELECT * FROM A JOIN B ON f(A) = g(B)' and 'SELECT * FROM B JOIN A ON f(A) = g(B)' mean exactly the same thing, but this is not obvious from the language. This is especially iffy when you start joining even more tables together.

The equivalence is clear when you write out the corresponding diagram and note that the join is its limit, but your examples seem to make the same mistake SQL did by lumping together the join condition with one of the two tables.

Does it seem clear to you that a + b is equivalent to b + a? If you know the semantics of join operations (as you should to at least a basic degree if you're going to use them), the SQL notation above is just as clear as the arithmetic notation for addition.

To me the SQL notation is about as clear as a < b being equivalent to b < a.

Hm, maybe it's because I'm so used to SQL, but I had to lol about the yaml example, I think it's quite nasty to read and I'm glad that SQL looks different.

It can be abbreviated to

    SELECT: [num, name]
    FROM: [customers]
    WHERE EXISTS:
      SELECT: [name]
      FROM: [orders]
      WHERE:
        AND:
          - EQUALS: [customers.num, orders.customer_num]
          - LT: [price, 50]

It's not that different from formatted SQL. It's uglier, though, IMO, and more error prone. But to hate YAML for the fact that SQL looks less familiar in it, is a weird take.

> But to hate YAML for the fact that SQL looks less familiar in it, is a weird take.

True, it's a little side hustle that's funny but doesn't necessarily make much sense.

I guess the broader point they're driving at is that attempting to port familiar programming constructs to YAML DSLs will result in this kind of ugliness. If that's true though, it's a bit too subtle for my tastes.

'looks better' isn't 'works better', sadly.