5 ms·

> I've personally written SQL queries for complex purposes of lengths up to around 1000 lines. How does it refute the argument about SQL being horrible for dat

by divan 4y ago

> I've personally written SQL queries for complex purposes of lengths up to around 1000 lines. How does it refute the argument about SQL being horrible for data query? Being proficient in some language or tool doesn't necesarilly mean that thing is not horrible. There are a lot of people proficient in JavaScript, you know. To expand a bit on my definition of horrible, I see a tool as a good choice for its job when two criteria match: 1) tool was deliberatly designed for the job (and not used as an afterthought, as with html/css/js, for example) 2) it matches well the mental model of human thinking in that problem domain. For example, when I need to fetch some nested data from db, I think about my request in terms of relations between objects (like "give me the list of people who are the actors for those movies nominated for Oscars and who are started directors careers recently") instead of JOINS and GROUPS. The fact that I have to reshape my way to think (aka boost my SQL skills) is a testimony to how poorly it scores in my number 2 criteria. Basically whenever you need to reshape your thinking to do some simple stuff with a tool, the tool is horrible. Like describe relatively simple spatial abstract knowledge in terms of class hierarchies (and start thinking in classes, which is not how human brain organizes knowledge). Or build modern UX interfaces thinking in typesetting primitives like "<p>" or "<img 'src='". A lot of popular things are horrible in software engineering unfortunately.

btilly 4y ago
I think you missed the line, "SQL feels horribly verbose, right until you compare it with equivalent procedural code." Having written SQL of varying complexity, and having rewritten it both directions between SQL and procedural, I'm in a good position to compare. And SQL is very good for its purpose. This is why nothing has replaced it.
- divan 4y ago
  > This is why nothing has replaced it. I don't buy this logic. It's like saying Facebook is a good social network and this is why nothing has replaced it. SQL obviously is an industry standard, the first thing you learn at IT bootcamp or CS classes, the first thing you've being asked at a job as a junior, etc. Decades of experience made most popular SQL engines stupidly effective. Yet, SQL as a query language was designed long time ago, when the data was orders of magnitude smaller and assumptions about data queries needs were way different from today. Let me put it this way – if data query language was designed today from scratch, with all the knowledge and experience we have now - it'll look very different from SQL. I mean, it's just obvious that with more time and real-world practice we get more understanding of how to shape our tools. And then they shape us, of course.
  - btilly 4y ago
    Do you have ANY sense of the history here? Query languages existed long before SQL was invented in the 1970s. For example IMS, still widely used for financial transactions was created in the 1960s. Even if you limit yourself to relational databases, there was long a competitor named QUEL. (Postgres originally used a dialect of QUEL as its query language.) Query languages continue to regularly be introduced. Practically every "NoSQL" system out there has one. Most object-relational mappers at some point introduce a query language that they think is better than SQL. I long ago lost count of how many query languages I've had to do something with for environments as different as MongoDB to Redis to custom languages for doing MapReduce on distributed systems. Some of those last indefinitely - both MongoDB and Redis are doing well. Other tools eventually sprout SQL layers like Postgres and Google BigQuery did. And SQL systems often sprout alternate layers as well, for example multiple projects exist to allow your SQL database to turn into a GraphQL one instead. The influence of SQL is not an artifact of history. It is due to the fact that, in a dynamic ecosystem filled with competition, nothing has managed to dethrone SQL since it successfully swam to the top and became dominant back in the 1980s. And ever since then, the end of SQL has been predicted. The next big thing is always around the corner. Maybe https://www.codemag.com/article/0305091/XQuery-the-Query-Language-of-the-Future https://www.codemag.com/article/0305091/XQuery-the-Query-Lan... is right and XQuery will finally slay the SQL dragon. Mind you I read articles like that 10 years ago and SQL is still standard. I also read articles 20 years ago like that with the same result. So it is probably a good idea to hedge your bets and learn SQL just in case history repeats itself.
    - divan 4y ago
      Thanks for the mentions of IMS and QUEL – I didn't know about them. I guess the main point I disagree with you here is about "dynamic ecosystem filled with competition". I totally agree that SQL won the battle of dominance, and that's the main reason why SQL stays popular and not so much competitors even emerge (sorry, MongoDB query language is a joke). Take QWERTY as an example. It's been proven countless times that it is suboptimal layout. It was designed with suboptimal trade-offs and with different goal in mind (minimize jamming of a typewriter). But it got it success and become dominant because of commercial success of typewriters with this keyboard layout. The rest is a pure network effect. So when I read your comments on SQL I hear something like "QWERTY is objectively the best layout, because nobody managed to dethrone it in a highly competitive settings, and because I type 800+ chars per minute with it". So that's true that SQL is dominant, but is it objectively the best we can do? I don't think so. Also, what's your experience with EdgeQL? I know it's a layer on top of existing SQL, but I had incredibly positive experience with it (after 20+ years with SQL). And I can totally see it as a standard for data query by itself. I would love to have something serverless like EdgeQLIte, in fact.

by divan 4y ago

btilly 4y ago

I think you missed the line, "SQL feels horribly verbose, right until you compare it with equivalent procedural code." Having written SQL of varying complexity, and having rewritten it both directions between SQL and procedural, I'm in a good position to compare. And SQL is very good for its purpose. This is why nothing has replaced it.

divan 4y ago
> This is why nothing has replaced it. I don't buy this logic. It's like saying Facebook is a good social network and this is why nothing has replaced it. SQL obviously is an industry standard, the first thing you learn at IT bootcamp or CS classes, the first thing you've being asked at a job as a junior, etc. Decades of experience made most popular SQL engines stupidly effective. Yet, SQL as a query language was designed long time ago, when the data was orders of magnitude smaller and assumptions about data queries needs were way different from today. Let me put it this way – if data query language was designed today from scratch, with all the knowledge and experience we have now - it'll look very different from SQL. I mean, it's just obvious that with more time and real-world practice we get more understanding of how to shape our tools. And then they shape us, of course.
- btilly 4y ago
  Do you have ANY sense of the history here? Query languages existed long before SQL was invented in the 1970s. For example IMS, still widely used for financial transactions was created in the 1960s. Even if you limit yourself to relational databases, there was long a competitor named QUEL. (Postgres originally used a dialect of QUEL as its query language.) Query languages continue to regularly be introduced. Practically every "NoSQL" system out there has one. Most object-relational mappers at some point introduce a query language that they think is better than SQL. I long ago lost count of how many query languages I've had to do something with for environments as different as MongoDB to Redis to custom languages for doing MapReduce on distributed systems. Some of those last indefinitely - both MongoDB and Redis are doing well. Other tools eventually sprout SQL layers like Postgres and Google BigQuery did. And SQL systems often sprout alternate layers as well, for example multiple projects exist to allow your SQL database to turn into a GraphQL one instead. The influence of SQL is not an artifact of history. It is due to the fact that, in a dynamic ecosystem filled with competition, nothing has managed to dethrone SQL since it successfully swam to the top and became dominant back in the 1980s. And ever since then, the end of SQL has been predicted. The next big thing is always around the corner. Maybe https://www.codemag.com/article/0305091/XQuery-the-Query-Language-of-the-Future https://www.codemag.com/article/0305091/XQuery-the-Query-Lan... is right and XQuery will finally slay the SQL dragon. Mind you I read articles like that 10 years ago and SQL is still standard. I also read articles 20 years ago like that with the same result. So it is probably a good idea to hedge your bets and learn SQL just in case history repeats itself.
  - divan 4y ago
    Thanks for the mentions of IMS and QUEL – I didn't know about them. I guess the main point I disagree with you here is about "dynamic ecosystem filled with competition". I totally agree that SQL won the battle of dominance, and that's the main reason why SQL stays popular and not so much competitors even emerge (sorry, MongoDB query language is a joke). Take QWERTY as an example. It's been proven countless times that it is suboptimal layout. It was designed with suboptimal trade-offs and with different goal in mind (minimize jamming of a typewriter). But it got it success and become dominant because of commercial success of typewriters with this keyboard layout. The rest is a pure network effect. So when I read your comments on SQL I hear something like "QWERTY is objectively the best layout, because nobody managed to dethrone it in a highly competitive settings, and because I type 800+ chars per minute with it". So that's true that SQL is dominant, but is it objectively the best we can do? I don't think so. Also, what's your experience with EdgeQL? I know it's a layer on top of existing SQL, but I had incredibly positive experience with it (after 20+ years with SQL). And I can totally see it as a standard for data query by itself. I would love to have something serverless like EdgeQLIte, in fact.