Re: Decline of Science: Computer Science and Databases

On Fri, 8 Nov 2002 23:35:44 +0100, "Carl Rosenberger" <carl_at_db4o.com> wrote:

>Lauri Pietarinen wrote:
>> > We want development at all levels:
>> > - More precise code at low level.
>> > - More powerful syntax at high level.
>>
>> One of the problems with coding is that it is
>> very error-prone.
>
>In comparison to what?

Reading, writing, or understanding just about any other kind of language, because of the assumptions and limitations hidden behind any computer language.

>Constraints are code like any other code.

Declarative code is not the same as procedural code. Declarative code seems to be higher level and more comprehensible to most people than procedural code, which has to include a lot of housekeeping at some level to get anything done.

>The advantage of contraints, as they are typically used:
>- They are very simple expressions that a human can read
>and understand at one glance.
>- They operate at a higher level with a higher priority
>than application code.
>
>If you use different levels of priority within OO code,
>you can build up much more powerful and more complex
>"constraints" than with the constraints that we know from
>relational databases.

Probably not true if the problem is understood and the db design is done properly.

>What you need is a clear separation between check-logic
>and modification logic.

What you actually need is a clear separation between inviolable basic rules and higher level logic that should not need to concern itself with the basics.

> "order.customer may not be null"
>
>is the same as
>
> if(order.customer == null){
> throw new ConstraintViolatedException();

better:

        throw new NullCustomer(order);

> }
>
>> The idea in the RM approach is to be able
>> to state declaratively as much as possible.
>> We might have to add some code but
>> the "dumb, stupid, boring" stuff should
>> and could be generated automatically.
>
>We invented OO programming to do more complex tasks:
>Object orientation tries to break up all data, all
>methods, all events into small, smaller, tiny little
>chunks, that are small enough that a human can
>understand them at one glance.

That a human can understand one of them at a glance: unfortunately the big picture may require understanding all of them, and OO may get in the way here, as does any code, by spreading a piece of information (not data) all across hell's half acre.
If you want to do more complex tasks, you have to work at a more abstract level than tiny chunks of data: you delegate the mundane drudgery to the database, let it handle the nitty-gritties, and throw an exception when it complains.
OO actually tries to keep everything related to some part of the model together, to simplify and localize change, not break everything up.

>If you have a complex rule, your rule statement may
>be 15 monitor pages long and nobody will be able to
>maintain it.
>
>Object orientation solves the problem.

Object orientation requires all the rules be specified correctly in procedural code that humans find difficult to understand and maintain without screwing up the rule.
Specifying the same complex rule in your OO code may spread the pieces across 150 monitor pages that nobody will be able to comprehend as a whole.
I've seen a lot of code that's only concerned about its needs and not the desired end result: it's a pain to understand and a joy to rewrite.

>What we need though, is frameworks and APIs that simulate
>the features that relational databases have acquired in
>the long history of data management:
>
>- constraints
>- different levels of priority
>- APIs that can do, what SQL can do and more.

Why reinvent the wheel? A problem has been solved by relational databases: trying to do the same job in code has proved disastrous in the past, which is why it is entrusted to the db layer; specify the absolutes once and forget. Declarative, non-procedural approaches as used in dbs seem to be easier for more people to understand.
Rules should be broken down into their component parts and each part be able to be specified independently if the db design is done properly; or better, not specified, but be an inherent part of the db design, or indeed any system design.

Thanks. Take care, Brian Inglis Calgary, Alberta, Canada

-- 
Brian.Inglis_at_CSi.com 	(Brian dot Inglis at SystematicSw dot ab dot ca)
    fake address		use address above to reply
abuse_at_aol.com tosspam_at_aol.com abuse_at_att.com abuse_at_earthlink.com 
abuse_at_hotmail.com abuse_at_mci.com abuse_at_msn.com abuse_at_sprint.com 
abuse_at_yahoo.com abuse_at_cadvision.com abuse_at_shaw.ca abuse_at_telus.com 
abuse_at_ibsystems.com uce_at_ftc.gov				spam traps