1–10 of 14 posts
Show HN: Prela – Purely Algebraic Relation Combinators
github.com
Not really, too many obscure symbols.
Certainly learnable but I wouldn't say immediately readable.
Morel is an ML dialect that can compile set-producing expressions into bytecode that Calcite can execute against databases
Sort of like "If you could query anything with SQL but it's ML instead"
I bring this up because the example query looks very similar to Morel queries
Neat xample of solving a combinatorial optimization problem with a single query that he posted recently to Twitter:
I wonder though, is such a dialect better for agents? Have you tried to measure if an agent performs better expressing queries in such a language instead of SQL?
SQL, JS, Excel are really hard to substitute because of how widely used they are by people. Even if something new comes up that it's objectively better, so far has always failed gaining traction because of this reality. I wonder though, is such a dialect better for agents? Have you tried to measure if an agent performs better expressing queries in such a language instead of SQL?
SQL, JS, Excel are really hard to substitute because of how widely used they are by people. Even if something new comes up that it's objectively better, so far has always failed gaining traction because of this reality. I wonder though, is such a dialect better for agents? Have you tried to measure if an agent performs better expressing queries in such a language instead of SQL?
Claude had no problem translating SQL into Prela, and because you have fine grained control over the query plan (a Prela query is a plan), it was able to optimize queries to be very fast
Do you think it would be possible to offer Prela as a direct interface to a relational database?
SQL, JS, Excel are really hard to substitute because of how widely used they are by people. Even if something new comes up that it's objectively better, so far has always failed gaining traction because of this reality. I wonder though, is such a dialect better for agents? Have you tried to measure if an agent performs better expressing queries in such a language instead of SQL?
Claude had no problem translating SQL into Prela, and because you have fine grained control over the query plan (a Prela query is a plan), it was able to optimize queries to be very fast
> Prela queries are readable even to those new to the language Not really, too many obscure symbols. Certainly learnable but I wouldn't say immediately readable.
Earlier quoted context omitted.
Claude had no problem translating SQL into Prela, and because you have fine grained control over the query plan (a Prela query is a plan), it was able to optimize queries to be very fast
Having control over the execution plan is super interesting ! This is a very common frustration when writing SQL. Do you think it would be possible to offer Prela as a direct interface to a relational database?
Earlier quoted context omitted.
Claude had no problem translating SQL into Prela, and because you have fine grained control over the query plan (a Prela query is a plan), it was able to optimize queries to be very fast
I'm more curious about going from text to Prela instead of going from text to SQL and measuring any difference in the performance there. On one hand models have been trained on a lot of SQL on the other hand they are really good in mathematical reasoning too so thinking in Perla might be a natural fit for them.