Back in October I posted about the virtues of SQL and asked the question: what will replace it in a NoSQL/NewSQL hybrid world?
Don’t get me wrong: I dislike SQL as a programming language; I think it’s an awful kludge, and something inside me cringes every time I use it. (Although, to be fair to SQL, I kind of feel that way about all the functional programming languages I’ve ever used: Prolog, (functional) LISP. Functional programming bugs me the same way having to wait for the waiter to bring water bugs me when I’m thirsty and I can see the pitcher of water eight feet away at the waitstaff podium… but we disgress.)
But SQL has the virtue of separating the details of data storage and retrieval from the details of application logic, and we badly need something like that going forward.
As it happens, the relational paradigm itself is under attack from NoSQL approaches (or it should be; I never really liked the relational paradigm much, either; it has a heck of a time with anything “complex” (join-y, recursive-y, set-y), and doesn’t do such a great job on things that are simple, either. But we digres…)
So maybe we can kill two birds with one stone: advance beyond the relational paradigm and start an API to data (even if not yet a language) that is agnostic about the structured-ness of the underlying data.
I guess I’m going to out completely here, and say that I also hate XML sublanguages by and large. They are bloated, difficult to compute on, and PL/1-ish. With exceptions, perhaps.
But something on the order of abstraction of RDF sounds like the “new relational” to me. Even after the rise and fall of the “triples empire” some years ago. A simple atomic relationship binding two entities together seems like a logical place to start.
As usual, I’m way out of my depth here. I hope someone who actually knows something about these matters will step in. But I do feel obliged to bring the matter up.
Your thoughts?
Ah, yes, let me add the trifecta of hateful languages: XSL. Combines the blovation of XML with the functional-ness of SQL and adds in a je ne sais quoi of complete opaqueness that puts it right up there with Teco macros for my most hated programming language of all time.
Our take is JSONiq, an extension of XQuery for JSON: http://jsoniq.org