4 ms·

Elo – A data expression language which compiles to JavaScript, Ruby, and SQL

104 points by ravenical 9mo ago

jauntywundrkind 9mo ago
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.
- blambeau 9mo ago
  Check finitio.io Might be an alternative with less complexity for a simple filtering use case.
Levitating 9mo ago
Third example on the site does not in fact compile to SQL
- blambeau 9mo ago
  SQL does not support lambda functions. I need to check what we will do in that case.
h1fra 9mo ago
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.
- swrobel 9mo ago
  Yeah, P30D as presumably intuitive to non-technical users has me chuckling Also, knowing that TODAY > signup + P30D transpiles to TODAY > signup + 30.days in Ruby. Which one is more readable?
  - ElectricalUnion 9mo ago
    Is this even valid ruby? Doesn't it need Rails-specific Active Support to work?
  - blambeau 9mo ago
    Point taken. Will see what I can do. Probably TODAY + Duration({ days: 30 }) would be a better example then.
fastball 9mo ago
Targeting Python, Ruby, and SQL seems impossible if you want certain features.
NetOpWibby 9mo ago
This looks perfect for people who desire terseness above all. The examples make my head hurt.
- blambeau 9mo ago
  Sorry about that
egonschiele 9mo ago
Maybe the most incredible part – did Claude write a recursive descent parser from scratch for this? https://github.com/enspirit/elo/blob/9f07fefcdf65c169089f123a2c0b684131b53dd7/src/parser.ts https://github.com/enspirit/elo/blob/9f07fefcdf65c169089f123... 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 https://github.com/egonSchiele/tarsec [2] https://ohmjs.org https://ohmjs.org [3] https://nearley.js.org https://nearley.js.org
- gatapia2 9mo ago
  That git commit is very impressive (for Claude) Edit: Oh, I think the main dev is just using Claude to do the commits (I guess to summarise changes, etc). It does not mean that Claude wrote all that code.
  - geoffschmidt 9mo ago
    FWIW, at the bottom of the landing page they credit Claude for “every line of code, tests, and docs”
  - blambeau 9mo ago
    Claude did, I swear The parser was built gradually though, with logs of increments under automated tests.
- torginus 9mo ago
  Recursive descent parsers are basically mechanical structures, if you get the grammar right (which encapsulates all the logic). When I was a CS student, they seemed like magic to me as well, but later I got to revisit them for a project at work, and finally managed to understand the logic. Imo, the biggest complexity in using them comes from how they handle operator precedence, with recursive nested expressions in the grammar, which I still don't find intuitive at all. If you decide to hand-roll your own parser/syntax today, I recommend you look at Pratt-parsers, they are much nicer to write by hand. Modern languages (Rust, Go) , ironically are much simpler to parse, since they defined the syntax in such a way that they can be parsed unambigously by looking 1-2 tokens ahead. And since all of them follow the same logic, AI has a ton of sources to learn from. I'm also working on my programming language, and AI assistants have been able to generate these parsers for well over a year.
cjohnson318 9mo ago
What would I use this for? Everything in the examples is pretty easy to do in scripting languages like Python, JS, and Ruby.
- digitaltrees 9mo ago
  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.
throwaway132448 9mo ago
The notion that this is for non-technical people is... wild. Curious to know who they've spoken to?!
- blambeau 9mo ago
  We should write power users, maybe. Peppol interconnecting No Code tools like Make and others
tgv 9mo ago
The compilation example contains an error. You should ask Claude what it is, because clearly you didn't find it yourself.
- blambeau 9mo ago
  Which one ?
cess11 9mo ago
Why would I teach this to someone instead of plain SQL?
- _s_a_m_ 9mo ago
  If nothing is going on at work this allows you to work overtime to find compilation issues, can't have enough redundant leaky abstractions in a project ..
_s_a_m_ 9mo ago
can't wait to never use this
bambax 9mo ago
SQL was also initially built for end users and not considered "code". 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?
- aerzen 9mo ago
  Because we already have databases we have to query and they speak only a dialect of SQL. If there were a lower-level machine-friendly instruction set for databases, it should target that.
jbergstroem 9mo ago
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 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 https://filtron.dev
- blambeau 9mo ago
  good to know. Should we join forces ?
aerzen 9mo ago
This is very similar to what I'm building: https://lutra-lang.org https://lutra-lang.org 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.
- blambeau 9mo ago
  Didn't know about it, thanks @aerzen
timwalz 9mo ago
[flagged]
digitaltrees 9mo ago
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?
deleted 9mo ago
[deleted]
gzuuus 9mo ago
[dead]

104 points by ravenical 9mo ago

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.

blambeau 9mo ago
Check finitio.io Might be an alternative with less complexity for a simple filtering use case.

Levitating 9mo ago

Third example on the site does not in fact compile to SQL

blambeau 9mo ago
SQL does not support lambda functions. I need to check what we will do in that case.

h1fra 9mo ago

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.

swrobel 9mo ago
Yeah, P30D as presumably intuitive to non-technical users has me chuckling Also, knowing that TODAY > signup + P30D transpiles to TODAY > signup + 30.days in Ruby. Which one is more readable?
- ElectricalUnion 9mo ago
  Is this even valid ruby? Doesn't it need Rails-specific Active Support to work?
- blambeau 9mo ago
  Point taken. Will see what I can do. Probably TODAY + Duration({ days: 30 }) would be a better example then.

fastball 9mo ago

Targeting Python, Ruby, and SQL seems impossible if you want certain features.

NetOpWibby 9mo ago

This looks perfect for people who desire terseness above all. The examples make my head hurt.

blambeau 9mo ago
Sorry about that

egonschiele 9mo ago

Maybe the most incredible part – did Claude write a recursive descent parser from scratch for this? https://github.com/enspirit/elo/blob/9f07fefcdf65c169089f123a2c0b684131b53dd7/src/parser.ts https://github.com/enspirit/elo/blob/9f07fefcdf65c169089f123... 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 https://github.com/egonSchiele/tarsec [2] https://ohmjs.org https://ohmjs.org [3] https://nearley.js.org https://nearley.js.org

gatapia2 9mo ago
That git commit is very impressive (for Claude) Edit: Oh, I think the main dev is just using Claude to do the commits (I guess to summarise changes, etc). It does not mean that Claude wrote all that code.
- geoffschmidt 9mo ago
  FWIW, at the bottom of the landing page they credit Claude for “every line of code, tests, and docs”
- blambeau 9mo ago
  Claude did, I swear The parser was built gradually though, with logs of increments under automated tests.
torginus 9mo ago
Recursive descent parsers are basically mechanical structures, if you get the grammar right (which encapsulates all the logic). When I was a CS student, they seemed like magic to me as well, but later I got to revisit them for a project at work, and finally managed to understand the logic. Imo, the biggest complexity in using them comes from how they handle operator precedence, with recursive nested expressions in the grammar, which I still don't find intuitive at all. If you decide to hand-roll your own parser/syntax today, I recommend you look at Pratt-parsers, they are much nicer to write by hand. Modern languages (Rust, Go) , ironically are much simpler to parse, since they defined the syntax in such a way that they can be parsed unambigously by looking 1-2 tokens ahead. And since all of them follow the same logic, AI has a ton of sources to learn from. I'm also working on my programming language, and AI assistants have been able to generate these parsers for well over a year.

cjohnson318 9mo ago

What would I use this for? Everything in the examples is pretty easy to do in scripting languages like Python, JS, and Ruby.

digitaltrees 9mo ago
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.

throwaway132448 9mo ago

The notion that this is for non-technical people is... wild. Curious to know who they've spoken to?!

blambeau 9mo ago
We should write power users, maybe. Peppol interconnecting No Code tools like Make and others

tgv 9mo ago

The compilation example contains an error. You should ask Claude what it is, because clearly you didn't find it yourself.

blambeau 9mo ago
Which one ?

cess11 9mo ago

Why would I teach this to someone instead of plain SQL?

_s_a_m_ 9mo ago
If nothing is going on at work this allows you to work overtime to find compilation issues, can't have enough redundant leaky abstractions in a project ..

_s_a_m_ 9mo ago

can't wait to never use this

bambax 9mo ago

SQL was also initially built for end users and not considered "code". 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?

aerzen 9mo ago
Because we already have databases we have to query and they speak only a dialect of SQL. If there were a lower-level machine-friendly instruction set for databases, it should target that.

jbergstroem 9mo ago

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 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 https://filtron.dev

blambeau 9mo ago
good to know. Should we join forces ?

aerzen 9mo ago

This is very similar to what I'm building: https://lutra-lang.org https://lutra-lang.org 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.

blambeau 9mo ago
Didn't know about it, thanks @aerzen

timwalz 9mo ago

[flagged]

digitaltrees 9mo ago

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?

deleted 9mo ago

[deleted]

gzuuus 9mo ago

[dead]