4 ms·

What went into the decision to use the DSL that you did, versus (for example) SQL? I always miss writing SQL queries, so I got excited when I initially thought

• obi1kenobi 4y ago
  SQL is kind of a monster language to parse properly[1], and has some unfortunate and confusing edge cases[2]. It would have cost a ton of time and energy to implement properly, and all it would have ended up with is "SQL but worse." SQL is also really awkward around APIs, since API norms and schemas don't map cleanly to SQL tables and JOINs. For example, many APIs take arguments, and while the most natural way to express an API call in SQL is as a SELECT or JOIN, requiring user-provided arguments there is really clunky. Worse, if the API that takes an argument sets a default value if that argument is not provided, then you end up in a situation where a `SELECT * FROM API` can return fewer results than a `SELECT * FROM API WHERE <some predicate>`. Using a new language meant that I could design it to best highlight Trustfall's capabilities with minimal work. Trustfall's core is language-agnostic, so it should be possible to put a new language parser in front of it in the future -- including SQL. So I haven't ruled it out forever, I just didn't want the first thing I built to be "SQL but worse" because it's in a domain poorly suited for it. [1]: https://twitter.com/sc13ts/status/1413729761247916036 https://twitter.com/sc13ts/status/1413729761247916036 [2]: https://www.scattered-thoughts.net/writing/select-wat-from-sql/ https://www.scattered-thoughts.net/writing/select-wat-from-s...