[
Lists Home |
Date Index |
Thread Index
]
1/12/2002 8:26:37 AM, Jonathan Robie
<jonathan.robie@softwareag.com> wrote:
> In general, when designing complex systems,
> I think it is very helpful to
> think in terms of declarative, testable
> architectures.
As usual, Jonathan makes an informed and well-argued
case for the typed/declarative orientation. The
only thing I'd disagree with is whether this is true
"in general" or mainly in a more limited set of
situations where one has:
- A well-defined and stable conceptualization of the
data, as we do for definition of a "limerick".
- Enough of a community of / market for
interoperating tools and users to make the
architectural investment worthwhile.
- Some sort of authority to encourage/enforce
compliance and manage schema evolution.
Perhaps ironically, I see that our great admirer :~)
Fabian Pascal (echoing much of C. J. Date's recent
work) makes an argument similar to Jonathan's in a
critique of the way SQL forces business rules and
integrity constraints to be validated by stored
procedures rather than declarative constraint
languages.
http://searchdatabase.techtarget.com/tip/1,289483,si
d13_gci788645,00.html
Maybe I have the "see worse is better everwhere"
pattern hard-wired in my brain, but that article
sure is eerily reminiscent of a lot of discussions
here! So, I'd leave Jonathan with the same question
that set Mr. Pascal off into a long rant a few
months back: If the logical / declarative /
architectural "right thing" is such a good GENERAL
prescription for building information systems, why
is it so rarely practiced in the Real World?
My proposed answer is much like my recent reply to
Al Snell about the upfront design vs incremental
evolution: If you have well-known and stable
requirements and some way to enforce compliance,
"declarative, testable architectures" designed up
front will lead to success; if you don't, something
more like extreme programming / well-formed XML /
procedural scripting will tend to be more pragmatic.
|
