intertwingly

Jon Udell: JavaScript, Perl, Python, .NET.  Could the same principles bring this Perl/Python research to fruition?

Depends on what your goals are.  As you so aptly put it in your thread on Ruby (the language), "To be free to innovate, which Ruby indisputably does in some important ways, a language has to carry a lot of baggage. Conversely a language that travels light, acquiring everything from its environment -- like any .NET language -- has limited scope for innovation."

This picture is likely to change dramatically when Parrot is ready.

One month ago today, Dave Winer described me as a patient evangelist.  Some may have noticed a gap after my last web services related essay entitled Dealing with Diversity.  The intent was always to follow this up with Coping with Change, but I was waiting for some clear and compelling example to emerge for the need to evolve an interface which was designed in a brittle fashion.  Ultimately I even wrote an essay about the waiting process itself.

Yesterday the magic event occurred.  While I knew it was only a matter of time, the actual interface that it occurred to exceeded my wildest expectations.  It is one that everyone in this community can relate to.  And as a bonus, the extensions do not originate from the owner.

And it gets even better.  Dave's " daring and clever" use of structs points out the need more clearly that I could ever have.  When " blasting a hole" for some data that one requires, one should always consider anything else that might follow.  Greg Pierce nails it when he talks about the mental leaps and specialized knowledge that this proliferation of interfaces creates.  Dave responds that he can't see the overhead.  Touché, Dave.

So, wouldn't it be better if everybody followed a design principle of placing all non-administrivia  request and response parameters into a struct?  In fact, why not build this into the protocol itself, so instead of:

<member>
  <name>dateCreated</name>
  <value>
    <dateTime.iso8601>
      20020314T08:29:24
    </dateTime.iso8601>
  </value>
</member>

One could simply say:

<dateCreated xsi:type="xsd:dateTime">
  20020314T08:29:24
</dateCreated>

Now, I am not so naïve to believe that I will convince anybody of this overnight.  But I will continue to patiently make statements like this and this whenever the opportunity presents itself.