Ah, nothing quite like a rant to air some heartfelt observations. I approve of the honesty you've expressed here so I'll try to merely give views based on my experience. I'll apologise ahead if I come across as too "teachy".
With a list of ten things there, I'll use a series of response posts wherever I think I have something to say rather than attempting it all in one go.
So, #1 SQL Syntax
I think it's fair to say that the syntax of SQL is a bit of a mess. It's clearly just evolved and meandered over the years and we're probably lucky that it has not become utterly dreadful.
That said:
I can't think of any languages that tolerate lists with a dangling comma - with this applying to both your examples;
the usage of single and double quotes took some time to evolve into the semi-standard of now. Their usage varies a lot among programming languages so there's no single comparison to make with all those. I still deal daily with two dialects with contrasting approaches (more on this later). In quite a few dialects they were interchangeable. The main need for them comes from two issues:
not really having reserved words - that would disallow a column named "from" or "table" - therefore the quotes let you be clear that you didn't mean the reserved word;
allowing for column/table names with spaces in them (me, I would have just said No to that, but once any of them allowed it then the others would all need to as well)* ;
regarding multiple WHERE clauses I'm guessing you think it's obvious that having more than would be an AND combination. From where I sit, neither AND nor OR are more obvious than the other, so I'm happy we have to be clear about which is being used. As we'll see later, WHERE has a more distinct meaning than just limiting things.
Expressions of angst are one thing, but declaring features you don't (yet) like as "errors" is overreach when you're not showing how you'll avoid inconsistencies. For example you don't indicate which interpretation you think should be made for your dangling commas. I can easily imagine two versions of you with different obvious opinions:
In one, the dangling comma should just be ignored as if you didn't mean it;
In another, it obviously implies a NULL expression as an extra column.
The funny thing, in teaching many people SQL over the years it is the latter that I've had instructees suggest as obvious - often when the SELECT was just for supplying an INSERT - and who then disliked the bother of doing CAST( NULL AS INTEGER) such as is often required by various parsers or engines.
As for "syntax rules also don’t add much" I would mainly say - they add clarity (to a degree anyway). When you work with millions (and even billions) of rows, that clarity is more than just handy.
p.s. actually there are some gnarlier issues that you may not have encountered yet. I have a habit of putting CASE expressions inside their own brackets () because some dialects can't parse them when nested inside more expressions e.g. 3 + ( CASE WHEN col = 'A' THEN 1 ELSE 0 END )
* a curious reality about SQL is that it's not unusual to be using dialect A to deal with tables/columns constructed with a dialect B. While the early waves of relational databases locked their tables within their own engines, soon APIs and drivers enabled engines to access each other's tables. This isn't just a problem about databases, one runs into similar problems with file systems - a reason to use Linux to fix Windows systems is to avoid the latter having some impossible filenames (a whole other topic that).
Hi @geraldew
- thanks for the detailed responses! I'll try to answer them one by one, but I want to mention that I appreciate the conversation!
Ok here goes
I can't think of any languages that tolerate lists with a dangling comma - with this applying to both your examples
Are you talking about Query languages, specifically? Because this is a feature in many modern programming languages, including Ruby & Python
the usage of single and double quotes took some time to evolve into the semi-standard of now. Their usage varies a lot among programming languages so there's no single comparison to make with all those. I still deal daily with two dialects with contrasting approaches (more on this later). In quite a few dialects they were interchangeable. The main need for them comes from two issues:
I agree there is a need to specify identifiers, and I do believe that backticks would be much more useful than double quotes. Theoretically this type of feature could be behind a feature-flag to preserve backwards compat.
Expressions of angst are one thing, but declaring features you don't (yet) like as "errors" is overreach when you're not showing how you'll avoid inconsistencies. For example you don't indicate which interpretation you think should be made for your dangling commas. I can easily imagine two versions of you with different obvious opinions:
The fix here would be to ignore everything past the dangling comma. This is the expected behavior in many modern programming languages. Expecting a dangling comma to have a null in either a CTE or select block seems very strange and unexpected.
As for "syntax rules also don’t add much" I would mainly say - they add clarity (to a degree anyway). When you work with millions (and even billions) of rows, that clarity is more than just handy.
I do believe there's a tradeoff between clarity and UX. In this case, I believe the tradeoffs for better usability are worth it.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
Ah, nothing quite like a rant to air some heartfelt observations. I approve of the honesty you've expressed here so I'll try to merely give views based on my experience. I'll apologise ahead if I come across as too "teachy".
With a list of ten things there, I'll use a series of response posts wherever I think I have something to say rather than attempting it all in one go.
So, #1 SQL Syntax
I think it's fair to say that the syntax of SQL is a bit of a mess. It's clearly just evolved and meandered over the years and we're probably lucky that it has not become utterly dreadful.
That said:
Expressions of angst are one thing, but declaring features you don't (yet) like as "errors" is overreach when you're not showing how you'll avoid inconsistencies. For example you don't indicate which interpretation you think should be made for your dangling commas. I can easily imagine two versions of you with different obvious opinions:
The funny thing, in teaching many people SQL over the years it is the latter that I've had instructees suggest as obvious - often when the SELECT was just for supplying an INSERT - and who then disliked the bother of doing
CAST( NULL AS INTEGER)such as is often required by various parsers or engines.As for "syntax rules also don’t add much" I would mainly say - they add clarity (to a degree anyway). When you work with millions (and even billions) of rows, that clarity is more than just handy.
p.s. actually there are some gnarlier issues that you may not have encountered yet. I have a habit of putting CASE expressions inside their own brackets
()because some dialects can't parse them when nested inside more expressions e.g. 3 + ( CASE WHEN col = 'A' THEN 1 ELSE 0 END )Hi @geraldew - thanks for the detailed responses! I'll try to answer them one by one, but I want to mention that I appreciate the conversation!
Ok here goes
Are you talking about Query languages, specifically? Because this is a feature in many modern programming languages, including Ruby & Python
I agree there is a need to specify identifiers, and I do believe that backticks would be much more useful than double quotes. Theoretically this type of feature could be behind a feature-flag to preserve backwards compat.
The fix here would be to ignore everything past the dangling comma. This is the expected behavior in many modern programming languages. Expecting a dangling comma to have a
nullin either a CTE orselectblock seems very strange and unexpected.I do believe there's a tradeoff between clarity and UX. In this case, I believe the tradeoffs for better usability are worth it.