5 ms·

Imperative code is complicated when dealing with data, so we abstract imperative code into SQL. SQL is complicated so we abstract it from SQL back into imperati

Imperative code is complicated when dealing with data, so we abstract imperative code into SQL. SQL is complicated so we abstract it from SQL back into imperative code via an ORM. Of course it's backwards. It's like one of the biggest legacies of web development next to javascript, html and CSS. SQL is a very specific way to think about data and a very high level and leaky abstraction. So high and leaky, that you literally need to look at the query plan in order to optimize sql queries. If Database IO is the bottleneck for web development the best abstraction for this area is most likely a zero cost abstraction (rust for example). Instead we have SQL and we create a generation of SQL hackers who memorize a bunch of technology specific hacks to try to get things to work. Why is SELECT * bad? It's a hack you memorized, a leaky abstraction. I'm not saying schema-less is better hear me out. I'm saying SQL is a bad API. You can probably make some api language that's more explicit and imperative on top of something like postgres. Change the API itself don't write something on top of it. Either way, an ORM on top of SQL is like what type script is to javascript. You know when they make an API on top of an API it's to cover up something that doesn't work well. Unless it's a zero cost compilation such fixes only make performance worse. If you insist on using some abstraction on top of sql the way to do it with zero cost is an api that is bijective to the syntax of SQL itself. Type script I'm guessing is relatively isomorphic to javascript, so it works out.

taffer 7y ago
> I'm saying SQL is a bad API. You can probably make some api language that's more explicit and imperative on top of something like postgres. Change the API itself don't write something on top of it. Something like VSAM or IMS? The relational model and declarative query languages were invented because the previously existing imperative navigational model was far too inflexible and difficult to use. Access paths were baked into the data structures, you had to be your own optimizer, and if you optimized for the wrong usage patterns, you had to refactor everything or live with poor performance.
- crimsonalucard 7y ago
  You can enforce patterns via types. You can also have default optimizations. The problem with SQL is to choose optimization you have to do it by poking the syntax. For example: query1 = select(table, columns, optimization_method="auto") query3 = join(query1, query2, joinOptimizationMethod="auto"...) Obviously the above example is trivial, wrong and probably won't work. But I hope it paints a fuzzy picture of my point. That is that the optimization or 'plan' should be explicit. You choose auto or you dive in and you change it yourself. No language or syntax hacks.
  - taffer 7y ago
    It seems that what you want is not an imperative API, but a more explicit one. I'm afraid the problem is that specifying the access methods or optimizations to use in the database is very product- or even version-specific, on the other hand you can already tell a database what to do using optimizer hints.
    - crimsonalucard 7y ago
      I want both. An imperative language makes it more able to be isomorphic to a web app api. You can have corresponding types and functions without something totally different. Optimizer hints is a good idea. As far as I know this isn't a well known feature (if it even is a feature) for postgresql, which is the DB I have the most experience with.
  - james_s_tayler 7y ago
    No thanks. The benefit is not having to specify the plan. The optimizers themselves are fairly good. A well designed table with the right indexes should perform well. Raw SQL is great at what it does. ORMs are typically good at what they do. Depending on the use case both have their pain points. Typically I see a mixture of ORM for most CRUD based stuff and raw SQL for cases where the ORM isn't suitable. No need to throw the baby out with the bathwater.
    - crimsonalucard 7y ago
jdmichal 7y ago
Just FYI, TypeScript is expressly a superset of JavaScript, so you don't need to guess! https://github.com/Microsoft/TypeScript https://github.com/Microsoft/TypeScript TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

taffer 7y ago

> I'm saying SQL is a bad API. You can probably make some api language that's more explicit and imperative on top of something like postgres. Change the API itself don't write something on top of it. Something like VSAM or IMS? The relational model and declarative query languages were invented because the previously existing imperative navigational model was far too inflexible and difficult to use. Access paths were baked into the data structures, you had to be your own optimizer, and if you optimized for the wrong usage patterns, you had to refactor everything or live with poor performance.

crimsonalucard 7y ago
You can enforce patterns via types. You can also have default optimizations. The problem with SQL is to choose optimization you have to do it by poking the syntax. For example: query1 = select(table, columns, optimization_method="auto") query3 = join(query1, query2, joinOptimizationMethod="auto"...) Obviously the above example is trivial, wrong and probably won't work. But I hope it paints a fuzzy picture of my point. That is that the optimization or 'plan' should be explicit. You choose auto or you dive in and you change it yourself. No language or syntax hacks.
- taffer 7y ago
  It seems that what you want is not an imperative API, but a more explicit one. I'm afraid the problem is that specifying the access methods or optimizations to use in the database is very product- or even version-specific, on the other hand you can already tell a database what to do using optimizer hints.
  - crimsonalucard 7y ago
    I want both. An imperative language makes it more able to be isomorphic to a web app api. You can have corresponding types and functions without something totally different. Optimizer hints is a good idea. As far as I know this isn't a well known feature (if it even is a feature) for postgresql, which is the DB I have the most experience with.
- james_s_tayler 7y ago
  No thanks. The benefit is not having to specify the plan. The optimizers themselves are fairly good. A well designed table with the right indexes should perform well. Raw SQL is great at what it does. ORMs are typically good at what they do. Depending on the use case both have their pain points. Typically I see a mixture of ORM for most CRUD based stuff and raw SQL for cases where the ORM isn't suitable. No need to throw the baby out with the bathwater.
  - crimsonalucard 7y ago

jdmichal 7y ago

Just FYI, TypeScript is expressly a superset of JavaScript, so you don't need to guess! https://github.com/Microsoft/TypeScript https://github.com/Microsoft/TypeScript TypeScript is a superset of JavaScript that compiles to clean JavaScript output.