One of the simple sounding, yet complex, bifurcations in software
architectures is between static and dynamic typing of both code and
data. The split is most commonly recognized in programming languages.
Languages such as Pascal, Java, and Ada lean heavily towards a
statically typed view of the world. All variables are declared before
they are used. All variables have one, and only one, type associated
with them, which is allocated at design time and never changed at run-
time. Data objects persisted onto disk or on the Web must be of a
known "type" in order to be readable by statically typed languages.
Apart from some fundamental types like strings, integers and so on,
type information must be compiled into applications prior to execution.
Languages like Python, Scheme, and Basic lean heavily the other way --
toward a dynamic view of the concept of "type". Variables come into
existence as required; they don't have to be etched in stone at compile
time (indeed they may be no "compile time" at all). Variables can
change type dynamically in a running program. New types can come into
existence completely on the fly without even shutting down the
applications.
As is the case with all simple sounding bifurcations, this one is not
that simple -- not by a long shot. So-called static languages often
provide dynamic features. Java's Bean architectures, for example, are
based on dynamic discovery of type information (introspection).
The "reference to arbitrary object" facility in most statically typed
languages allows you to subvert static typing where required.
Conversely, so-called dynamic languages often provide static typing
features. Some, for example, let developers promise not to change the
type of a variable at run-time and thus allow the compiler/interpreter
to be cleverer in its dealings with the variable both at compile time
and at run time.
Switching now from code to data, both static and dynamic approaches are
to be seen in data as well. SGML, XML and HTML all exhibit leanings one-
way or the other, but the differences between the three big "MLs" on
this topic are interesting.
SGML is quintessentially static in its philosophy towards typing.
Everything has a declared type, every object (entity, element,
attribute) must be declared before it is used. SGML tools pride
themselves on their ability to catch problems before they occur by
forcing everything to be just so before proceeding.
HTML, and the Web in general, is quintessentially dynamic in its
philosophy. Resources (referenced by URIs) come and go. To link to a
resource from, say, a Web page, just name it. The very existence of the
resource linked to is not determined until run-time -- when you click
the link. If the resource exists, then you see it. If it doesn't, then
you get a 404 -- the Web equivalent of a software run-time error.
XML fall sin-between SGML and HTML when it comes to typing. The DTD
enforced requirement to declare all elements and all entities clearly
comes from the SGML static typing heritage. Well formedness, open
content models, XInclude, and Namespaces are all clearly from the
dynamic school of thought.
Both approaches have pros and cons but if I could only choose one, I
would definitely choose dynamic typing. Programming languages are
becoming more and more dynamically typed over time. Static languages
(such as Java) are developing dynamic features much faster than dynamic
languages (such as Python) are developing static features.
The Web itself is an excellent example of a system that trades off more
run-time errors (i.e., 404s) in return for greater architectural
flexibility. (Can you imagine having to "declare" every resource your
Web pages will link to?).
The opposing static versus dynamic view of the world is swinging into
full view in the Web Services arena at the moment. WSDL is an excellent
example of a static approach to typing. The REST architecture discussed
in an earlier article is an example of a more dynamic approach to
typing. At this stage, an overwhelming emphasis appears to be on the
static approach to architecting Web Services. The situation is made
more interesting by the fact that static entry points to Web Services
can and will exchange dynamically typed XML data.
The collision between the static and dynamic worldviews within the Web
services field is guaranteed to generate some interesting fireworks in
the years ahead. My money is on the dynamic view prevailing in the
longer term but a re-run of the PASCAL/SGML -- thou shalt declare
everything FIRST -- days seems inevitable in the short term.
