Languages that are static, dynamic and both

Software systems typically consist of low-level components

written in static and strongly type languages, strung together

with dynamic and loosely typed languages. (this is

still true of something like a stand-alone perl or python programme,

since the dynamic language calls standard routines written in C or C++).

By close coupling a mean an approach where there is a strong system

of typeing and other constraints which is implemented before

run time, so that explicitly coded run time checks are largely

unnecessary.

Neither approach is right or wrong per se.

Close binding is appropriate to components, because building blocks

need to be reliable. Close binding is also possible with small building

blocks, because everything in a non-distributed system can be compiled

and linked together at a single point in time. However, with dstributed

systems (web services, RPC calls), one part of a system can be upgraded

separately from the other parts. There is then no way of guaranteeing

apriori that data passed will be of the appropriate kind and format.

This problem can be ameliorated by sending meta data along with

messages (as in XML) so that recipients can dynamically check that

the sender and format are what they are expecting.

Whilst dynamic, loosely coupled systems, and the languages associated

with them, have grown considerably since the 1980s, it would be a mistake

to think that static languages will die. Dynamic languages require interpreters

and virtual machines, and you cannot have an infinite stack of these. A compiled

language is needed at the bottom of the stack. Interpreters,

system software and low-level libraries will continue to be written in C and C++,

the survivors of a number of procedural and strongly typed languages of the 1970s

and 1980s.

Whilst the typical complex system is written in multiple (at least two)

languages reflecting the different paradigms, there is no logical

necessity for this: specifically there is no necessity to adopt

a different *syntax* in order to achieve stronger constraints.

A multi-paradigm language could do it all.

The Object-Relational Impedance Mismatch

As described here:

http://en.wikipedia.org/wiki/Object-relational_impedance_mismatch

The origin of the problem is the expectation that everything should have an object description
or equivalent because the object view is general purpose. But in fact there is a more
general purpose paradigm: message passing. A method call on an object is  a special case of passing
a message, which is more tightly bound and less flexible with regard to when the resulting action
occurs and which object or process ultimately handles it.
Message-passing is a natural fit for the way database engines work.
database engines receive
messages (SQL queries) and generate responses from their encapsulated data.
Who cares in their encapsulated data isn’t object-style itself? The
point of  object orientation is encapsulation, and the point of encapsulation is that implementation
details don’t matter.

Encapsulation isnt an end in itself…the end is correctness of data. The ACID objectives are more general and powerful.