Re: The future of Ada is at risk

[Georg Bauhaus <rm.tsoh+bauhaus@maps.futureapps.de>]

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... ;-)