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!news3.google.com!feeder1-2.proxad.net!proxad.net!feeder2-2.proxad.net!newsfeed.arcor.de!newsspool1.arcor-online.net!news.arcor.de.POSTED!not-for-mail Newsgroups: comp.lang.ada Subject: Re: The future of Ada is at risk From: Georg Bauhaus In-Reply-To: <186n1dt34b84r.1jjg9vmd48kbs.dlg@40tude.net> 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> Content-Type: text/plain Content-Transfer-Encoding: 7bit Message-Id: <1199650387.8241.27.camel@K72> Mime-Version: 1.0 X-Mailer: Evolution 2.12.1 Date: Sun, 06 Jan 2008 21:13:07 +0100 Organization: Arcor NNTP-Posting-Date: 06 Jan 2008 21:13:07 CET NNTP-Posting-Host: 2d2947bc.newsspool4.arcor-online.net X-Trace: DXC=c864Sk`Em8f>jlK2>IgHGd4IUK\BH3YbOZ4\5]]^gKjA:ho7QcPOVcc7YDKXWbZ>k0F8XH]@CTIe X-Complaints-To: usenet-abuse@arcor.de Xref: g2news1.google.com comp.lang.ada:19242 Date: 2008-01-06T21:13:07+01:00 List-Id: 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. OO classes are closer to attribute sets than they are to relational expressions---unless they try to implement a better SQL. Go ahead! ;-) A relational expression has yet to find its way into pure Ada. If you have something ... ;-) > 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? > 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). This is why every now and then someone suggests ActiveRelation instead of ActiveRecord. So far, there are no results AFAICT. > 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? > 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... ;-)