[cap-talk] How desirable / feasible is a persistent OCAP language?

[ihab.awad at gmail.com]

On Thu, Jul 17, 2008 at 11:29 AM, Jonathan S. Shapiro <shap at eros-os.com>
wrote:

> Yes, but if you actually have such a turing-complete constraint
> language, you discover that *that* has limitations too:
>

I suspect you interpreted more theoretical meat to my comment than I
intended. :)

I was proposing that there is a way to take the "database is the single
point of truth" design pattern to heart without carrying over the "database
is programmed in a weird language that only the DBA knows or cares about"
problem.

The RDBMS constraint mechanisms are too simple to give meaningful
application-level correctness, and the ways people get around them make it
once more possible to introduce bugs by bad programming. So maybe, as a
matter of design pattern, one should just program a persistent vat that acts
as a system's "mnemone", maintaining persistent state, in one's favorite
language, but keeping things as simple as possible to avoid upgrade
headaches. Then pretend that this is the SQL database with which we are
familiar.

See Benjamin Pierce's "Types Considered Harmful":
>

Seen and duly humbled. :)

Ihab

-- 
Ihab A.B. Awad, Palo Alto, CA
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.eros-os.org/pipermail/cap-talk/attachments/20080717/ff4a6b77/attachment.html