Ballerina, perhaps a more serious language with relational constructs
Quote from dandl on November 8, 2021, 12:22 amQuote from Erwin on November 7, 2021, 6:51 pmQuote from dandl on November 6, 2021, 2:17 amAnd new entrants start from so far behind that mostly they never catch up.
New entrants who let themselves be inspired by the TTM message (after having 'gotten' it, of course ...), start from so far ahead that the intended audience is never going to catch up in its lifetime.
Not really. SQL/Word/Excel/Java etc are like a city full of skyscrapers, Manhattan say. People live and work in every floor, every room, every cubicle. You come along and point out (quite correctly) that the foundations are wrong and the whole city would work better if they were put right. So you set out to create new foundations and add a couple of floors of one building, but you are so far behind because you can never build a new city. So everyone stays in the old one, because it's there, and it works, kind of.
The only change you get is once in a generation when a new city gets built, like for smart phones. But even then the battle is on to claim territory fast so they pick the tools to hand and replicate the same old mistakes. Or there is continuing battle over which tools to use and you get the Web. Either way, you never catch up. The money wins every time.
Until Manhattan becomes Detroit. That, too, happens to cities that ***appear to*** "work, kind of".
Quote from Erwin on November 8, 2021, 5:34 pmQuote from dandl on November 8, 2021, 12:22 amQuote from Erwin on November 7, 2021, 6:51 pmQuote from dandl on November 6, 2021, 2:17 amAnd new entrants start from so far behind that mostly they never catch up.
New entrants who let themselves be inspired by the TTM message (after having 'gotten' it, of course ...), start from so far ahead that the intended audience is never going to catch up in its lifetime.
Not really. SQL/Word/Excel/Java etc are like a city full of skyscrapers, Manhattan say. People live and work in every floor, every room, every cubicle. You come along and point out (quite correctly) that the foundations are wrong and the whole city would work better if they were put right. So you set out to create new foundations and add a couple of floors of one building, but you are so far behind because you can never build a new city. So everyone stays in the old one, because it's there, and it works, kind of.
The only change you get is once in a generation when a new city gets built, like for smart phones. But even then the battle is on to claim territory fast so they pick the tools to hand and replicate the same old mistakes. Or there is continuing battle over which tools to use and you get the Web. Either way, you never catch up. The money wins every time.
Until Manhattan becomes Detroit.
Or you can build yourself a nice house in the suburbs, exactly how you think it should be.
But you still don't get to choose your own infrastructure.
You may have a better way to do urban planning, street layout and construction, water, sewage, gas, power, light etc but you don't get to choose. You can only ever pick what is, built by others, and build on top of it. And to build an entire infrastructure from bare metal is too hard, too long, too expensive.
A TTM/D (or anything akin to it) can only gain traction if it (a) solves a data-related problem (b) fits with enough existing data-related infrastructure (c) is promoted (to people with that problem and that infrastructure).
The entire tottering edifice of software has exactly that same problem. It's all built on arbitrary shaky foundations hastily set down over some 60+ years with a meshwork of inter-dependencies that lock it all into place. If some bit fails, it gets patched.
Conceptually, I don't like Wrapd one little bit. Practically, it is exactly as it needs to be.
Quote from dandl on November 8, 2021, 11:28 pmBut you still don't get to choose your own infrastructure.
You may have a better way to do urban planning, street layout and construction, water, sewage, gas, power, light etc but you don't get to choose. You can only ever pick what is, built by others, and build on top of it. And to build an entire infrastructure from bare metal is too hard, too long, too expensive.
A TTM/D (or anything akin to it) can only gain traction if it (a) solves a data-related problem (b) fits with enough existing data-related infrastructure (c) is promoted (to people with that problem and that infrastructure).
The entire tottering edifice of software has exactly that same problem. It's all built on arbitrary shaky foundations hastily set down over some 60+ years with a meshwork of inter-dependencies that lock it all into place. If some bit fails, it gets patched.
Conceptually, I don't like Wrapd one little bit. Practically, it is exactly as it needs to be.
Yes. Conceptually, I don't like almost all of how IT is implemented.
Realistically, I unavoidably need to access SQL databases from Java code, so I've tried to make it as painless as possible.
And realistically, the only possible resolution to the SQL problem is a new database formalism of which SQL is a subset.
- SQL the language is trivial
- SQL the data model is complex: it can be formalised, but the RM is not enough.
- SQL the query model is reasonably simple, but the RA is not enough.
- SQL the operational model is just a set of libraries and procedures.
As the psychologist said to the lightbulb: first, you've got to want to change.
Quote from dandl on November 10, 2021, 12:40 amAnd realistically, the only possible resolution to the SQL problem is a new database formalism of which SQL is a subset.
- SQL the language is trivial
- SQL the data model is complex: it can be formalised, but the RM is not enough.
- SQL the query model is reasonably simple, but the RA is not enough.
- SQL the operational model is just a set of libraries and procedures.
As the psychologist said to the lightbulb: first, you've got to want to change.
I've yet to see a case where a manager bought or chose a tool based on its formalism. What is the formalism behind Java? Or C#? Or Node.js? Or MongoDB? Or React.js?
The problem, to the extent that there is one, is that the (majority of) developers and their managers who use SQL don't consider SQL to be a problem, so replacing it with a new-SQL/non-SQL SQL-replacement isn't a solution. It doesn't have a sufficient -- and in most cases, any -- justification.
And for the developers and their managers who don't use SQL, they choose various NoSQL products for the wrong reasons but the right marketing: The MongoDB pundits tell them it's new and better (for an undefined value of "better") than the dinosaur "relational model" that's 50 years old and therefore inherently bad. Remember, IT things are only good if they were made recently and, ideally, by young people and/or Facebook, er, Meta, etc. That may be a weak justification, but if your real justification is following fashion -- which it is for most decisions -- then it's good enough.
As I've said before, the commercial and/or market-penetrating opportunity here lies in convincing the decision-makers in some small (possibly very small) specialist niche that you've got a way of turning their money into more money or losing less money than the alternatives, and/or addressing an unsolved (or only solved with bespoke code) problem. They don't care whether it's formally defined or not -- or what model it's based on, if any at all -- as long as you can show that it does what it claims.
That, after all, is how popular NoSQL products earned their popularity -- they made inroads by being a viable solution in a few niches where SQL DBMS scalability was a serious problem.
Quote from Dave Voorhis on November 10, 2021, 9:34 amQuote from dandl on November 10, 2021, 12:40 amAnd realistically, the only possible resolution to the SQL problem is a new database formalism of which SQL is a subset.
- SQL the language is trivial
- SQL the data model is complex: it can be formalised, but the RM is not enough.
- SQL the query model is reasonably simple, but the RA is not enough.
- SQL the operational model is just a set of libraries and procedures.
As the psychologist said to the lightbulb: first, you've got to want to change.
I've yet to see a case where a manager bought or chose a tool based on its formalism. What is the formalism behind Java? Or C#? Or Node.js? Or MongoDB? Or React.js?
The problem, to the extent that there is one, is that the (majority of) developers and their managers who use SQL don't consider SQL to be a problem, so replacing it with a new-SQL/non-SQL SQL-replacement isn't a solution. It doesn't have a sufficient -- and in most cases, any -- justification.
And for the developers and their managers who don't use SQL, they choose various NoSQL products for the wrong reasons but the right marketing: The MongoDB pundits tell them it's new and better (for an undefined value of "better") than the dinosaur "relational model" that's 50 years old and therefore inherently bad. Remember, IT things are only good if they were made recently and, ideally, by young people and/or Facebook, er, Meta, etc. That may be a weak justification, but if your real justification is following fashion -- which it is for most decisions -- then it's good enough.
As I've said before, the commercial and/or market-penetrating opportunity here lies in convincing the decision-makers in some small (possibly very small) specialist niche that you've got a way of turning their money into more money or losing less money than the alternatives, and/or addressing an unsolved (or only solved with bespoke code) problem. They don't care whether it's formally defined or not -- or what model it's based on, if any at all -- as long as you can show that it does what it claims.
That, after all, is how popular NoSQL products earned their popularity -- they made inroads by being a viable solution in a few niches where SQL DBMS scalability was a serious problem.
No argument. Really. But that's not the point.
My point is that you can't build a new database ecosystem alongside SQL and expect anyone to use it just because it's 'better'. You can most certainly find niches that SQL doesn't serve, and much of NoSQL does exactly that. But if you ever wanted to build something to replace SQL and offered TTM-like features you would have to build a superset that swallowed them whole and offered something really valuable that isn't there right now.
It's a bad analogy, but SQL is kind of like the MS-DOS of database. You go through extended/expanded memory and character mode/GUI front ends, but eventually you need something like Windows, with MS-DOS as a subsystem but the real action in a new GUI and filesystem and memory model. And right now I don't see anyone willing to drop a billion or two on doing that, or what they would build if they did. But I expect (like Windows) it will be driven by hardware. Zettabyte databases anyone?