Re: [xml-dev] 2007 Predictions

["Kurt Cagle" <kurt.cagle@gmail.com>]

I liken it to the need for both bone and sinew to construct a(n admittedly simplified) body. I've long been a proponent of JavaScript, but only in the context of providing those sinews and nerves. Any other imperative language could in theory do much the same, but even in XForms, which I've chosen to evangelize, there is a definite point where you cannot be in a completely declarative world.

One of the interesting aspects that I see about JavaScript, however, is that over time it has shifted away from being a pure imperative language. It takes a bit of work, but you can get to the point of saying "Here is an object:"

var Dom = {url:"http://www.myserver.com/myresources/myData",target:"myTarget",onerror:function(){reportError();}};

and work upon that object in a purely declarative, side-effect free manner:

var dom = Process.getInstance(Dom);

There is still certainly imperative programming there, but the conventions are shifting towards declarative models similar to those of Lisp, Scheme, and Haskell and curiously enough they are doing so largely due to the efforts of people who have never worked with those languages.

There's something primal about hashes - kind of an optimal mix of just enough structure to do what you need but not so much structure to get in the way, and hashes seem to be the single strongest common denominator of most declarative languages. When I point to the future being declarative, I think this is really what I see - hash core languages (and XML certainly qualifies as that) with minimal implied semantics (typing is "weak" or even associative rather than intrinsic) and a tendency away from hidden side effects becoming the dominant language in use. I don't see C++, Java, C#, et al. "going away" - the level of abstraction that declarative languages require often need to be built upon a more efficient substrate language, and that need will never go away, but what will happen is that the strongly imperative languages will increasingly be relegated to substrate work in supporting the weak, rather than being used outright.

This is one of the reasons why I think the browser is such an incredibly powerful concept. It is the (largely accidental) embodiment of this principle - a general purpose toolkit for supporting an array of declarative languages. The browser by itself largely exists in potentia - the interesting work occurs once you start pouring the declarative languages into it. This is why I tend to believe that stand-alone applications will, one by one, be subsumed into a GP browser over time as the processing power supports it - not because I think that the browser is any more efficient (it most certainly isn't) but because processors are now reaching a stage where the inefficiencies of the browser are becoming less of an issue then they were 1, 5 or 10 years ago. 

Context change is disruptive for most people - they don't want to leave the application that they are in to change contexts to another application unless they absolutely have to. I'd love to run Photoshop in my browser, to run Poser in my browser, to do all my word processing there - not because I LOVE my browser, but because all of these things ultimately have interdependencies - information I need for an article will be on the web, my communication IMs are done in the context of shared information in other spaces, and so forth.

I think Eclipse provides another good example of this process at work; Eclipse has become a common, general-purpose IDE that is rapidly moving beyond its original mandate for handling Java editing. Once you understand the conventions, Eclipse works quite well in keeping the hard part of context switching largely automated. The same, to a great extent, can be said to be true for Visual Studio, with the caveat that VS tends to work very well for its "universe" but handles things outside of that universe (Microsoft development) in increasingly poor fashion ... though of course the same thing can be said about Eclipse. To what extent can you push an IDE paradigm before it breaks is an interesting question.

Programming philosophies cycle (as do programming fashions). The broader the context set in a given application, the more work it takes to insure that the contexts can be integrated, and the more the tradeoffs of a standalone vs. an integrated become contentious. I see the broadest term solution being a mixed approach, in which the 80/20 rule becomes the operating paradigm - for a given application, give me extensions into a common suite for handling the 80% of cases where all I need to do are "minor" edits, and once I reach a critical threshhold (determined by me, not by the application) I can choose then to change my context to the standalone application - and once done I can return the object back into the context of the environment I was in. This has been the "promise" of programming for a long time, but outside of demos at trade-shows I find that it very seldom seems to work that way in practice unless you're willing to buy completely into the integration suite of a given vendor. Eclipse is coming closer to that paradigm (and not insignificantly Eclipse has also become the darling of the OSS community, largely for precisely that reason) but ultimately I see that the only way for this particular bar to be crossed is for abstraction-oriented declarative programming to become the norm rather than the exception. 

-- Kurt

On 1/20/07, Michael Champion <mc@xegesis.org> wrote:

> -----Original Message-----
> From: noah_mendelsohn@us.ibm.com [mailto:noah_mendelsohn@us.ibm.com]
> Sent: Friday, January 19, 2007 7:30 PM
> To: Michael Champion
> Cc: 'XML Developers List'
> Subject: RE: [xml-dev] 2007 Predictions
>
> A key point is that information captured in declarative form is typically
> much easier to extract and repurpose than information encoded
> procedurally.  Get me a table of stock quotes, and I can easily and
> probably securely import it into charting tools, database, AJAX clients,
> etc.  Give me instead a Javascript program which, it is asserted, will
> produce stock quotes as output and for many purposes I'm in much worse
> shape.  ...
>
> These points are all made somewhat more carefully in the recent TAG
> finding titled: "The Rule of Least Power

This finding reminds me of  the emperor in "Amadeus" telling Mozart that he
used too many notes.  If the Web really did follow the W3C's lead, the
current state-of-the-art web applications would never have been invented.
These tend to download semi-opaque blobs of Javascript which open a side
channel to the server for data, and the data tends to be JSON serialization
of internal objects more than declarative data. I can just hear Sir Tim
saying "It's quality work. There is simply too much power.  Just cut some of
that power and it will be perfect." :-)

That's not to deny that there are plenty of accessibility, security,
non-linkability, etc.  issues with AJAX (and XAML, applet, smart client,
etc.) applications, but they address lots of usability, performance, and
general clunkiness problems with the Web that cannot be denied. Portable
information, presumably encoded in XML, will hopefully be the foundation for
"Web n.0" but I don't think it is at all clear what mix of imperative and
declarative code will be used to process that information.

So I'd reiterate my earlier assertion - there's no clear winner in sight in
the declarative - imperative controversy.  The imperative folks (e.g the C#
and VB teams at Microsoft) are adding declarative features, the declarative
folks (e.g. the XQuery working group) are adding imperative features, all
because both are needed in any general purpose system.  Although it's hard
to disagree that data resources on the web should be as declarative and
repurposeable as possible within security/confidentiality constraints, the
very notion of a *service* resource implies some action to be taken, and
hence an ultimately imperative implementation.  The "principle of least
power" doesn't seem like a very helpful guide forward now, whatever value it
might have had in describing the principles extant when TimBL drafted it in
1998.


_______________________________________________________________________

XML-DEV is a publicly archived, unmoderated list hosted by OASIS
to support XML implementation and development. To minimize
spam in the archives, you must subscribe before posting.

[Un]Subscribe/change address: http://www.oasis-open.org/mlmanage/
Or unsubscribe: xml-dev-unsubscribe@lists.xml.org
subscribe: xml-dev-subscribe@lists.xml.org
List archive: http://lists.xml.org/archives/xml-dev/
List Guidelines: http://www.oasis-open.org/maillists/guidelines.php

-- 
Kurt Cagle
http://www.xforms.org