Re: The wisdom of the object mentors (Was: Searching OO Associations with RDBMS Persistence Models)

From: x <>
Date: Tue, 13 Jun 2006 16:41:11 +0300
Message-ID: <e6mf2r$d7c$>

"Robert Martin" <> wrote in message news:2006061313220738165-unclebob_at_objectmentorcom...
> On 2006-06-01 04:09:29 +0200, J M Davitt <> said:
> > An important clarification is needed here: when relational theory
> > advocates talk about data integrity they are talking about constraints
> > which are expressed in declarative language. The superiority of
> > declarative v. imperative languages has long been decided.

> In some circles. The one important circle where it has not been
> decided is the circle application programming. Prolog failed. ML and
> the other functional language are faring no better (and are, after all,
> a mix of declarative and imperative styles).

It would be interesting to hear the opinions from comp.lang.prolog on this matter. :-)
Search for Erlang for an example of a failed declarative language.

> Declarative syntax in the
> application world has not yet succeeded. And I doubt it is likely to
> succeed in the near future.

Syntax ?

> I think the reason is known. Application programming is rich in
> behavior. And it is difficult to describe behavior declaratively.

Not difficult at all. It's easyer.

>You need things like "The Cut" (a highly non-declarative feature of prolog
> that nobody could figure out how to get rid of.)

Nobody ? Do you know Nobody ? Have you meet him ? Why it is "The Cut" "highly non-declarative" ?

> Note, I am not debating whether declarative is better than imperative
> or not. IMHO when declarative syntax can be used, it is often very
> valuable. But it doesn't seem to work for everything.

Syntax ?

> > In part,
> > data dogs slam OO languages because they are, essentially, procedural,
> > and building systems using them is extremely difficult.

> I agree. OO languages are the worst way of building applications,
> except for all the others.

Worst in what way ?

> > Sure, you can
> > settle upon "design patterns" and conventions which help all the parts
> > fit together, but complexity abounds and the pile of code is littered
> > with artifacts which exist only because of the technology chosen.

> This is not a symptom that "the data dogs" can exclude themselves from.
> They too have their own little artifacts that are related to
> technology. We could make the observation that in both cases this is a
> matter of skill rather than an intrinsic failure of the idea.

Those little artifacts are due to "the code dogs" who could not understand what they were asked to implement and why. Received on Tue Jun 13 2006 - 15:41:11 CEST

Original text of this message