[listenallyall]

I can understand that the statement order can be awkward, such as choosing what to select before the source.

But help me with "more concise". SQL has no boilerplate, its keywords are brief, you express the exact logic of the result set you're seeking. There are tons of SQL overlays or replacements embedded in programming languages or BI/reporting tools, and they are universally, more difficult to work with than straight SQL.

[temporarely]

There is a paper at the end of this link trail and that paper discusses everything that is wrong with SQL including concision.

https://news.ycombinator.com/item?id=39798528

et voila: https://www.cidrdb.org/cidr2024/papers/p48-neumann.pdf

see their comments on WITHIN GROUP and redundant declaration of identifiers. As for boiler plate, SQL's turf war over plain English words as reserved names creates this interesting situation of boiler plate identifiers in SQL to disambiguate from reserved keywords.

[listenallyall]

This is nothing more than one guy's opinion dressed up to look like an academic study. He actually admits a few times that SQL features are concise. SQL definitely isn't perfect, and some vendors' implementations are better than others, but things like JOINs are pretty perfect. He considers specifying an INNER JOIN as syntactic sugar (over using WHERE equality), which seems backwards, as opposed to a more consistent practice of always using the JOIN keyword regardless of the type of join.

[pkkm]

That one was more of a nitpick, so maybe I shouldn't have included that. What I had in mind was that I would like a bit more symbols instead of words, for example value IN [1, 10] instead of value BETWEEN 10 AND 10.

Some operations on groups are also too verbose, like getting top 5 items in each group.

[listenallyall]

IN already has a different meaning. BETWEEN 1 AND 10 is exactly how a human would describe it to another person.