3 ms·
I hate these sort-of-well-known-language-but-not-really DSLs. Since they’re sort of the well known language, documentation is usually sparse, you never know how
by oefrha 3y ago
I hate these sort-of-well-known-language-but-not-really DSLs. Since they’re sort of the well known language, documentation is usually sparse, you never know how to deal with edge cases without trial and error. For instance, in the given example, how do you escape SQL keywords? How do you escape quotes in string literals? Even SQL dialects don’t necessarily agree on what’s allowed, never mind this DSL with a half-assed parser.
Not to mention this practically invites dumb string interpolation in SQL preparation, undoing decades of work to rid the world of this terrible habit. (Edit: This problem is solvable.)
Don’t try to be clever, use a structured format (JSON, protobuf, etc.) with a well documented schema.
Note that I’m only talking about APIs. It’s an entirely different matter if your product allows users to type in and send complex queries interactively.
- MissingNo_ 3y agoAye, and if you need a query language inside your API it's probably best to use one of the existing languages specifically made for this use case, like GraphQL
- sausagefeet 3y agoGraphQL does not solve the problem if the query language is user-facing. Additionally, GraphQL a pretty huge tech stack injection. Something like this is much simpler. So, it depends on the context of what you're making and why.
- ahoka 3y agoSQL is structured with a well documented schema.
- sausagefeet 3y agoI believe they mean that the language described in here is not really SQL. It looks like SQL. But the question is: what are the differences? Is it really like SQL?
- oefrha 3y agoIt’s a structured language (which programming language isn’t?*), not a structured format, as in data exchange format. * Forget about nascent LLM-interpreted natural language as programming language.