I have to say, I strongly disagree on this point. I am a coder who works in a variety of languages build on many paradigms, of which SQL is one of my most enjoyable. I agree that the creation of schemas can be painful, but SQL's almost Prolog level of declaration can be beautiful in certain problem spaces. It is unfortunate that the current state of query optimizers leads to leaky abstractions where one must rearrange queries to allow for efficient execution. Still, I have had a great deal of success introducing SQL to otherwise nontechnical people, and they also love the fact that one can describe the solution you desire as opposed to instructing the computer on how to get there. These people particularly benefit from the almost English nature of the language, and I feel I have no right to complain about any syntax with a `use Perl;' background on my desktop.

Thats interesting considering Cassandra moved to CQL (their SQL-like language) and theres a ton of work in the Hadoop stack on SQL-like languages (Hive, Pig, Presto)

What's wrong with SQL?

It tries to be like english, but it is anything but. It has a complicated irregular grammar. It has an implicit structure that is hard to guess if you don't already know. People write huge bloated ORMs to try to run away from it. Your application needs to have code in it to do a bunch of string concatenation if you don't use one.

It is a bad language.

EDIT: It is completely preposterous that SQL injection is even a thing.

Every once in a while, though, it does something really cool. The declarativeness is cool, IMO; I always appreciate inline conditionals. That's something I would want to be carried over to a replacement.

The language. Really the problem with SQL is the API. I like having a relational database, but SQL strings are a really crummy way of writing to it.

What's so crummy about variable interpolation?

    def insert_person(first_name, last_name)
      sql.query("insert into persons values(#{first_name}, #{last_name})")
    end

So long as you're not plugging form data directly into that function, that works just fine.

What happens when you have to deal with a crazy pop star with a " in his (real, legal, you-are-the-unreasonable-one-for-demanding-something-else) name? (This is ignoring the myriad of issues that come with parameterizing names into "first name" and "last name" in the first place, but that's a separate thing.)

This is what binding variables is for, but to use them you're either writing for specific platforms (PSQL, Oracle SQL, etc), or you're using middleware that hides the raw SQL from you.

This is a problem with the string domain, not with SQL. You'd have it no matter what data persistence method you use. The answer is to put logic between that function and your form data puller.

Then don't use SQL strings? There are many, many ORMs that abstract SQL strings to objects and relations.

Actually I think the problem are the developers that don't take the time to properly learn it.