5 ms·

The middlebrow dismissal strikes again! Why is it so hard to imagine something displacing SQL? A simpler, more predictable syntax seems perfectly plausible--it

by ericb 7y ago

The middlebrow dismissal strikes again! Why is it so hard to imagine something displacing SQL? A simpler, more predictable syntax seems perfectly plausible--it could ship alongside SQL. Do we have StockHolm Syndrome? The negativity is surprising and at the same time predictable.

hobs 7y ago
Because of the decades of things not displacing it - when someone suggests "oh we'll just do it simpler" they often are not seeing the forest for the trees. Simpler languages have been shipped dozens if not hundreds of times, and they generally tend towards expressing the things they missed or not giving enough functionality for the things they missed. I am not saying its impossible, but you're going to have to do a lot more than hand waving to justify the reverse position.
- chuckgreenman 7y ago
  It's sort of like the mouse trap problem. Mouse traps and SQL are already incredibly simple and incredible effective, that's why you don't see a reinvented mouse trap at home depot and why SQL remains unseated despite many efforts to replace it.
  - adamlett 7y ago
    You really think SQL is incredibly simple? I think TFA makes a pretty convincing argument that it is anything but.
    - chuckgreenman 7y ago
      Certainly there are complex aspects of it but you could teach someone how to do most of what you need to do in SQL in under an hour.
    - darkpuma 7y ago
      Most common SQL statements read like somewhat stilted english. Many non-programmers find this particularly accessible. Yes you can make some lovecraftian horrors if you really want to, but SQL is one of those things where just a little bit of knowledge goes a long way. If you can understand the basics you can get a lot of work done. It's a lot like Excel. You can do some really complex confusing stuff in Excel. But you can also teach the basics to non-programmers quite easily, and command of the basic skills will be very empowering. Basic knowledge of Excel, like SQL, gives the user new ways to leverage computers when creating their own solutions to their own problems.
      - adamlett 7y ago
        Most common SQL statements read like somewhat stilted english. Many non-programmers find this particularly accessible. The problem is not reading SQL, but writing it. It's a lot like Excel. You can do some really complex confusing stuff in Excel […] Basic knowledge of Excel, like SQL, gives the user new ways to leverage computers when creating their own solutions to their own problems. I can’t speak to your experiences, but I’ve never in my life encountered someone who was not a professional programmer ever even contemplating using SQL for anything let alone creating their own solutions to their own problems. I think it’s safe to assume that the overwhelming majority of people who use SQL, are programmers who most certainly cannot get by with just basic knowledge.
        perl4ever 7y ago
        "I’ve never in my life encountered someone who was not a professional programmer ever even contemplating using SQL for anything" I have. That's only an anecdotal observation, but it seems to me that the existence of Visual Basic and the popularity over the years, combined with the utter disdain for it by "real programmers" is evidence that, more generally, there are a huge number of kinda, sorta, programmers who are outside the IT culture.
        darkpuma 7y ago
        Librarians and secretaries are two examples of "non-programmer" careers where functional knowledge of SQL is pretty common. Less-so these days with secretaries, but moreso for librarians. Not to mention tons of researchers across countless disciplines have SQL in their toolboxes. I've even met government bureaucrats with professional backgrounds in regional banking that know SQL. Previous programming experience? Using HP-12c calculators... >I think it’s safe to assume that the overwhelming majority of people who use SQL, are programmers who most certainly cannot get by with just basic knowledge. Most demonstrably do though, so there's that. If you cast a wide net when polling programmers, I think you'd find that mode level of knowledge was relatively low. You don't need to be a SQL rockstar ninja dude to do what most professional programmers are doing with SQL most of the time. Obviously advanced knowledge is good for any professional programmer to have, but the fact is there are a TON of people out there who only know the basics, and that works for them.
  - perl4ever 7y ago
    "that's why you don't see a reinvented mouse trap at home depot" Interesting for you to say that. The last time I went looking for mouse traps, I found that every place I went had a reinvented type, and traditional style were extremely hard to find. Yet, it is true that the traditional style is simple and effective. I've learned from experience that anything else is likely to be useless.
skybrian 7y ago
It could happen. However, the probability of success for any given attempt is low. Consider all the attempts at improving on JavaScript before Typescript.
dragonwriter 7y ago
> The middlebrow dismissal strikes again! Yes, it was that, but, still, there's a big and growing hurdle here that many similar efforts, with similar objective merits compared to contemporary SQL implementations, have failed to overcome, and not a lot of reason provided to think EdgeDB is better positioned. > Why is it so hard to imagine something displacing SQL? Because systems providing just as good solutions to largely the same set of SQL deficiencies have been produced and failed to displace SQL for a couple of decades. The problem isn't doing better than SQL. It's doing enough better than SQL to overcome the depth of knowledge, experience, support, tooling maturity, and comfort people have with SQL. And that most gets deeper over time, on top of SQL getting internal mitigations, if not actual solutions, to some of the problems over time. That said—as I’ve done with several before—I’ll probably download EdgeDB and try to do some stuff with it.
- garmaine 7y ago
  That's like saying nothing will replace COBOL. Or nothing will replace Fortran. Or C++. Or Java. There's no reason the industry can't move to new technology for new projects. No one is going to rewrite legacy applications in the new language, at least not until the transition is so far along that SQL specialists are aged out and costly. But for new things? It's totally acceptable to pick new languages. And btw, this has already happened in some areas. Most developers I know don't code in SQL: they use an ORM provided by their language runtime or a support library. That's essentially the same thing.
  - GenericsMotors 7y ago
    > And btw, this has already happened in some areas. Most developers I know don't code in SQL: they use an ORM provided by their language runtime or a support library. That's essentially the same thing. This works well enough until your ORM shits the bed and you're forced to figure out why your SQL database is "slow". SQL isn't slow, ORMs are just terrible when you hit an edge-case or when pretend there isn't a relational model behind your opaque materialised objects. I used to be one of those developers you mentioned, but I'm not anymore after years of debugging "SQL performance issues" (hint: it was the ORM), and actually taking the time to learn the language and take advantage of specific RDBMS features. My preference has shifted to just use a lightweight library to materialise objects (like Dapper), and write the queries myself.
marcosdumay 7y ago
Would you adopt an extra abstraction layer (bugs, maintenance, incompatibilities and surprises included) over your database to get a coherent handling of nulls and a few other optimizations of this level? I know I'm staying with the nulls. I wish the best luck for them, and if it survives to maturity, I'll haply go get the ~1% (probably less) more productivity they offer. But right now I'm not moving. It's sad, really, but things are stacked against them. Change is costly, so we lose all the small changes that could compose into something huge.
ErwinSmout 7y ago
You even don't have to "imagine" it anymore, it already exists. See the projects list at http://www.thethirdmanifesto.com http://www.thethirdmanifesto.com . The crux is : it takes much much more to achieve that than what the average C# or java coder yup has to offer. So the average C# or java coder yup will dismiss those things too.

by ericb 7y ago

hobs 7y ago

Because of the decades of things not displacing it - when someone suggests "oh we'll just do it simpler" they often are not seeing the forest for the trees. Simpler languages have been shipped dozens if not hundreds of times, and they generally tend towards expressing the things they missed or not giving enough functionality for the things they missed. I am not saying its impossible, but you're going to have to do a lot more than hand waving to justify the reverse position.

chuckgreenman 7y ago
It's sort of like the mouse trap problem. Mouse traps and SQL are already incredibly simple and incredible effective, that's why you don't see a reinvented mouse trap at home depot and why SQL remains unseated despite many efforts to replace it.
- adamlett 7y ago
  You really think SQL is incredibly simple? I think TFA makes a pretty convincing argument that it is anything but.
  - chuckgreenman 7y ago
    Certainly there are complex aspects of it but you could teach someone how to do most of what you need to do in SQL in under an hour.
  - darkpuma 7y ago
    Most common SQL statements read like somewhat stilted english. Many non-programmers find this particularly accessible. Yes you can make some lovecraftian horrors if you really want to, but SQL is one of those things where just a little bit of knowledge goes a long way. If you can understand the basics you can get a lot of work done. It's a lot like Excel. You can do some really complex confusing stuff in Excel. But you can also teach the basics to non-programmers quite easily, and command of the basic skills will be very empowering. Basic knowledge of Excel, like SQL, gives the user new ways to leverage computers when creating their own solutions to their own problems.
    - adamlett 7y ago
      Most common SQL statements read like somewhat stilted english. Many non-programmers find this particularly accessible. The problem is not reading SQL, but writing it. It's a lot like Excel. You can do some really complex confusing stuff in Excel […] Basic knowledge of Excel, like SQL, gives the user new ways to leverage computers when creating their own solutions to their own problems. I can’t speak to your experiences, but I’ve never in my life encountered someone who was not a professional programmer ever even contemplating using SQL for anything let alone creating their own solutions to their own problems. I think it’s safe to assume that the overwhelming majority of people who use SQL, are programmers who most certainly cannot get by with just basic knowledge.
      - perl4ever 7y ago
        "I’ve never in my life encountered someone who was not a professional programmer ever even contemplating using SQL for anything" I have. That's only an anecdotal observation, but it seems to me that the existence of Visual Basic and the popularity over the years, combined with the utter disdain for it by "real programmers" is evidence that, more generally, there are a huge number of kinda, sorta, programmers who are outside the IT culture.
      - darkpuma 7y ago
        Librarians and secretaries are two examples of "non-programmer" careers where functional knowledge of SQL is pretty common. Less-so these days with secretaries, but moreso for librarians. Not to mention tons of researchers across countless disciplines have SQL in their toolboxes. I've even met government bureaucrats with professional backgrounds in regional banking that know SQL. Previous programming experience? Using HP-12c calculators... >I think it’s safe to assume that the overwhelming majority of people who use SQL, are programmers who most certainly cannot get by with just basic knowledge. Most demonstrably do though, so there's that. If you cast a wide net when polling programmers, I think you'd find that mode level of knowledge was relatively low. You don't need to be a SQL rockstar ninja dude to do what most professional programmers are doing with SQL most of the time. Obviously advanced knowledge is good for any professional programmer to have, but the fact is there are a TON of people out there who only know the basics, and that works for them.
- perl4ever 7y ago
  "that's why you don't see a reinvented mouse trap at home depot" Interesting for you to say that. The last time I went looking for mouse traps, I found that every place I went had a reinvented type, and traditional style were extremely hard to find. Yet, it is true that the traditional style is simple and effective. I've learned from experience that anything else is likely to be useless.

skybrian 7y ago

It could happen. However, the probability of success for any given attempt is low. Consider all the attempts at improving on JavaScript before Typescript.

dragonwriter 7y ago

> The middlebrow dismissal strikes again! Yes, it was that, but, still, there's a big and growing hurdle here that many similar efforts, with similar objective merits compared to contemporary SQL implementations, have failed to overcome, and not a lot of reason provided to think EdgeDB is better positioned. > Why is it so hard to imagine something displacing SQL? Because systems providing just as good solutions to largely the same set of SQL deficiencies have been produced and failed to displace SQL for a couple of decades. The problem isn't doing better than SQL. It's doing enough better than SQL to overcome the depth of knowledge, experience, support, tooling maturity, and comfort people have with SQL. And that most gets deeper over time, on top of SQL getting internal mitigations, if not actual solutions, to some of the problems over time. That said—as I’ve done with several before—I’ll probably download EdgeDB and try to do some stuff with it.

garmaine 7y ago
That's like saying nothing will replace COBOL. Or nothing will replace Fortran. Or C++. Or Java. There's no reason the industry can't move to new technology for new projects. No one is going to rewrite legacy applications in the new language, at least not until the transition is so far along that SQL specialists are aged out and costly. But for new things? It's totally acceptable to pick new languages. And btw, this has already happened in some areas. Most developers I know don't code in SQL: they use an ORM provided by their language runtime or a support library. That's essentially the same thing.
- GenericsMotors 7y ago
  > And btw, this has already happened in some areas. Most developers I know don't code in SQL: they use an ORM provided by their language runtime or a support library. That's essentially the same thing. This works well enough until your ORM shits the bed and you're forced to figure out why your SQL database is "slow". SQL isn't slow, ORMs are just terrible when you hit an edge-case or when pretend there isn't a relational model behind your opaque materialised objects. I used to be one of those developers you mentioned, but I'm not anymore after years of debugging "SQL performance issues" (hint: it was the ORM), and actually taking the time to learn the language and take advantage of specific RDBMS features. My preference has shifted to just use a lightweight library to materialise objects (like Dapper), and write the queries myself.

marcosdumay 7y ago

Would you adopt an extra abstraction layer (bugs, maintenance, incompatibilities and surprises included) over your database to get a coherent handling of nulls and a few other optimizations of this level? I know I'm staying with the nulls. I wish the best luck for them, and if it survives to maturity, I'll haply go get the ~1% (probably less) more productivity they offer. But right now I'm not moving. It's sad, really, but things are stacked against them. Change is costly, so we lose all the small changes that could compose into something huge.

ErwinSmout 7y ago

You even don't have to "imagine" it anymore, it already exists. See the projects list at http://www.thethirdmanifesto.com http://www.thethirdmanifesto.com . The crux is : it takes much much more to achieve that than what the average C# or java coder yup has to offer. So the average C# or java coder yup will dismiss those things too.