SQL is indeed pretty crufty. After all, it dates back to the 70's, and is generally regarded as an 'entry level' language for analysts.
It's nowhere near as crazy as Javascript (and, arguably, Ruby):
It's nowhere near as crazy as Javascript (and, arguably, Ruby):
However, the examples in the linked article are not examples of cruft.
I'm using this example of "cruft":
Cruft is a jargon word for anything that
is left over, redundant and getting in the
way. It is used particularly for defective,
superseded, useless, superfluous, or dysfunctional
elements in computer software.
I also don't think they really illustrate flaws/gotcha/etc in SQL itself. Nor were they meant to, I don't think... these highly pathological examples are examples of the sorts of pathologically ambiguous things a compiler needs to handle, but are not representative of anything I've seen in 20+ years of real world SQL experience.
Perhaps trivial cruft but cruft nonetheless.
As a user, I've been using SQL for many years and it's never been in the way. It's really just a syntactic alias, so I can't imagine it really impedes the work of the folks maintaining RDBMS's under the hood.
But, I wouldn't argue either. Like you say... I suppose that, however tiny, the burden is non-zero! =)
I would argue that SQL itself isn't very crufty. Rather, it's fairly simple and well thought out since it's based on many years of thought and consideration from the creators of the relational database model. E.F. Codd, for one, wrote at length about how these models can work for years before SQL appeared, refining the concept for maybe a decade afterwards. His goal was to make a system that made it easy for developers to store and request information with as little redundancy as needed.
Vendors and developers of database systems have implemented various functions and features that expand on or alter SQL, but those are reflections more on those particular systems rather than on SQL. For example, MySQL's GROUP BY does not verify if the extra columns in the selectlist are dependent on the group by columns, which is against SQL's definition. It wouldn't make sense to count that as an issue with SQL itself.