I like parts of the transaction model. It’s how I would/do do it - the commit collection, batching and asynchronous reply model.
That said, why are we still using a decades old domain specific language from 1979 (SQL) to interact with databases.
A language that has an extremely low impedance match with “data”, when we have a perfectly good language from two decades earlier… 1958 (LISP) that does a better job, and doesn’t require an ad-hoc query planner that trys (and fails) to outsmart the person planning the query.
Not only that but clearly someone didn’t get the memo that relational database models are so “1995”.
I applaud the efforts, and cynicism aside it really looks like they are doing their best here, and appreciate there is still some time to go before SQL falls away.
Unfortunately I can’t really like the fact that the authors are working this hard on what really is a dead paradigm.
Very well made paper however.
Obviously this comment comes off as authoritative, snarky and denigrating to the people who did the work.
That’s really not my intention however; it’s more like
Probably because it’s the least dead paradigm in the data world. Tools are useful to the extent that they can be employed to solve problems, and the first part of that is minimizing the number of new concepts the user must learn before they can solve problems.
Just to go further in agreement in relation to your comment.
Select * from Customers where Balance < 0
I just made that up so it probably isn’t valid SQL. It’s years since I wrote a lot of SQL.
Sure, that is easy and as you said, it helps people get going and solve problems.
But look what they just did. They learned a DSL that wasn’t needed. Transducers like Map/Filter/Reduce (or better) are much clearer for them and the machine.
Furthermore those translate to many other languages and compose much more easily.
I’m not convinced it is easier to learn SQL than just learning operators based on basic set theory.
Not only that, but extending SQL to graph databases, geospatial etc.
Sure, it can be done, and has been, but only at the cost of vendor specific lock-in or extremely obtuse syntax.
I used SQL a great deal back in the day. Before I “saw the light”. It’s just there are things that are equally expressive but compose much better and honestly not that much more difficult.
I think that the problem is a matter of how principles are introduced.
When SQL started it really seemed quite good and worked awesomely.
Then it got extended - a lot.
It got extended to such a great extent that when I look at SQL now, I feel like the thousands of people who have spent so much time in learning it properly have been painted into a corner, and I really feel sorry for them.
I have good friends who are top notch SQL DBA’s but they can’t transfer their skills easily. They are upset and have been going through the five stages of grief for some time.
Data is not flat relational tables anymore, (you could argue it never was), and I really feel bad that they really did do “Computer Science” to a high level on a very obscure technology that is destined to the same fate as COBOL.
I like parts of the transaction model. It’s how I would/do do it - the commit collection, batching and asynchronous reply model.
That said, why are we still using a decades old domain specific language from 1979 (SQL) to interact with databases.
A language that has an extremely low impedance match with “data”, when we have a perfectly good language from two decades earlier… 1958 (LISP) that does a better job, and doesn’t require an ad-hoc query planner that trys (and fails) to outsmart the person planning the query.
Not only that but clearly someone didn’t get the memo that relational database models are so “1995”.
I applaud the efforts, and cynicism aside it really looks like they are doing their best here, and appreciate there is still some time to go before SQL falls away.
Unfortunately I can’t really like the fact that the authors are working this hard on what really is a dead paradigm.
Very well made paper however.
Obviously this comment comes off as authoritative, snarky and denigrating to the people who did the work.
That’s really not my intention however; it’s more like
“just sayin…”
Probably because it’s the least dead paradigm in the data world. Tools are useful to the extent that they can be employed to solve problems, and the first part of that is minimizing the number of new concepts the user must learn before they can solve problems.
Just to go further in agreement in relation to your comment.
Select * from Customers where Balance < 0
I just made that up so it probably isn’t valid SQL. It’s years since I wrote a lot of SQL.
Sure, that is easy and as you said, it helps people get going and solve problems.
But look what they just did. They learned a DSL that wasn’t needed. Transducers like Map/Filter/Reduce (or better) are much clearer for them and the machine.
Furthermore those translate to many other languages and compose much more easily.
I’m not convinced it is easier to learn SQL than just learning operators based on basic set theory.
Not only that, but extending SQL to graph databases, geospatial etc.
Sure, it can be done, and has been, but only at the cost of vendor specific lock-in or extremely obtuse syntax.
I used SQL a great deal back in the day. Before I “saw the light”. It’s just there are things that are equally expressive but compose much better and honestly not that much more difficult.
I think that the problem is a matter of how principles are introduced.
Oh you need to do data? You need to use SQL.
It doesn’t work like that.
Yes I get that and you are right of course.
When SQL started it really seemed quite good and worked awesomely.
Then it got extended - a lot.
It got extended to such a great extent that when I look at SQL now, I feel like the thousands of people who have spent so much time in learning it properly have been painted into a corner, and I really feel sorry for them.
I have good friends who are top notch SQL DBA’s but they can’t transfer their skills easily. They are upset and have been going through the five stages of grief for some time.
Data is not flat relational tables anymore, (you could argue it never was), and I really feel bad that they really did do “Computer Science” to a high level on a very obscure technology that is destined to the same fate as COBOL.
Obviously they get paid a lot. So there is that.