Agreed. Two points. 1. Andl can never replace SQL in one step. The challenge is to find some useful niche and demonstrate an end-to-end solution to a problem, and show that as a total solution it's better than could be done with SQL. It should have a cross-platform front end UI/UX (say JavaScript, Java or Ruby but NOT C#/.NET) and (for now at least) a backend on SQLite, with Andl in the middle and NO ORM.
2. Despite what you might think, Andl is an easy language to learn. However, using it to do real work is a major challenge because the theoretic underpinnings are unfamiliar to most people. Actually solving problems using relations and operations on relations is new, even to very expert SQL users. There are many interesting problems that can be solved in just a few lines, but mentally constructing the steps to those few lines is tough. The time taken to write the Sudoku solver on the web site is way out of proportion to the length. Regards David M Bennett FACS Andl - A New Database Language - andl.org -----Original Message----- From: sqlite-users-boun...@mailinglists.sqlite.org [mailto:sqlite-users-bounces at mailinglists.sqlite.org] On Behalf Of James K. Lowden Sent: Friday, 19 June 2015 7:11 AM To: sqlite-users at mailinglists.sqlite.org Subject: Re: [sqlite] Mozilla wiki 'avoid SQLite' 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
