I really really want this to take off. SQL sucks. No, I do not care if relational algebra is beautiful, or simple, or represents some other mathematical purity which makes it the best way to represent data. SQL, as implemented, is a rough language which makes too many things difficult.
Unfortunately, it is really difficult for me to lean against this for anything “real” without more years of battle testing. Queries have to be right. I do not want something to blow-up one day because the translation hit a buggy edge case. SQL has many flaws, but everyone knows it. Nobody ever got fired for writing SQL.
SQL does have faults but PRQL is not fixing any of those and instead is just a python-esque version that retains all the SQL faults and introduces additional complexity without providing much in return.
Main complaints about SQL are that SELECT comes before FROM and that there are too many dialects.
The SELECT part is only partially valid when writing the query but it is much nicer/easier to read than FROM first options presented elsewhere. This same issue plagues majority of programming languages, most of which optimise for terse syntax that is easy to write but painful to read even when most of the time reading is what people need to do when writing in a programming language.
Dialects is a silly one. Programmers treat databases as interchangeable back end instead of foundation of the data storage. No-one ever even thinks about complaining that you can't swap C for Python or Java without major rewrite yet these languages are nothing but glue between database and UI that SHOULD be interchangeable at any time.
To my untrained eyes, SQL did not appear to have things like windowing, hierarchical relationships, (trees, graphs) in mind when initially designing the language.
Support for these things have been wedged into the language by numerous additions, and I think the fundamental syntactical framework of SQL is cracking under the pressure. Granted, it's been a while since I've had to traverse a tree using SQL, but I do recall that the query was very painful to write, and even more painful to execute efficiently.
Also, these things only work if you've wedged your data model into rows and columns. (or you use non-standard language extensions like jsonb)
PRQL, on the other hand, rearranges the syntactical structure to be more extensible, and also agnostic over the underlying shape of the data model. It works the same regardless of whether you're using an RDBMS or a graph/document database.
Is the result more complicated? IMO, only in the simplest examples. PRQL shines vs SQL when you have multiple stages of aggregation, like pre and post aggregation filtering, or referencing synthesized data, etc.
is how graph/tree queries work in modern SQL (assuming you aren't using something like ltree [0]. The first part of the recursive CTE identifies the root record and then UNION ALL with the subsequent items referencing what came before.
Is it as easy as a Cypher query in Neo4j? Not all all. But it is arguably more flexible in that you can represent far more data structures and link to non-graph data easily.
I just unwrapped nested JSON columns into a flat key-value set with it last week. It's deceptively powerful.
> No-one ever even thinks about complaining that you can't swap C for Python or Java without major rewrite yet these languages are nothing but glue between database and UI that SHOULD be interchangeable at any time.
One of the main benefits of Python is that you can easily swap it for C. 95% of the stuff I do in Python every day is only possible due to existence of numpy.
And in general programmers care about interop a lot. Interop with C was, obviously, one of the main points of C++. One of the benefits of JVM languages like Kotlin or Scala is simple bidirectional interop with Java.
Docker became so popular because you can simply containerize your app and run it anywhere without being tied down to specific requirements of your environment.
Yeah, SQL has plenty of flaws but PRQL does not seem to be fixing any of those and instead seems to be introducing new issues, e.g. what is up with 'derive country_code = s"LEFT(country, 2)"'.
This doesn't improve SQL for me at all. How exactly is this better than SQL? It still uses variables before they are even declared so the code flow is still all over the place. There still seems to be no real "coding" possible (function declarations, reuse, typed variables)
How can you possibly say that this is any better than SQL? SQL is bad but this doesn't improve it.
What really feels better would be this but unfortunately it's proprietary and only for one specific database: KQL (kusto query language)
I am a simple man, and I do not think of SQL in terms of relational algebra. I was inelegantly attempting to cutoff the SQL proponents who will say that SQL is fine because relational algebra is such a beautiful model.
Yes, SQL can do everything. That being said, I wish the syntax were significantly cleaner and composable.
For an alternative, GraphQL-like take on a related problem ("efficiently query any combination of data sources, from APIs to DBs to raw files"), check out the Trustfall language mentioned in the sibling comment: https://news.ycombinator.com/item?id=34182125
It's used in multiple real-world applications, including a tool that is slated to be merged into cargo, Rust's built-in package manager (cargo-semver-checks, a semver linter).
SQL is not relational algebra. It's relational algebra, and various relational calculi, mixed up in an ugly way because they tried to make it look like natural language.
Unfortunately, it is really difficult for me to lean against this for anything “real” without more years of battle testing. Queries have to be right. I do not want something to blow-up one day because the translation hit a buggy edge case. SQL has many flaws, but everyone knows it. Nobody ever got fired for writing SQL.