nostr:nprofile1qqsza7flq8xjfylqgg66dwrmzrfuff6w9flt0s72795zdrm27ue3fdgct4s0j is this because you don't think it's wise for a weird Cobol-like string of instructions -- that first have to be generated by the host (with all the care to prevent malicious injections and all the refinement of string concatenation otherwise) and then parsed by the database -- to act as the API between two programs because they could pretty exchange structured data instead?
Discussion
Or is it because SQL is associated with servers running externally to the programs that use the data and as such they constitute a weird unnecessary slow abstraction that isn't needed for 99% of the programs we write today that could pretty much use an embedded simpler database or sometimes just some files?
Also interested in the answers to these questions nostr:npub19mun7qwdyjf7qs3456u8kyxncjn5u2n7klpu4utgy68k4aenzj6synjnft
Or perhaps it's because the whole "relational" stuff hides the nasty parts of arranging, indexing and querying data from the programmer and creates a vicious cycle of dependence and incapability that makes the average programmer think anything an SQL query can do is at the same time "magic" (because no one knows how it's done) and "natural" (because everybody can do it since it's assumed everybody is using Postgres or MySQL).
You can see an example of that in any of the many discussions about what features the Nostr "query language" should support.
Precisely. It is utterly insane for programmers to communicate with a database by constructing strings in an arcane language that is then compiled in real time. Not only does this open a whole bunch of bizarre, security holes, it’s just plain dumb. We are programmers, we communicate with our libraries using functions and data structures, not strings that have a syntax that was designed 50 years ago for non-programmers to use.
Dynamically compiling SQL query strings in our programs is something so stupid even southpark couldn't sufficiently mock it
South Park talked about SQL? Where?
It's ripe for the pickings
This is what I think devs look like when they are writing SQL abstraction libraries.