Skip to content.

Manageability

Sections
Personal tools
You are here: Home » blog » archive » Explicitness versus Loose Coupling

Explicitness versus Loose Coupling

20030504215450

"Visually Explicit Programming" talks about why it's necessary to have excplicit constructs in your programming language.  The presence of explicit constructs makes it possible for programs to perform analysis and therefore reason about code.

The main difference between static and dynamic typed systems is the explicit association of type information with variables.  The presence of this explicit construct makes it easier  for static analysis of typing rules.  The absence of the construct leads to looser coupling between modules. 

In fact, part of language design is making the tradeoff.  Making something explicit affords better analysis capabilities, the tradeof however is tighter coupling.  For instance, declarative languages do not make explicit the sequence of execution , this is a loose coupling between what needs to be done and how it is to be done.  This leads to more flexibility on how a program is executed.

Functional languages do not have state, to circumvent this deficiency, state is simulated explicitly via constructs like monads.  Imperative languages however do have state, but it's implicit, this makes it much harder to perform analysis of imperative languages as compared to functional languages.

Dynamic type languages make implicit type associated with variables.  This makes it more difficult to do type analysis.  The advantage however is a loose coupling of type with variables.  If type were associated with modules, this then implies a looser coupling between modules.  (of course the use of interfaces in Java leads to the same loose coupling)

In short explicitness affords better analysis.  Implicitness affords looser coupling.  In fact, Martin Fowler alludes to this in his article "To Be Explicit"

Explicitness is not an absolute in design, but clever designs often become hard to use because they aren't explicit enough.  In some cases, the cost is worth it, but it's always something to consider.

One wonders, do programmers of dynamic typed languages create tests because it's simply impossible for a human to reason about a dynamic typed program.  Rather, the reasoning is delegated to a test program? 

The debate of Static vs. Dynamic typing is a more about the tradeoffs of "Explicitness vs. Loose Coupling" and "Static Analysis vs. Runtime Testing".   Arguing about feeling liberated from strict typing, the terseness of the language or the inadequacy of compile time checking is missing to see the big picture.  Strict typing has its benefits, explicitness is sometimes good and runtime testing is something we all can't avoid.

Created by admin
Last modified 2003-07-30 04:14 PM
visitors
reading
 
 

Powered by Plone

This site conforms to the following standards: