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
@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?
However, SQL: http://www.more-magic.net/posts/lispy-dsl-ssql.html
@natecull @mtjm I'd challenge you: what's the smallest, consistent parser and writer you can build for... let's make it "simple", and take a single Database's syntax. Write a universal parser and writer for all of Postgres' syntax from a structured representation to the appropriate strings, and the reverse.
Can you do it? How large would it be?
@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.)
@hyper I find this difficult to believe... using eval (yuck) or using an existing parser isn't relevant to the conversation here.
Could you paste your one-line-json-parser?
The social network of the future: No ads, no corporate surveillance, ethical design, and decentralization! Own your data with Mastodon!