19 ms·

Lazy devs love it. Everyone who has to come along after them despises them for it. KV stores and noSQL stuff have their place, being a dumping ground does the

Lazy devs love it. Everyone who has to come along after them despises them for it. KV stores and noSQL stuff have their place, being a dumping ground does them no favours.

kbolino 2y ago
I've returned to SQL after years of "lazily" enjoying NoSQL and I gotta say, SQL would do well to stop relying on a thesaurus. It feels like I'm writing COBOL. I don't understand why I need to feed English to a Zork parser when I know exactly what operation to perform. An opcode with some arguments would be preferable to writing a poem and hoping it gets interpreted how I meant.
- FridgeSeal 2y ago
  SQL has its warts for sure, I personally long for the day we get a better declarative query lang than the stringly-typed thing we have now. > An opcode with some arguments would be preferable to writing a poem and hoping it gets interpreted how I meant Not sure I follow here though? Is it the declarative nature you don’t like? SQL can be a bit ugly sometimes, but I’ve never really had “no that’s not what I mean” moments?
  - kbolino 2y ago
    This may be a gripe specific to Postgres but I find that the documentation can be obtuse. Yes, I'm sure it parses consistently, but what a given word or phrase does in a given context isn't always clear. I've had to write a lot more database tests to be sure I know what I'm doing than when I was calling specific operations with well defined arguments in NoSQL land. Maybe this issue is mostly in my head, but the semantics of various operations seem a lot fuzzier than I'm used to.
    - maxbond 2y ago
      SQLite does make this a lot clearer using flow charts, I wish Postgres' docs had that. https://www.sqlite.org/lang_createtable.html https://www.sqlite.org/lang_createtable.html You will find all the same information in the Postgres docs, but in a more obtuse, grammatical form. https://www.postgresql.org/docs/current/sql-createtable.html https://www.postgresql.org/docs/current/sql-createtable.html They will tell you what each component does further down the page though. Mongo's documentation has a slicker and more ergonomic design though, no question. Mongo uses a "cheat sheet"/"tabular" approach, and Postgres uses a "printed reference book" approach, which is rather dated. Mongo is very good at surfacing the complexity and nitty gritty details immediately. It's all there in the Postgres docs, but you have to sit with them for longer and have more of an intuition about how they've organized it. I've also found the Postgres.FM podcast to be a great resource. I've been working with Mongo recently and something that's bothered me is that I haven't found a comparable resource, where practitioners give you the straight dope about what stupid mistake you're going to make to bring down production and how to fix it. Substantially all of the learning material for Mongo is from Mongo the company, and is just not as candid.
- sapling-ginger 2y ago
  A poem that has been consistent and frozen for 50 years, that works 99% same across all vendors? We tolerate the SQL as it is, warts and all, because as soon as you bikeshed it it will explode into 50 different dialects. Just look at JSON for example.
  - kbolino 2y ago
    I think that is a gross overstatement. The language has evolved (and should evolve) substantially over the last few decades. Experience from the NoSQL world has influenced SQL (though obviously not always as much as I'd like). I'd also rate the mutual intelligibility of various dialects at around 80-90%, which is still really high, all things considered. But none of that is the problem. I'm not a data analyst. I don't need a query Swiss army knife. I need a database that behaves predictably under concurrency at a level I can understand. I need primitive operations that map well to the persistence needs of an app serving multiple users at scale. I've never said SQL is incapable or even inadequate at these tasks but figuring out how to do them correctly ends up being a test of English skills rather than picking the right function to call and the right arguments to pass it.

Lazy devs love it. Everyone who has to come along after them despises them for it. KV stores and noSQL stuff have their place, being a dumping ground does them no favours.

kbolino 2y ago

I've returned to SQL after years of "lazily" enjoying NoSQL and I gotta say, SQL would do well to stop relying on a thesaurus. It feels like I'm writing COBOL. I don't understand why I need to feed English to a Zork parser when I know exactly what operation to perform. An opcode with some arguments would be preferable to writing a poem and hoping it gets interpreted how I meant.

FridgeSeal 2y ago
SQL has its warts for sure, I personally long for the day we get a better declarative query lang than the stringly-typed thing we have now. > An opcode with some arguments would be preferable to writing a poem and hoping it gets interpreted how I meant Not sure I follow here though? Is it the declarative nature you don’t like? SQL can be a bit ugly sometimes, but I’ve never really had “no that’s not what I mean” moments?
- kbolino 2y ago
  This may be a gripe specific to Postgres but I find that the documentation can be obtuse. Yes, I'm sure it parses consistently, but what a given word or phrase does in a given context isn't always clear. I've had to write a lot more database tests to be sure I know what I'm doing than when I was calling specific operations with well defined arguments in NoSQL land. Maybe this issue is mostly in my head, but the semantics of various operations seem a lot fuzzier than I'm used to.
  - maxbond 2y ago
    SQLite does make this a lot clearer using flow charts, I wish Postgres' docs had that. https://www.sqlite.org/lang_createtable.html https://www.sqlite.org/lang_createtable.html You will find all the same information in the Postgres docs, but in a more obtuse, grammatical form. https://www.postgresql.org/docs/current/sql-createtable.html https://www.postgresql.org/docs/current/sql-createtable.html They will tell you what each component does further down the page though. Mongo's documentation has a slicker and more ergonomic design though, no question. Mongo uses a "cheat sheet"/"tabular" approach, and Postgres uses a "printed reference book" approach, which is rather dated. Mongo is very good at surfacing the complexity and nitty gritty details immediately. It's all there in the Postgres docs, but you have to sit with them for longer and have more of an intuition about how they've organized it. I've also found the Postgres.FM podcast to be a great resource. I've been working with Mongo recently and something that's bothered me is that I haven't found a comparable resource, where practitioners give you the straight dope about what stupid mistake you're going to make to bring down production and how to fix it. Substantially all of the learning material for Mongo is from Mongo the company, and is just not as candid.
sapling-ginger 2y ago
A poem that has been consistent and frozen for 50 years, that works 99% same across all vendors? We tolerate the SQL as it is, warts and all, because as soon as you bikeshed it it will explode into 50 different dialects. Just look at JSON for example.
- kbolino 2y ago
  I think that is a gross overstatement. The language has evolved (and should evolve) substantially over the last few decades. Experience from the NoSQL world has influenced SQL (though obviously not always as much as I'd like). I'd also rate the mutual intelligibility of various dialects at around 80-90%, which is still really high, all things considered. But none of that is the problem. I'm not a data analyst. I don't need a query Swiss army knife. I need a database that behaves predictably under concurrency at a level I can understand. I need primitive operations that map well to the persistence needs of an app serving multiple users at scale. I've never said SQL is incapable or even inadequate at these tasks but figuring out how to do them correctly ends up being a test of English skills rather than picking the right function to call and the right arguments to pass it.