5 ms·
I counter the argument that just because it is still around it is the best solution. Many things stick around just because of inertia, for example, the QWERTY k
by animal_spirits 3y ago
I counter the argument that just because it is still around it is the best solution. Many things stick around just because of inertia, for example, the QWERTY keyboard.
- nonethewiser 3y agoThen state the better solution. Besides, I'm not saying it's the best because it's most common, or even that its the best at all. It just makes it difficult to understand the argument that SQL sucks when its so widely used and no one can agree on an alternative. Including in new databases which could opt for these "new and improved" variants. I grant that there is a first-mover advantage and it's not easy to shift paradigms. That's a big factor. That's why I am honestly - not rhetorically - asking which query language is clearly better than SQL? And why do people keep making new challengers instead of backing something that's already better than SQL? There seems to be very little support for these query languages despite many people saying SQL sucks and they want a redo.
- fijiaarone 3y agoBig keyboard is keeping DVORAK down! In a fair world we’d all be typing NewQL faster with AI from our flying electric cars in a communist utopia.
- euroderf 3y agoThe cross-silo synergy is strong in this one.
- halayli 3y agoYou're comparing apples to oranges. Typing is much harder to relearn due to muscle memory. New well designed programming languages become quite popular quickly and go viral when they solve the right problems for developers. SQL is a very sound querying language originally based on relational algebra and tuple relational calculus. Many attempts have been made in the past to come up with better syntax but they don't go far which might have to do with the fact that authors realize later that SQL is just a thin layer masquerading the mathematical concepts required to retrieve relational data and make certain assumptions without breaking set theory axioms. One common mistake I see is that developers attempting to create an SQL replacement often approach it in the same mindset as creating yet another general purpose programming language. Edit: The above is not in reference to PRQL. It's just my anecdotal experience working on several SQL engines, building ones from scratch and working in this domain for 15 yrs.