3 ms·

Your rant doesn't need a point-by-point response. Problems always exist when you attempt to force-fit two idiomatically divergent languages. SQL was designed

by ak39 12y ago

Your rant doesn't need a point-by-point response. Problems always exist when you attempt to force-fit two idiomatically divergent languages. SQL was designed for reading and updating relational data. Data in tables that can be joined with relational intersections, unions and complements. For that it does its job. Idiomatically, it has its own "code modularity" paradigm. (And no, I don't mean stored procedures here). Object-oriented folks want to overlay the object paradigm and the attendant idiomatic language aspects on top of SQL. Painful, but not the fault of SQL's. This is your proverbial impedance mismatch. We have to "deal with it" without compromising the idiomatic strengths of either paradigm.

jbergens 12y ago
With some small changes to SQL you can get something similar that probably gets closer to what he describes. Seems to be called NewSql in a lot of cases. One thing some people like with sql is that the query engine translates the language to the actual query. If this is what you want you can build it on top of many databases. Being able to return something more advanced than simple tables would also be nice in a lot of cases.
Pxtl 12y ago
What? > SQL was designed for reading and updating relational data. Data in tables that can be joined with relational intersections, unions and complements. Obviously. And it fails miserably at providing you with tools to reuse this code. > This is your proverbial impedance mismatch. We have to "deal with it" without compromising the idiomatic strengths of either paradigm. That's a cop-out. Purist functional programming languages provide namespaces, packaging systems, etc. even though nowhere in the academia of "lambda calculus" is stuff like that mentioned. At some point the rubber hits the road and you have to interface with your beautiful kernel of relational algebra, and you have to organize all that relational stuff. Nowhere in Date and Darwin's work does it say that a relational set must be defined by a name. Why can't it be defined by a tree of namespaces? Or packages? Or anything other than simply a flat list of names? At some point it's time to stop making excuses for this antediluvian system. SQL platforms make exceptions from the SQL spec for stupid things like bolting on a procedural scripting language, but never for smart things like better organization tools for code-reuse.

by ak39 12y ago

jbergens 12y ago

With some small changes to SQL you can get something similar that probably gets closer to what he describes. Seems to be called NewSql in a lot of cases. One thing some people like with sql is that the query engine translates the language to the actual query. If this is what you want you can build it on top of many databases. Being able to return something more advanced than simple tables would also be nice in a lot of cases.

Pxtl 12y ago

What? > SQL was designed for reading and updating relational data. Data in tables that can be joined with relational intersections, unions and complements. Obviously. And it fails miserably at providing you with tools to reuse this code. > This is your proverbial impedance mismatch. We have to "deal with it" without compromising the idiomatic strengths of either paradigm. That's a cop-out. Purist functional programming languages provide namespaces, packaging systems, etc. even though nowhere in the academia of "lambda calculus" is stuff like that mentioned. At some point the rubber hits the road and you have to interface with your beautiful kernel of relational algebra, and you have to organize all that relational stuff. Nowhere in Date and Darwin's work does it say that a relational set must be defined by a name. Why can't it be defined by a tree of namespaces? Or packages? Or anything other than simply a flat list of names? At some point it's time to stop making excuses for this antediluvian system. SQL platforms make exceptions from the SQL spec for stupid things like bolting on a procedural scripting language, but never for smart things like better organization tools for code-reuse.