The worse realisation:
THERE IS NO HASKELL OR PYTHON OR JAVA OR EVEN C FOR RELATIONAL DATABASES
Of all the possible interfaces for all our data, we went with the COBOL-like one. Fake English sentences. As strings. That you have to generate and parse at runtime.
And stuck with it for 40 years, because if there's one thing we programmers are great at, it's reinventing and reengineering everything that's even faintly inefficient, amirite
@natecull My brother spoke very clearly on this: "Why are we speaking to databases in sentences?"
It would be much better if we could speak to databases on some general-purpose AST, be that canonical s-exps or heck even json. Something with structure.
That we're having to encode rules to avoid "little bobby tables" security risks in every language is bonkers.
@cwebber @natecull Isn't this solved by libraries like SQLAlchemy Core? Any text protocol might have attacks like SQL injections; I have seen code not escaping ' in JSON, there are attacks on apps accepting newlines in HTTP headers. Or is the problem in libraries (not protocols and languages) treating SQL/HTML/... as text?
@mtjm @natecull JSON has a realtively consistent structure that can be parsed in a few hundred lines of code.
However, SQL: http://www.more-magic.net/posts/lispy-dsl-ssql.html
@cwebber @natecull It looks easier with writers only, not parsers, in client libraries. Cases like PostgreSQL getting a new feature, or implementing such a library in a new programming language, are very good arguments for a consistent protocol syntax. (Or being able to hack tools for e.g. generating a smaller query reproducing a bug.)