Path: dp-news.maxwell.syr.edu!spool.maxwell.syr.edu!news-spur1.maxwell.syr.edu!news.maxwell.syr.edu!postnews.google.com!i40g2000cwc.googlegroups.com!not-for-mail
From: "Alfredo Novoa" <alfredo_novoa@hotmail.com>
Newsgroups: comp.databases.theory
Subject: Re: Declarative constraints in practical terms
Date: 25 Feb 2006 16:05:27 -0800
Organization: http://groups.google.com
Lines: 82
Message-ID: <1140912327.578922.244610@i40g2000cwc.googlegroups.com>
References: <1140555731.823399.160020@g44g2000cwa.googlegroups.com>
   <43fb9f3f$0$11061$e4fe514c@news.xs4all.nl>
   <1140572636.412425.167160@f14g2000cwb.googlegroups.com>
   <43fcaa00$0$11073$e4fe514c@news.xs4all.nl>
   <1140635869.277415.201510@g44g2000cwa.googlegroups.com>
   <1140657194.873638.147660@g47g2000cwa.googlegroups.com>
   <1140728544.042637.68440@z34g2000cwc.googlegroups.com>
   <1140744043.908869.248700@u72g2000cwu.googlegroups.com>
NNTP-Posting-Host: 85.49.128.149
Mime-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
X-Trace: posting.google.com 1140912332 6265 127.0.0.1 (26 Feb 2006 00:05:32 GMT)
X-Complaints-To: groups-abuse@google.com
NNTP-Posting-Date: Sun, 26 Feb 2006 00:05:32 +0000 (UTC)
In-Reply-To: <1140744043.908869.248700@u72g2000cwu.googlegroups.com>
User-Agent: G2/0.2
X-HTTP-UserAgent: Mozilla/5.0 (Windows; U; Windows NT 5.1; es-ES; rv:1.8.0.1) Gecko/20060111 Firefox/1.5.0.1,gzip(gfe),gzip(gfe)
Complaints-To: groups-abuse@google.com
Injection-Info: i40g2000cwc.googlegroups.com; posting-host=85.49.128.149;
   posting-account=joxBkAwAAADsPEyGCMIJ7NnYIJVUS3AU
Xref: dp-news.maxwell.syr.edu comp.databases.theory:36870


Hi Ralph,

ralphbecket@gmail.com ha escrito:

> Specifications should be (and usually are) given in a declarative
> language (e.g., first order logic) which can only state *what* the
> invariant is, not *how* it should be computed or maintained.
>
> If the specification is implemented in an adequately expressive
> declarative implementation language (such as that provided by
> the DBMS), at most all one needs to do is make slight changes to
> the syntax in the spec.

I use to write the specification directly in the (declarative)
implementation language with very good results.

> Virtually all industrially used languages however (such as Java)
> are imperative.

And procedural.

Declarative languages like Tutorial D are also imperative.

>  That means they are based almost entirely on the
> notion of specifying *how* a process should be carried out, but
> pay little or no attention to saying anything about *what* the
> process is (or should be) computing.

This is the difference between procedural and declarative languages,
although it is very common to confuse imperative programming with
procedural programming and functional programming with declarative
programming.

> >  Do coders who write constraints
> > declaratively code more accurately and more quickly?
>
> Yes, in my experience - but then I am a Mercury developer.
> Plug: www.mercury.cs.mu.oz.au

The best thing about declarative constraints is that they might be
written by the functional analysts (in case they have a brain }:).

> Well... I know of one commercial company that has just replaced a
> 1.5 million line Java multiple insurance database system with 3000
> lines
> of Mercury plus some meta-data files.

Interesting numbers. They match very well with my own experience. The
difference in code size between procedural and declarative code grows
exponentially.

> > This makes sense to me.  It brings me to the question I'm not supposed
> > to ask about whether there is any data to support a conclusion that
> > constraints specified to a DBMS provide better performance in the final
> > solution than those specified in other code.
>
> Do you really find it plausible that human coders could do better than
> an automatic optimiser on a day to day basis?  Especially where these
> coders are already struggling with concurrency and distribution and
> don't have access to internal DB structures?

Don't take Dawn seriously, she is a well known troll.

But the most important issue is not a marginal performance difference.
Optimizers do their work for free in miliseconds without mistakes, and
coders don't.

Optimizers are nothing but mechanic coders and to replace manual labour
by optimizers is mechanization.

http://en.wikipedia.org/wiki/Mechanization

To be against mechanization is called technophobia. Dawn is a
Neo-Luddite

http://en.wikipedia.org/wiki/Luddite


Regards
  Alfredo

