Thanks. Even on just that point, I disagree. I think they are equally readable. Just like Python and C# are equally readable to the respective cohorts that are used to programming in those languages.

Yes, EF queries are more readable to many developers who know C# well but don't want to get used to SQL. But the problem with that is DB apathy + EF leads to some real performance problems as systems scale that grinds the application to a halt with SQL queries longer than dissertations, to which the developers need a quick hack to fix. The query plan for those beasts is intractable. Which of the 10 table scans or index scans to tackle first? And how do you tackle it?

They discover "indexed views" and all is well until you start to have locking problems, so more hacks are needed. etc. By writing the damn SQL to begin with they'd have to tame the beast earlier on and address the design flaws in their schema and/or application.

Ok this is a bit of a strawman (although it is based on experience) but I think saying SQL is less readable is a red herring. It is more readable for a lot of use cases. It's a DSL designed for the job, you really can't get much better (except for Elastic Search use cases, etc.). It's slightly old fashioned but that's just fashion.

This isn't about ORMs or database performance. It's just a comparison of query languages, with LINQ being more natural for data models with lots of joins and nested records that are common today (especially since that's how people work with objects inside their programming language).

SQL is far from perfect. It would be nice to see some modern SQL dialects that follow the LINQ syntax and are natively supported by RDBMS.

Linq is horrible for outer joins, the syntax is completely unintuitive to the point that I’ll just use raw sql.

With a lot of nested joins, both options suck. You are best abstracting. So, likely a view.

> "Yes, EF queries are more readable to many developers who know C# well but don't want to get used to SQL."

My main field is databases. Been working with SQL for ~15 years. My knowledge of LINQ is much less than SQL (partly also because I was writing plenty of SQL before LINQ existed). I also think SQL is a big big mess full of leaky abstractions that forces you to do things in unituitive ways. And yet it is incredibly powerful. But don't listen to me. Read any book by C.J.Date (especially this one http://www.thethirdmanifesto.com/), for all the reasons SQL is poorly designed.

> "But the problem with that is DB apathy.....leads to some real performance problems....."

I completely agree. Databases are very powerful and more people should know how to properly use them so that the rest of us would have fewer headaches.

> " It's a DSL designed for the job, you really can't get much better"

The problem is that due to many reasons it is the only such DSL in wide spread use. Any alternatives are just footnotes.

"select id, name from ..."

"from c in customers select ..."

Fill in the blank. They're not equally readable to the IDE that's trying to provide $1,199 worth of code completion for a partially typed query.

Strictly, to the IDE they should both be equally readable. In many cases, an IDE could fill in the from just based on the columns selected.

Yeah give me raw sql any day: it’s far more readable to me than the unnecessary abstractions we write to make things easier