Frankly, I've avoided taking a close look at Andl because of its massive use of 
special characters.  I can usually work out a rough meaning on your examples 
because I know the SQL it came from.  If I became 'Andl proficient' it probably 
wouldn't be a problem, but I gotta ask.. what's the issue with just using 
keywords?  I feel like I'm looking at APL.

-----Original Message-----
From: sqlite-users-bounces at mailinglists.sqlite.org 
[mailto:sqlite-users-bounces at mailinglists.sqlite.org] On Behalf Of 
da...@andl.org
Sent: Thursday, June 18, 2015 10:59 AM
To: 'General Discussion of SQLite Database'
Subject: Re: [sqlite] Mozilla wiki 'avoid SQLite'

Yes, yours is the kind of situation Andl is aimed at. It does most of that 
stuff, but it's not ready for prime time yet. It's amazingly good at doing 
complex queries in just a few lines of code, but it lacks the external 
connections for it to be used for real applications.

I don't really understand the 'row access' or 'multiple row sets' in terms of 
the need being filled, and what Andl has to do to meet it. Hopefully this will 
come out if and when people try to use it to do real work.

Regards
David M Bennett FACS

Andl - A New Database Language - andl.org

-----Original Message-----
From: sqlite-users-bounces at mailinglists.sqlite.org 
[mailto:sqlite-users-boun...@mailinglists.sqlite.org] On Behalf Of Marc L. Allen
Sent: Thursday, 18 June 2015 11:51 PM
To: General Discussion of SQLite Database
Subject: Re: [sqlite] Mozilla wiki 'avoid SQLite'

I don't understand all the issues with SQL as it is today.  I doubt I'm at the 
level of most of the posters in this group.  However, I do write a mess of it 
so I thought I'd give my two cents as a programmer.

For what it does, SQL does it really well.  That is, it takes a couple of sets 
of data, links them together and returns a set of data with given relations.  
But, that's just not enough.  

Recursive SQL is one of the best things to happen to SQL, though the syntax is 
rather wonky.  But, I think it's done that way because SQL is NOT a programming 
language and we keep trying to turn it into one.  Ok.. not turn it into one, 
per say, but we want to, quite often, do programming-like work on the data as 
part of the 'linking' process.  This is especially prevalent in the systems 
supporting stored procedures.  Personally, I find it a pain to combine SQL and 
programming in code.  First, I have to generate the SQL, then I have to do 
whatever is necessary to iterate over the result set, often requiring 
additional SQL and additional iteration.  So, if SPs are available, I tend to 
put a lot of logic in them and, frankly, SQL and it's variants really aren't 
good at that.  Furthermore, the SQL environment is not part of the controlling 
programming environment and that causes additional problems.  It's also slow to 
go back and forth, especially when the application and database are separated.

I guess, at the end, is that I  need a data language that has both set 
operations and iteration operations.  I would want a language or construct that 
gives me row access during the operations so that I can finely tune the 
actions.  Sort of an OnRow() function that works for all SQL operations.  Also, 
the ability to split the incoming row set into multiple row sets for different 
purposes. Also... (insert weird data flow operation that doesn't exist 
natively).

As I read back through this, I realize how poorly stated it is.  But, I'm going 
to post it anyhow.  Maybe someone will say, "Hey, stupid... *this* exists.. try 
it."  Heck, maybe Andl does it.  I haven't looked.

Marc

-----Original Message-----
From: sqlite-users-bounces at mailinglists.sqlite.org 
[mailto:sqlite-users-bounces at mailinglists.sqlite.org] On Behalf Of 
da...@andl.org
Sent: Thursday, June 18, 2015 6:36 AM
To: 'General Discussion of SQLite Database'
Subject: Re: [sqlite] Mozilla wiki 'avoid SQLite'

I agree. It would be relatively easy to produce a new language with a syntax 
based on SQL, which was superficially familiar, but there are many necessary 
differences at the lower levels. One issue where bullet biting is needed is 
nulls and three-valued logic; another is duplicate rows and nameless or 
duplicate columns. The type system needs a complete overhaul too. C was a 
clean, polished and quite small language; SQL is none of those.

And the biggest thing? Most SQL is used as a data sub-language, but the need is 
for a complete database programming language and a way out of the ORM mess. You 
can't get that from putting a layer on top of SQL.

Regards
David M Bennett FACS

Andl - A New Database Language - andl.org

-----Original Message-----
From: sqlite-users-bounces at mailinglists.sqlite.org 
[mailto:sqlite-users-boun...@mailinglists.sqlite.org] On Behalf Of Darren Duncan
Sent: Thursday, 18 June 2015 5:29 PM
To: General Discussion of SQLite Database
Subject: Re: [sqlite] Mozilla wiki 'avoid SQLite'

I disagree with the idea that a good SQL alternative would just be a superset 
of SQL as you propose.

That has already been done numerous times, the principal manifestations being 
each SQL DBMS that has its own small or large differences in syntax and 
features from each other.

SQL is already a very complex language due in part to most of its features each 
having their own custom syntax, often several variations per feature to boot, 
as well as lots of arbitrary limitations or specified inconsistent behaviors, a 
lot of these for keeping backwards compatibility with various old or 
vendor-specific ways of doing things.

What a good SQL alternative would actually be is a much more self-consistent 
and less redundant than SQL.  It would still have all of SQL's expressive power 
and features so that any SQL code can be translated to it, including 
automatically, without too much circumlocution.  That is how you would simplify 
the transition and re-utilization of existing code.  The good alternative would 
actually be easier for a DBMS to implement also without losing any power.

-- Darren Duncan

On 2015-06-17 11:52 PM, ajm at zator.com wrote:
> Indeed, I'm agree with Darren, and continuing its thought, perhaps that 
> hypothetical new language would be a clean extensi?n of SQL in the same way 
> that C++ was respect to C, simplifying the transition and reutilization of 
> legacy code.
>
> Cheers.
>
> --
> A.J. Millan
>>
>> ---- Mensaje original ----
>> De: <david at andl.org>
>> Para:  "'General Discussion of SQLite 
>> Database'"<sqlite-users at mailinglistssqlite.org>
>> Fecha:  Thu, 18 Jun 2015 14:50:40 +1000
>> Asunto:  Re: [sqlite] Mozilla wiki 'avoid SQLite'
>>
>> The question for now is: does a new database programming language 
>> have a place?

_______________________________________________
sqlite-users mailing list
sqlite-users at mailinglists.sqlite.org
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users

_______________________________________________
sqlite-users mailing list
sqlite-users at mailinglists.sqlite.org
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users



This email and any attachments are only for use by the intended recipient(s) 
and may contain legally privileged, confidential, proprietary or otherwise 
private information. Any unauthorized use, reproduction, dissemination, 
distribution or other disclosure of the contents of this e-mail or its 
attachments is strictly prohibited. If you have received this email in error, 
please notify the sender immediately and delete the original.
_______________________________________________
sqlite-users mailing list
sqlite-users at mailinglists.sqlite.org
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users

_______________________________________________
sqlite-users mailing list
sqlite-users at mailinglists.sqlite.org
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users



This email and any attachments are only for use by the intended recipient(s) 
and may contain legally privileged, confidential, proprietary or otherwise 
private information. Any unauthorized use, reproduction, dissemination, 
distribution or other disclosure of the contents of this e-mail or its 
attachments is strictly prohibited. If you have received this email in error, 
please notify the sender immediately and delete the original.

Reply via email to