[jsiegz]

The central problem with SQL is a lack of modularity and reusability. The syntax is easy to learn, it's just onerous to do complex things.

Dev teams and analysts use text files, Gists, and emails to save hundreds of useful queries containing similar patterns, subqueries, and clauses that could easily be repurposed if the language had any reusability features. There's a lot of waste and it can feel like a big task to ask a simple question.

That said, it's very easy to learn SQL and the author's suggestions don't seem to maintain that learning curve. I disagree that "human language mimicking" is a problem -- SQL syntax actually makes a lot of sense (I'm "SELECTing FROM a table and ORDERing the results" etc).

What we need is a higher level language or tool to describe relations in a database -- something like an ORM or XML used in legacy BI tools. SQL still lives underneath. IBM Cognos, SAP Business Objects, Microstrategy, and others tried this to varying levels of success. Another commenter (siganakis) gets it right: "I would prefer a syntax layer that can be compiled / transformed back to SQL."

We're actually working on something very similar to that at Looker (http://looker.com) if anyone is interested in hearing more about it, but we aren't quite at the point where we can release the language spec to the world yet.

[siddboots]

> The central problem with SQL is a lack of modularity and reusability. The syntax is easy to learn, it's just onerous to do complex things.

From what I understand of it, the author here is describing a completely different avenue by which relational programming language could be made more powerful. Namely, through a higher-order type system. This is surely more powerful a proposal than merely providing a mechanism for modularity on top of SQLs existing interpretation of the relational model.

> What we need is a higher level language or tool...

ORMs and framework layers that compile to SQL have been around for decades, and while they do allow modularity, they remain a source of perennial dissatisfaction^1. Why is yet another such language or tool what we need?

If modularity and reusability really was "the central problem with SQL", surely the problem can be called solved given all of the existing solutions that you describe?

^1 http://blogs.tedneward.com/2006/06/26/The+Vietnam+Of+Compute...

[collyw]

SQL syntax is easy, but judging from co-workers and my own experience, it takes a fair bit of time to begin thinking in sets, and being able to do more complex queries (for example queries with the same table joined in more than once).

My team leader always describes the output as "if this, then that". SQL isn't imperative. I translate his ifs to wheres then I have a reasonable start on the query.

[ako]

You can use views to reuse SQL queries.