From mboxrd@z Thu Jan  1 00:00:00 1970
X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me
X-Spam-Level: 
X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00 autolearn=ham
	autolearn_force=no version=3.4.4
X-Google-Thread: 103376,a0be06fbc0dd71f1
X-Google-Attributes: gid103376,public,usenet
X-Google-Language: ENGLISH,ASCII-7-bit
Path: 
 g2news1.google.com!news4.google.com!feeder1-2.proxad.net!proxad.net!feeder1-1.proxad.net!feeder.news-service.com!newsfeed.freenet.de!newsfeed01.chello.at!newsfeed.arcor.de!newsspool1.arcor-online.net!news.arcor.de.POSTED!not-for-mail
Date: Sun, 06 Jan 2008 23:12:02 +0100
From: Georg Bauhaus <rm.tsho+bauhaus@maps.futureapps.de>
User-Agent: Thunderbird 2.0.0.6 (X11/20071022)
MIME-Version: 1.0
Newsgroups: comp.lang.ada
Subject: Re: The future of Ada is at risk
References: <20071229040639.f753f982.coolzone@it.dk> <flnlmp$su$1@online.de>
 <878x3436pj.fsf@ludovic-brenta.org> <1199531506.9355.8.camel@K72>
 <vh1ezr05krrf.1fhfhd3lm8h6a.dlg@40tude.net> <1199539751.9355.46.camel@K72>
 <1xu2jerm6vwjv.mt6we9a8wu5q.dlg@40tude.net>
 <sa41w8v7s3m.fsf@snoopy.microcomaustralia.com.au>
 <pjh0xejxnqdn$.1k74da00vqix8.dlg@40tude.net> <1199621128.7300.72.camel@K72>
 <186n1dt34b84r.1jjg9vmd48kbs.dlg@40tude.net> <1199650387.8241.27.camel@K72>
 <1r4o6yx7es25v$.p02lmth61gt0$.dlg@40tude.net>
In-Reply-To: <1r4o6yx7es25v$.p02lmth61gt0$.dlg@40tude.net>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Message-ID: <47815232$0$25381$9b4e6d93@newsspool4.arcor-online.net>
Organization: Arcor
NNTP-Posting-Date: 06 Jan 2008 23:12:02 CET
NNTP-Posting-Host: 640b9801.newsspool4.arcor-online.net
X-Trace: 
 DXC=bbB?T^fB@a]<<0iRN7DLEQ4IUK<Cl32<Q4Fo<]lROoRQFl8W>\BH3YROZ4\5]]^gKZA:ho7QcPOVSc7YDKXWbZ>[XgK=3e?0fE_
X-Complaints-To: usenet-abuse@arcor.de
Xref: g2news1.google.com comp.lang.ada:19247
Date: 2008-01-06T23:12:02+01:00
List-Id: <comp.lang.ada>

Dmitry A. Kazakov wrote:

>>>  Usually such problems have algorithmic nature.
>> Database performance problems are just like functional
>> language performance problems: The simple and elegant
>> expressions tend to be too resource consuming and must be
>> rewritten until they become efficient.
>> How would a purely relational type system remove this issue?
> 
> What has it to do with bindings? If you think that my goal is to search for
> the Holly Grail of RA, then you get me wrong. I don't care about relational
> purity.

OK, I see. Then SQL should be fine.
For me, a good compromise is this: problem domain abstractions
in Ada and then the most direct link between my Ada types and
the linguistic mechanism controlling the RDB: plain old SQL.
My programs are then written in two languages, and the connection
between the two source parts is easy, regular, and manageable.

Every ambitious binding I have seen so far isn't near the ease of a
working solution: basically, write SQL.  The most powerful thing I have
seen is CLSQL. Since Lisp tends to be most useful as a metaprogramming
language, you can do all kinds of complex magic in very clever
convolutions. Besides that, if you think of your RA type system,
will it look like SQL using Ada?