10 ms·
I don't think SQL is particularly crufty, but I'm willing to admit that's highly debatable -- depends on your definition of "crufty," really. However, the exam
by JohnBooty 7y ago
I don't think SQL is particularly crufty, but I'm willing to admit that's highly debatable -- depends on your definition of "crufty," really.
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.
Nearly all of the examples in the linked article are based on core SQL sorting and grouping concepts (with a sprinkle of trivalue NULL logic) that have been around since Day One.
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.
- nmyk 7y agoThere are parts of SQL that are crufty by that definition. For example, COMMIT; and COMMIT WORK; are two different statements that do the exact same thing according to the SQL standard. Perhaps trivial cruft but cruft nonetheless.
- JohnBooty 7y agoI personally wouldn't say that example fits the "getting in the way" part of the definition. 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! =)