A better SQL in 11 lines of code

#1

Post by remywang » Sat, Aug 29, 2026, 5:13 PM UTC

A better SQL in 11 lines of code
prela-lang.org

Re: A better SQL in 11 lines of code

#2

Post by prathje » Sat, Aug 29, 2026, 7:02 PM UTC

Interesting concept which reminds of the operations available in pandas.

I disagree though with the statement of SQL needing 20 lines. The given query feels verbose and has lots of redundant conditions. Not saying that it is short but a better analogy could look like this:

SELECT DISTINCT an.name, t.title

FROM keyword k

JOIN movie_keyword mk ON mk.keyword_id = k.id

JOIN title t ON t.id = mk.movie_id

JOIN movie_companies mc ON mc.movie_id = t.id

JOIN company_name cn ON cn.id = mc.company_id

JOIN cast_info ci ON ci.movie_id = t.id

JOIN aka_name an ON an.person_id = ci.person_id

WHERE k.keyword = 'character-name-in-title' AND cn.country_code = '[us]';

Re: A better SQL in 11 lines of code

#3

Post by kscarlet » Sat, Aug 29, 2026, 7:07 PM UTC

Cool language! I thought dplyr and datalog are both local optima (forget about the three-letter abomination) but I now declare this language the global optimum of query language.

> In contrast, Prela can be implemented extremely close to the metal. The Rust implementation inlines operators and compiles them into tight fused loops over raw arrays, running several times faster than DuckDB even without a query optimizer.

This will be true in Common Lisp as well. Now someone just have to implement it.

Or maybe I should steal the syntax and compile to SQL first, just so people can use existing DBMS.

Re: A better SQL in 11 lines of code

#4

Post by kscarlet » Sat, Aug 29, 2026, 7:16 PM UTC

kscarlet wrote: post #3

Cool language! I thought dplyr and datalog are both local optima (forget about the three-letter abomination) but I now declare this language the global optimum of query language. > In contrast, Prela can be implemented extremely close to the metal. The Rust implementation inlines operators and compiles them into tight fused loops over raw arrays, running several times faster than DuckDB even without a query optimizer…

On second thought, some skepticism on performance comparison:

1. do both systems access everything from memory?

2. do both systems have the same kind of indices?

3. do either system tradeoff scan performance for faster/acceptably fast updates?

Re: A better SQL in 11 lines of code

#5

Post by bradleyy » Sat, Aug 29, 2026, 7:24 PM UTC

I'm afraid I'm in the "uses column store" and not "understands the actual storage mechanisms", but this feels like something that's essentially the same thing?

Yes, I could ask my local AI, I'm just curious if anyone here's wondering the same thing.

Re: A better SQL in 11 lines of code

#6

Post by trueno » Sat, Aug 29, 2026, 7:27 PM UTC

am i the only one who's not afraid of sql taking up lines? sql thats formatted well is beautiful to read my brain enjoys it. it's way easier to read sql in terms of "what resultset is this trying to build" then it is to pick apart some fluent api lookin orm on top of sql

Re: A better SQL in 11 lines of code

#7

Post by mwcremer » Sat, Aug 29, 2026, 7:28 PM UTC

Looks a lot like 6NF (https://en.wikipedia.org/wiki/Sixth_normal_form)

Re: A better SQL in 11 lines of code

#8

Post by slowcache » Sat, Aug 29, 2026, 7:30 PM UTC

trueno wrote: post #6

am i the only one who's not afraid of sql taking up lines? sql thats formatted well is beautiful to read my brain enjoys it. it's way easier to read sql in terms of "what resultset is this trying to build" then it is to pick apart some fluent api lookin orm on top of sql

I'm in this boat, especially if you're language supports multi-line strings

Re: A better SQL in 11 lines of code

#9

Post by slowcache » Sat, Aug 29, 2026, 7:40 PM UTC

I think an important benefit of a good ORM is to reduce the translations that you have to do between your mental model of the data and what you are trying to do with the data.

Before I started working a lot with SQL, ORMs fit my mental model better since I was more used to imperative programming languages and I thought they were easier to work with.

Now that I am very comfortable with SQL, I have to translate an ORM into the SQL that it would produce. So now they just add another step in between me and the data

Re: A better SQL in 11 lines of code

#10

Post by mamcx » Sat, Aug 29, 2026, 7:45 PM UTC

trueno wrote: post #6

am i the only one who's not afraid of sql taking up lines? sql thats formatted well is beautiful to read my brain enjoys it. it's way easier to read sql in terms of "what resultset is this trying to build" then it is to pick apart some fluent api lookin orm on top of sql

I also work on this area (https://tablam.org) and have used languages where this weird, poorly developed language SQL was not the main interface (FoxPro).

Think on this: You imagine yourself writing a regular website with ONLy sql? no, because SQL is not a "programming language" for developers.

Is possible you could think in various ideas about why is "nonsensical" to make an app with a relational language (that SQL clearly is not) but is the same as with OOP or functional: there is not reason to be a problem, and there is a lot of things that will be far easier if a proper relational language is used, like for example, is unnecessary and ORM and/or is not complicated and confusing to make one.