Re: One Ring to Bind Them

From: Eric Kaun <ekaun_at_yahoo.com>
Date: Wed, 16 Jun 2004 14:45:33 GMT
Message-ID: <h2Zzc.1822$Pt.1440_at_newssvr19.news.prodigy.com>


"Dawn M. Wolthuis" <dwolt_at_tincat-group.com> wrote in message news:can9nq$q7r$1_at_news.netins.net...
> Take a deep breath and then delegate ;-)

Unfortunately, I am the delegate...

> Both relational and declarative seem rather obvious choices to you and
> neither does to me.

I don't expect everyone to agree with me; I'll just point out that I've never worked in academia, and my opinion (however wrong) is based strictly on commerical work (some internal for the company, some for resale to customers) in the manufacturing, media, and print industries.

> My issues with declarative include:
>
> 1) There seem to be no standards for the black box that does something
with
> the declarations. I don't need standards-committees with years of process
> to adopt a standard -- I don't even know anything that would help ensure
> portability of such declarations. SQL has come the closest and does have
> standards, but we all know you can't just take any code you write against
> one database and run it against another.

True enough; SQL is so convoluted, and the standard so large, that it's difficult to implement. Contrast with the J2EE spec which, while also large (and overwritten in Sun's usual verbose style, writing 100 pages where 10 would do), is implemented fairly quickly by commercial and open-source vendors within 6 months of its release. SQL is atrocious.

That said, the standard for the black box should be a coherent spec, which implies the need for a coherent language.

> 2) It doesn't read like English -- the verbs are missing, for example.
I'd
> like to keep some of Grace Hopper's goal alive of writing code that human
> beings can read

I think that dream is dead. English is a poor basis for automation, and defining a useful subset would get us into even murkier water than the c.d.t glossary. Nonetheless, relational offers a more useful basic structure (the predicate, which is a sentence) than Pick/MV, which aspires to nouns. Objects also aspire to be nouns, leaving verbs and sentences "encapsulated", whatever that means (I know that it means, but doubt its utility in all things).

> 3) While hiding much that should be hidden, it "feels like" so much gets
> hidden that people spend time trying to figure out how it does things in
> order to be good at writing declarations

A valid criticism. I could chalk much of that up to the operationally-minded education of most programmers ("we're going to teach you to program just like a compiler writes machine code!"), but it is true that it's harder initially. I just think it would pay off, and that the learning curve, while somewhat steep, has dividends (and not just in the long term; perhaps in the "medium" range).

> 4) Invariably functions become one of the things to get specified. If we
> are going to specify both data and functions, which, afterall, is what
needs
> to happen,

But I draw a distinction between specifying a function and implementing it operationally. I can code a function in Java (even though I have to attach it to a class), but contrast that with any algebraic specification of a function; maybe something like Prolog, where you are simply defining terms using input patterns (pardon the gross oversimplification). True, you may have to optimize later; but you don't have to decide on the optimization (or on a sub-optimal algorithm) early.

> then what benefit is there to specifying a function and
> specifying where it is to be used rather than specifying the function and
> then using it where it needs to be used?

I'm not sure what you mean here. If you're arguing for the separation of data and function, I tend to agree; however, that's a very non-OO position to take... is that what you intended?

  • erk
Received on Wed Jun 16 2004 - 16:45:33 CEST

Original text of this message