I started this project mid 2019, with the goal of creating a database interface that I would actually enjoy using, rather than dread. By that point, I've done several machine learning and data engineering projects, all of which used SQL, and I felt like I spent way too much time wrestling with "data plumbing" and SQL's antics, instead of being able to focus on the data itself. So, I set out to fix it, and created Preql.
I chose a unique approach, which is to create a new programming language, that compiles to SQL. That way, it could access all of the good that SQL has to offer (and there is plenty), but with all the features of a modern language, and without the design limitations of ORMs. It allowed me to add sorely missed features like first-class functions, modules, and type safety.
I built Preql in Python, which allows for a very smooth interface between the two. For parsing, I used a library called Lark, which I created three years ago. I also created a new library called Runtype, which proved very helpful for writing the compiler.
While Preql is still in its early stages, I'm very proud of what I've accomplished so far, and I hope you'll decide to take it out for a spin.
I feel like Preql makes SQLAlchemy and other ORMs obsolete. And I think it's also ready to replace pipelines that are plain SQL, although probably with the help of a few escape hatches (via its SQL() function).
There are many worthwhile GUI tools for data analysis, which stand on their own. But perhaps they could benefit from having an embedded Preql console.
I believe this is the right way to solve the ergonomic issues SQL has. Once you have something like this though I think there is a real risk of it becoming more than just a sugar/ergonomics layer where it’s trying to optimize or rewrite queries. Perhaps the write approach is to take a similar stance to the TypeScript compiler and draw a line in the sand.
Also I like the syntax for defining the schema - it reminds me of GraphQL.
> I think there is a real risk of it becoming more than just a sugar/ergonomics layer
I'm not sure it's actually a risk. The improvements to optimization in C compilers have benefitted everyone, though it took C a long while to be better at it than humans. I think the same idea applies here, as long as we choose our abstractions and optimizations carefully.
> it reminds me of GraphQL
Good catch, GraphQL has been one of my inspirations.
I started this project mid 2019, with the goal of creating a database interface that I would actually enjoy using, rather than dread. By that point, I've done several machine learning and data engineering projects, all of which used SQL, and I felt like I spent way too much time wrestling with "data plumbing" and SQL's antics, instead of being able to focus on the data itself. So, I set out to fix it, and created Preql.
I chose a unique approach, which is to create a new programming language, that compiles to SQL. That way, it could access all of the good that SQL has to offer (and there is plenty), but with all the features of a modern language, and without the design limitations of ORMs. It allowed me to add sorely missed features like first-class functions, modules, and type safety.
I built Preql in Python, which allows for a very smooth interface between the two. For parsing, I used a library called Lark, which I created three years ago. I also created a new library called Runtype, which proved very helpful for writing the compiler.
While Preql is still in its early stages, I'm very proud of what I've accomplished so far, and I hope you'll decide to take it out for a spin.
what part of a data stack / pipeline would you see this replacing?
I feel like Preql makes SQLAlchemy and other ORMs obsolete. And I think it's also ready to replace pipelines that are plain SQL, although probably with the help of a few escape hatches (via its SQL() function).
There are many worthwhile GUI tools for data analysis, which stand on their own. But perhaps they could benefit from having an embedded Preql console.
I would guess the SQL query parts
I believe this is the right way to solve the ergonomic issues SQL has. Once you have something like this though I think there is a real risk of it becoming more than just a sugar/ergonomics layer where it’s trying to optimize or rewrite queries. Perhaps the write approach is to take a similar stance to the TypeScript compiler and draw a line in the sand.
Also I like the syntax for defining the schema - it reminds me of GraphQL.
> I think there is a real risk of it becoming more than just a sugar/ergonomics layer
I'm not sure it's actually a risk. The improvements to optimization in C compilers have benefitted everyone, though it took C a long while to be better at it than humans. I think the same idea applies here, as long as we choose our abstractions and optimizations carefully.
> it reminds me of GraphQL
Good catch, GraphQL has been one of my inspirations.
I’m really surprised this is the first project like this for SQL I’ve seen.
Good stuff