P.S. Since Daniel cc'd the list with a reply, I will likewise.
Daniel Ruoso wrote:
Sorry for bitching, but...
What exactly is the problem you're trying to solve? I mean, what is so
bad about SQL? and how does Muldis D solves it?
The very broad answer: It's not so much that SQL is terrible; it does the job
reasonably well but I do see it being deficient in a variety of ways. Muldis D
is my way to address those deficiencies without needing to keep backwards
syntactical compatibility. I see a huge degree of similarity between the
purpose of Muldis D and its relationship to SQL, and the purpose of Perl 6 and
its relationship to Perl 5. Lots of people think Perl 5 does the job just fine
too and are horrified by Perl 6's seemingly much greater complexity (borne
mainly out of misunderstanding/ignorance), but I think Perl 6 is beautiful and a
huge improvement and not more complicated in practice, even arguably less
complicated. Likewise I think about Muldis D versus SQL. Even more broadly
speaking, efforts like this in making new or improved languages is a way the
industry moves forward.
A few specific answers, off the top of my head: SQL is inconsistent with itself
in a variety of ways that can trip people up, and it has some unnecessary
limitations. For example, in some contexts NULL matches itself and in other
cases it doesn't. If you want to store a table inside a table you have to use
special operators like "MULTISET UNION" to work with them when you should be
able to use the same "UNION" as normal tables. SQL is natively multiset
oriented so a wide variety of queries that users would expect or want to give
the same answer in fact give different answers so you have to litter code with
keywords like DISTINCT to force what you want. For reasons including that, SQL
is a lot more work to optimize since a lot of what would otherwise be safe
optimizations can't be used since they might change the semantics, whereas with
set semantics that Muldis D natively has, lots more optimizations are safe. And
users are less likely to have bugs. Also SQL has the complexity of many
size-specific variants of the same data type rather than just offering a more
generic choice; eg different sizes of numbers or text. Also SQL has grown
highly unportable over the years with large degrees of difference between
vendors in all but the most trivial (albeit common) tasks. Also many
implementations don't let users define their own data types / object classes.
So Muldis D exists to make using databases more friendly to both DBAs and
regular application developers, as well as severely reduce database vendor lock
in because it provides a means today to effectively translate code between
different SQL vendors, including the investment of stored procedures etc which
are a large part of the effective vendor lock-in of a non-tiny program.
Honestly, it feels weird to me that you propose a query as simple as
SELECT 1
turning itself into a function declaration, with a lot of boilerplate
around...
Actually those aren't direct comparisons. For a direct comparison, the Muldis D
analogy of that is just:
1
... same as in Perl, assuming a scalar result is what you actually wanted, as
people who write such things usually do.
Similarly, the SQL:
SELECT * FROM foo
... is just:
$foo
... same as Perl. So such are trivial cases where the SQL is clearly more
complicated.
As for my "boilerplate", Muldis D is focused around the paradigm of storing your
database access code in the database analagous to SQL stored procedures, and so
all your actual database queries are invocations of stored procedures. Which is
common practice in databases of medium to large size.
So then a more direct comparison to the Muldis D code:
procedure proc1 (Relation &$result) {
$result := $dep.foo;
}
... is like this (pseudo?) SQL code:
CREATE PROCEDURE proc1 (result ARRAY INOUT)
BEGIN
SELECT * INTO result FROM foo;
END;
I hope that answers your question.
-- Darren Duncan
