I really like this idea! I wish I knew other data expression engines for js.
I feel like adding filtering languages into our http endpoints is one of those forever bespoke tasks. This is probably not the right form for tackling that problem, since it is a fairly complex query language & processor and doesn't cleanly map to something we'd use in a URL query string. But it makes me miss odata a little bit. And it makes me wish there were more visible popular options for data expression languages.
Love the idea, but I don't think this "built for [...] non-technical users" works. All the examples were more confusing to me vs a regular programming language and definitely not accessible to non-technical users.
Also, why would I want to compile to multiple languages? If I'm building a no-code platform, I won't bother supporting 3 different languages since I'm the only one seeing the code.
Not that it's super complex, but I'm surprised it didn't pick up an npm package. I wrote tarsec[1] and have been eyeing ohmjs[2]. And of course nearley is a classic.
It would be pretty nice to write those simple things in one language if you have a ruby server, react front end, and postgres database. You could target different parts of the stack but think/implement in one language. Seems nice to me.
I coincidentally worked on something similar but I kept closer to the SQL standard. It grew out of business cases where you don't have strongly typed data to act on.
I more or less adopted the syntax from dumbql (https://github.com/tomakado/dumbql) and started off with a peg parser using ohm.js. As I started benchmarking I realized how slow it was and started looking for "fast paths" using regex. I ultimately resorted to a recursive descent parser similar to Elo. At that stage I already had a lot of tests and api in place, so I was able to get a lot of help from Claude.
The base premise is the same: SQL is not a proper programming language and everyone knows it only because they have to. And I feel like everyone who knows SQL enough admits that, but still none of the 20+ attempts of a better language stuck on.
This looks amazing. We use Ruby, Javascript and SQL. I will try this out this week. Are you looking for contributors? What is your vision long term with this?
21 comments
[ 5.3 ms ] story [ 43.5 ms ] threadI feel like adding filtering languages into our http endpoints is one of those forever bespoke tasks. This is probably not the right form for tackling that problem, since it is a fairly complex query language & processor and doesn't cleanly map to something we'd use in a URL query string. But it makes me miss odata a little bit. And it makes me wish there were more visible popular options for data expression languages.
Might be an alternative with less complexity for a simple filtering use case.
I need to check what we will do in that case.
Also, why would I want to compile to multiple languages? If I'm building a no-code platform, I won't bother supporting 3 different languages since I'm the only one seeing the code.
Not that it's super complex, but I'm surprised it didn't pick up an npm package. I wrote tarsec[1] and have been eyeing ohmjs[2]. And of course nearley is a classic.
[1] https://github.com/egonSchiele/tarsec [2] https://ohmjs.org [3] https://nearley.js.org
I'm not sure we should continue to stack supposedly simple languages one on top of the other for ever. Why not learn SQL instead?
I more or less adopted the syntax from dumbql (https://github.com/tomakado/dumbql) and started off with a peg parser using ohm.js. As I started benchmarking I realized how slow it was and started looking for "fast paths" using regex. I ultimately resorted to a recursive descent parser similar to Elo. At that stage I already had a lot of tests and api in place, so I was able to get a lot of help from Claude.
Website here: https://filtron.dev
The base premise is the same: SQL is not a proper programming language and everyone knows it only because they have to. And I feel like everyone who knows SQL enough admits that, but still none of the 20+ attempts of a better language stuck on.
As someone would say: sad.