On 2015-06-18 3:35 AM, ajm at zator.com wrote: > Darren: > > Maybe you're right. But to that relationship of "goodness" that would be > desirable, perhaps we should add a few drops of pragmatism. Experience shows > that in many cases, the perfect is the enemy of the good, and despite a > disrupting transition (refusing the bad legacy of SQL) can avoid some > drawbacks, however a non-disrupting evolution, has the advantage of being > more easily accepted and assimilated by the users, as has happened before.
I'm not proposing "perfect" at all, but rather I don't agree that the best solution is to be perfectly backwards-compatible with SQL such that all SQL code is also valid code in the new language, as you are proposing. I don't think you realize just how complicated SQL as a whole is. What SQLite implements is just a small subset of it. Just the core part of the ISO SQL 9075-2:2011 language spec is about 1466 pages long and that leaves a lot out. Besides this, various dozens SQL DBMS vendors have their own proprietary additions or differences. Even just taking a subset an extending that, isn't innovating beyond existing current practices, and we have dozens of those variants. A lot of existing popular application languages have a much smaller language complexity than SQL does. What I'm proposing as good is something more comparable in complexity to those, while still being able to express everything you can in SQL without any greater verbosity or difficulty in understanding. One primary way to achieve that is to represent nearly all operators / actions using generic routine call syntax rather than custom syntax per operator, which is what languages like C, C++, C#, Java, etc do. For such as these, the language itself is fairly small, and most of the details are just in the libraries. SQL supports libraries too, eg stored procedures/functions/etc but an inordinately large number of built-ins are not expressed in those terms. It is very reasonable to have generic syntax function calls to represent the various parts of a SQL SELECT for example, similar to how we have array or set or whatever routines in application languages today. That makes the syntax relatively simple and user-extensible, and it by no means prevents a DBMS from doing any query rewriting or optimizing or rearranging whatever it wants to do to implement the over-all expression efficiently, in fact a DBMS may even have an easier time of it. Don't get me wrong, a new language can have these qualities and still look familiar to SQL users, its not like it means using APL etc. -- Darren Duncan
