h1

Languages that are static, dynamic and both

November 25, 2010

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.

Advertisements

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: