Serendipity is the Key to Code Reuse

In watching yet another ping pong game of compiled versus dynamic languages, I found myself mostly siding with the dynamic language crowd in the form of Steve Vinoski and Patrick Logan.  This time around the discussion was all about what to do with “average programmers”.  It all got started when some others posited that dynamic languages and RESTful architectures are for those who view progamming as art while statically checking the contract, whether speaking of languages or SOA’s, is what those who want to view programming as engineering should do.  I don’t want to get sidetracked by all of that background, because I will write about it some other time (is programming art or engineering, what to do with average programmes, yada, yada).  For this post, I was struck by one of the linked in tributaries that make the blogosphere such a powerful idea generator because it triggers that sudden tunneling of ideas between relatively unrelated spaces that sparks creativity.

Specifically, Vinoski mentioned almost completely in passing that REST is leads to serendipitous code reuse.  He provides just the one word, serendipity, with the link I’ve added to the word.  Well I can’t resist diving down a good looking rabbit hole when I see one, just to see what else there may be, and sure enough, it was worth the trip.  Stuart Charlton has a neat little post on serendipity and code reuse that crystallized some fuzzy thinking for me.  Stuart is an Enterprise Architect for BEA, which seems to me ought to predispose him to be much less enlightened, but being an INTP, I guess he couldn’t help himself blurting out some good stuff about REST.  Here is the goodness of Stu:

One problem with SOA is that it is very “heavy”, with a partial focus, like CBD before it, on planned reuse.

In some industries, planned “product line” reuse has been shown to work, such as with car platforms. It’s also appropriate for very general purpose programming libraries, etc., and could also be appropriate in software (there’s a fair amount of “software product lines” literature out there).

From this viewpoint, “build it and maybe people will use it later” is a bad thing. SOA proponents really dislike this approach, where one exposes thousands of services in hopes of serendipity — because it never actually happens.

Yet, on the Web, we do this all the time. The Web architecture is all about serendipity, and letting a thousand information flowers bloom, regardless of whether it serves some greater, over arching, aligned need. We expose resources based on use, but the constraints on the architecture enables reuse without planning. Serendipity seems to result from good linking habits, stable URIs, a clear indication of the meaning of a particular resource, and good search algorithms to harvest & rank this meaning.

This led my own little ESTJ overly top-down and logical mind to instantly make a list or continuum of choices surrounding code reuse, SOA, REST, and dynamic languages:

1.  Preplan everything and rigidly enforce the contracts:  Heavy SOA.  No hope for serendipity.

2.  Expose thousands of services in hopes of serendipity.  Lots of work if you use SOA-style mechanisms.  That’s why SOA proponents say it never happens.

3.  Use a lightweight protocol that exposes thousands of services almost for free: REST, we love you!

4.  Expose a language that can create any service as needed.  Whoa!  Where did that come from?

I’ll admit, #4 popped up unbidden.  In my defense, I have a sort of “Warfield’s Law” when it comes to computers that leaps to mind more frequently than it should:

All things become languages if they’re important enough.

If Adobe can make a language out of printing, I don’t see why this doesn’t merit a language too.  The Law is true too.  Computers do one thing especially uniquely: they are Turing machines.  Languages are their manifestation of that.  If it isn’t a language, it could be done by a toaster at some level and doesn’t need a real computer.  Conversely, if you don’t make it a language, you’re robbing yourself of the full power a computer can offer.

Getting back to the problem at hand, what could be better than a dynamic language for enabling serendipitous code reuse?  We can reorganize available code assets under the latest DSL of the day to solve an entirely new problem.  In the grand scheme of these distributed computing conglomerations, REST becomes the sort of assembly language for these DSL’s.  It gives us the universal impedance match we need to hook up our components.  The dynamic language massages that somewhat generic socket into something more recognizable and powerful for the particular domain we want to conquer today.  Tomorrow, we’ll build a new one, and it’ll be easy, because we have lots of RESTful components lying about and a nifty dyamic language that’s potent at composing them.

Perhaps I’ll run this thing on a Pile of Lamps while I’m at it.  I say that only partially in jest, because the Pile O’ Lamps crowd are speaking my language, at least in terms of making things into languages.  Aloof Schipperke writes that he sees SPOTs when thinking about the Pile of Lamps.  He goes through an abstraction exercise that got me thinking again.  Here is the original Lamp:

• Linux
• Apache
• MySQL
• P{HP,erl,ython}

Aloof says, “Wait, it’s more like this if we go up 10,000 feet”:

• Scripting Language
• HTTP
• Operating System
• Database

Do you see Warfield’s Law (everything becomes a language) at work yet?  What did the Scripting Language replace for many architectures?  The middle tier.  The application server.  Devilish complex, painful to operate, often extremely inefficient.  Beans of every variety abound.  J2EE et al ad nauseum.  Why put up with it?  Replace it with (drumroll please!):

A Scripting Language!

Now can we successfully combine all of these ingredients?   

• Component Bus for Reuse and Communication:  (RESTful or similar) 
• Scripting Language
• HTTP
• Operating System
• Database
• Utility Computing Infrastructure

That seems to me a potent next generation architecture for web software. 

Replacing pieces of code, framework, or whatever with a language is an extremely powerful chess move.  It’s turning a pawn into a queen.  It’s not easy to do, as most are not facile at creating languages.  But why bother, there are lots of nifty dynamic languages to choose from.  Now you’ve got another excuse to go look one up.