alt Hacker NewsThat comes across as arrogant and rude. Assuming you actually want to engage, I discussed some of the reasons that this can be hard here: https://news.ycombinator.com/item?id=49411927
The link in the top comment further expands on the cognitive overhead: https://www.scattered-thoughts.net/writing/against-sql
Particularly relevant is the part of that link which discusses having to pervasively refactor queries to add even a simple synthetic join or computed column. That’s a pain in the ass even for experienced DBAs, and is fundamentally not time well spent for row-at-a-time cases that are often, as you said, simple CRUD.
Are you sure you aren’t overfitting based on working on only one small, simple subset of the things people commonly use SQL for?
The example of pervasive refactor is a bit of a contrived example to be honest. Get the id of the record you're discussing with your pre-conditions and then retrieve the data you're after.
At least in SQL Server select x2 from foo group by x+1 as x2 you'd use select x+1 as x2 from foo group by x.
I've read your article and it's written well enough, I'm just not sure that's as big a hit piece as you think it is nor do I think here is the place to post a full rebuttal.
>Are you sure you aren’t overfitting based on working on only one small, simple subset of the things people commonly use SQL for?
I think on the contrary that esoteric features not used as commonly utilised deserve to be esoteric to use. The common path should be the easiest. That SQL is used by different professions and not just IT related ones is testament to a good language. You won't find BA's using C to write reports for instance. There's A LOT of value in that.