Thanks for your response, James, and I agree with what you've said. My own language family, Muldis D, takes all of those things into account.
For examples of this: 1. Muldis D is a general purpose language like for applications but it also is fundamentally savvy to the needs and features of relational and SQL databases (and other kinds of databases). Users of typical application languages would find all the features they're used to having and that they work in familiar ways. Users of typical SQL DBMSs would also find all the features they're used to having and that they work in familiar ways. 2. One killer feature of Muldis D is that one can use one language to work in both the application and database worlds. The long-standing wishes of many developers, to either use SQL features in applications or application language features in the database, will be satisfied. Not to mention the desire to have things just work when moving data between the two. Data types and business logic constraints and routines are all shareable. 3. Another killer feature of Muldis D is that one can losslessly translate any DBMS' version of SQL to it and have it work as they expect. So users' investment in SQL is preserved. Even if the Muldis D syntax isn't a superset of SQL, its feature set is, and so it just takes a translation layer for existing SQL-using applications to continue to work unchanged. This includes the power features of SQL like stored procedures and triggers and custom data types, not just lowest common denominator stuff like simple CRUD. I'm not going to harp on this too strongly as I still have to make Muldis D execute, but hopefully it will by the end of this summer. The reference implementation is stand-alone like a typical application programming language, but subsequent implementations will cross-compile as possible to existing SQL DBMSs so the work in those engines can be leveraged as possible. The reference is standalone so I am not limited by what current DBMSs support to make it work. -- Darren Duncan On 2015-06-18 2:11 PM, James K. Lowden wrote: > On Wed, 17 Jun 2015 22:05:12 -0700 > Darren Duncan <darren at darrenduncan.net> wrote: > >> I also believe the world is ripe to have SQL alternatives, its just >> a matter of ones appearing that are compelling to users for real work >> and not just an academic exercise. The fact we're still generally >> with SQL means this hasn't happened yet, but that doesn't mean it >> won't. > > Yes, I've been keeping track of TTM-inspired projects, and tried to > convince Ingres to commercialize its D implementation. What makes > David's andl unusual is that it's a new language atop a DBMS that is > used in production. > > Still, I'm not so sure the world is ready for a better SQL. The > evidence stands against, certainly. We already discarded one -- QUEL -- > which hardly anyone remembers. A great deal of effort has gone into > replacing SQL with less powerful constructs with no theoretical > foundation, and into neutering the DBMS with ORM toys. > > Do not underestimate SQL's enormous inertia and network effect. > Recognize that even if the syntax is better, engineering > challenges remain if the promise of fidelity to the relational model is > to be realized. > > The inertia stems from laziness and ignorance, never in short supply. A > fraction of those who write SQL understand the math and logic > underlying it. Forums like Stack Overflow are rife with questions that > demonstrate as much; the answers are often not much better. If you're > not thinking in terms of relational algebra and are unaware of the > benefits of using logic to accomplish your task, changing syntaxes will > only compound your problems. If you *are* thinking in those terms, > it's still work to learn a new language. It's not clear that a better > syntax -- if that's all you get -- would be seen as a worthwhile effort > for very many people. > > The network effect is important, too. The market recognizes knowledge > of SQL as a skill (even if it underestimates its value). That skill is > portable across jobs and DBMS implementations. It is a way that > programmers communicate to each other across the organization and > time. A new language has to clear a threshold of "better" to be > accepted. > > There are two engineering challenges that come to mind: performance and > set-theory semantics. > > As David outlines in his blog, it's no mean feat to swap out SQL from > any DBMS, including SQLite. Because the query language is > assumed/known to be SQL, query planning, rewriting, transformation, and > optimization is bound up in the grammar of SQL itself. Readers of this > list appreciate how much work goes into that. > > Set-theory touches on the implementation, too. DISTINCT is > implied in andl. It was left out of SQL because it requires a sort. > The ramifications are nontrivial; consider joining on a nonkey and > counting the results. Also remember that SQLite violates even SQL's > set-theoretic features, such as when > > update T set X = X + 1 > > fails if X is declared unique. > > So I would say replacing SQL with andl or similar is in fact not > analogous to replacing Perl with Python or C++ with Go. The requisite > knowledge in the user community to appreciate the improvement is > greater (and relatively nonexistent). And the engineering effort to > build a DBMS is far more than to build a compiler. > > There's a reason Larry Ellison can affort a yacht almost 500 feet > long. > > --jkl > _______________________________________________ > sqlite-users mailing list > sqlite-users at mailinglists.sqlite.org > http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users >
