Re: Declarative constraints in practical terms

Hi Ralph,

ralphbecket_at_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 Received on Sun Feb 26 2006 - 01:05:27 CET