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=-0.3 required=5.0 tests=BAYES_00, REPLYTO_WITHOUT_TO_CC autolearn=no 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!news3.google.com!news.germany.com!newsfeed01.sul.t-online.de!t-online.de!newsfeed.arcor.de!newsspool1.arcor-online.net!news.arcor.de.POSTED!not-for-mail From: "Dmitry A. Kazakov" Subject: Re: The future of Ada is at risk Newsgroups: comp.lang.ada User-Agent: 40tude_Dialog/2.0.15.1 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Reply-To: mailbox@dmitry-kazakov.de Organization: cbb software GmbH References: <20071229040639.f753f982.coolzone@it.dk> <878x3436pj.fsf@ludovic-brenta.org> <1199531506.9355.8.camel@K72> <1199539751.9355.46.camel@K72> <1xu2jerm6vwjv.mt6we9a8wu5q.dlg@40tude.net> <1199621128.7300.72.camel@K72> <186n1dt34b84r.1jjg9vmd48kbs.dlg@40tude.net> <1199650387.8241.27.camel@K72> Date: Sun, 6 Jan 2008 21:50:35 +0100 Message-ID: <1r4o6yx7es25v$.p02lmth61gt0$.dlg@40tude.net> NNTP-Posting-Date: 06 Jan 2008 21:50:36 CET NNTP-Posting-Host: af177488.newsspool2.arcor-online.net X-Trace: DXC=fhbX@LTWNW0U`5g[@c]@J1A9EHlD;3Yc24Fo<]lROoR1nkgeX?EC@@0BPC4[HS>6F1S=V: X-Complaints-To: usenet-abuse@arcor.de Xref: g2news1.google.com comp.lang.ada:19244 Date: 2008-01-06T21:50:36+01:00 List-Id: On Sun, 06 Jan 2008 21:13:07 +0100, Georg Bauhaus wrote: > On Sun, 2008-01-06 at 13:23 +0100, Dmitry A. Kazakov wrote: >> On Sun, 06 Jan 2008 13:05:28 +0100, Georg Bauhaus wrote: >> >>> On Sun, 2008-01-06 at 09:42 +0100, Dmitry A. Kazakov wrote: >>> >>>>> http://www.djangoproject.com/documentation/model-api/ >>> >>>> Yes, that looks pretty much like it should be, IMO. >>> >>> Did you notice that they provide anyone with direct access >>> to SQL in order to do non-trivial relational things? >> >> You can do assembler insertions in Ada. The relation must be same. > > Quite to the contrary, SQL is a very high level language. I don't care. The only question is how frequently one would need an insertion of raw SQL. >> Ada design never considered premature, close-to-hardware optimization as a >> priority. > > However, the Ada design explicitly considers close-to-hardware > programming a priority because of resource consumption and > timing. A similar situation exists with real-world SQL programming: > when a result set must be established within soft real-time > constraints and within a given amount of available memory. > Updates must not take longer than a given duration. > Working within these constraints is not in any way premature > optimization IMHO, but rather a way to achieve the minimal goals. > What will be *mature* optimization if fulfilling the requirements > using high level, non-trivial SQL is premature optimization? Is it about algorithms or about vendor-X specific non-standard SQL stuff? Either is a good reason why there should be no SQL-bindings. >> Further I doubt very much that performance problems could be imposed by >> bindings. > > In bindings such as the one you have seen, joins, key relations etc. > are built in the scripting language. The reason given is because MySQL > ISAM tables support very few features of basic SQL. "So we do > it ourselves...", i.e., try to reinvent the wheel, with moderate > success. The Ruby on Rails community quite honestly advises > against deviation from the Rails ways (... :). This means, if > a database module requires slightly more relational power than > standard framework objects have, you should "revert" to SQL (to > the higher conceptual level that is). I don't see the point, sorry. >> 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. >> I don't see how >> reasonably designed DB bindings would force you to choose a wrong >> algorithm... > > Something in this sentence is begging the question... ;-) Why? You told me how high level SQL is. I am impressed and presume that all work will be done outside the bindings. So whatever performance problems you will get, that will not because of bindings, they are all yours. -- Regards, Dmitry A. Kazakov http://www.dmitry-kazakov.de