Declarative Architectures focus on the What, not the How, of programming. The How has dominated the field - perhaps 80% of programming is done in the traditional Imperative style, where we tell the computer How to do a task in explicit steps.

I'd like to show in this blog how Declarative Architectures and technologies are not just an interesting sideshow to the main Imperative attraction, but a complete and powerful programming alternative in their own right - indeed, one which has already dominated certain fields.

Imagine being able to simply express What we want the computer to do - to give it constraints and rules - then let it work out for itself How to achieve our goals.

I believe that saying What, not How, will become the dominant paradigm in programming.

What?

Declarative Architectures are about data: documents, assertions, truths, rules, tables, structures, state, bits. Data storage, changes, constraints, transformation, sharing, querying, fetching, interaction, presentation, subscription, tagging.

In summary, we talk about stuff, changes to stuff and rules governing stuff. Not processes, actions, jobs or functions.

It's amazing how many interesting Declarative technologies are actually out there already - especially given that most programming is Imperative. They tend to go unnoticed; subservient to their Imperative masters.

Here are some examples from our daily work life (assuming you work in computing!):

  • XML: XSL, XPath, XQuery, Schematron, RelaxNG, Xcerpt, XForms, XRules
  • Other MLs: XUL, XForms, XAML, YAML, ...
  • Relational DBs, SQL
  • Publish / Subscribe: 'this has changed', not 'do this'
  • Observer Pattern, MVC (maybe)
  • EII: architectures for business data and events 'landscapes'
  • JCache, SpiritCache: updateable, cascadable caches, 'active queries'
  • Business Rule programming
  • Spreadsheets
  • JNDI
  • Makefiles, Ant; Source Control: versioning, deltas

What all these have in common is that they are purely data- and event-driven or oriented. Not a thread in sight (if used properly). No method calls. Just querying, fetching, subscribing, tagging, declaring truths and rules, making changes to stuff, etc.

On the 'Net, all the dominant technologies are actually Declarative, not Imperative:

  • DNS
  • REST: URIs, HTTP
  • Mail, News: SMTP, NNTP
  • Instant Messaging; VoIP
  • P2P: BitTorrent, Gnutella
  • Multimedia: streaming, multicasting, PeerCast
  • Compression, Information Theory, Cryptography, Trust

Again, the same things are happening: querying, fetching, subscribing, tagging, declaring truths and rules, making changes to stuff.

Email (SMTP) is a great example of a Declarative Architecture, with its routing and transformation rules and self-addressed store-and-forward transmission. And, in fact, much the same applies to the rest of this list, where the Declarative aspects may include network querying and data events.

Imperative protocols such as RPC, RMI, CORBA, SOAP, etc. haven't had anywhere near the impact of their Declarative cousins.

Now, consider the 'Web 2.0' technologies:

  • HTTP/1.1, XHTML
  • Metadata: RSS, RDF, Atom, MicroFormats, tagging engines
  • REST Web APIs for XML metadata (including RSS/Atom)
  • DHTML; AJAX (when used as DOM updater), mod_pubsub
  • Identity; Single Sign-On Web-APIs: OpenID

This is a wonderful list of Declarative approaches (as long as we use REST APIs and talk about Resources, not SOAP ones talking about functions and jobs!).

So far, I've mentioned technologies that have attached themselves to the periphery of Imperative programming, where the actual behaviour is still driven procedurally, or How-like.

However, Declarative programming itself has a history at least as long as Imperative programming, and includes:

  • Lisp, Rewriting systems
  • Prolog, Deductive Databases, The Semantic Web
  • Rule-Driven systems, Knowledge Engineering, Cyc, Ontologies
  • Tuple Spaces, Javaspaces
  • Neural Networks, Genetic Algorithms, Cellular Automata
  • Example-based programming: Subtext

We can, if we choose, write 100% Declarative systems (even down to asynchronous or event-driven operating systems and hardware).

 

Wherefore?

In this blog, I'll be pointing out opportunities where we can benefit from the Declarative approach when it's ready.

Perhaps the biggest example of a Declarative Architecture that is ready to benefit us now is the Web. In contrast, the Imperative Service-Oriented Architecture model and so-called 'Web' Services are still weaning; still trying to get a life free of their huge standards consortia. REST, in its simplicity, ubiquity and straightforward usefulness is orders of magnitude more deployed than SOAP will likely ever be.

This blog is for discussing the common problems and solutions in Declarative technologies; seeing if ideas in one area can be used in another and seeing if we can distill their lessons and their approaches.

Ultimately, heading towards a unified, distributed Declarative programming technology landscape.

I hope you'll join me in my explorations into Declarative Architectures, in particular if you're interested in the currently most promising segment I mentioned: Web 2.0, and its application in Social Software.

Or the currently massive but little-mentioned segment: Peer-to-Peer, and its application to the disruption of, well you know, all those big technological and commercial hierarchies...