Hi Mukul,

I absolutely agree with that - imperative code isn't going away, but it is
increasingly shifting into being used as bindings for declarative constructs
rather than being "naked". Overall, binding architectures seem to give you
the best of both worlds - ease of validation combined with a rich object
model.

On Wed, Dec 3, 2008 at 7:52 PM, Mukul Gandhi <gandhi.mukul@g...> wrote:

> Hi Kurt,
>  Thanks for your thoughts.
>
> I agree that declarative programming is the main style of programming
> in web based applications, and for XML oriented tasks.
>
> But even in web based applications (say in JSP or ASP), we do use
> imperative code (e.g., a Java fragment in a JSP page).
>
> I think, saying that imperative programming will completely vanish in
> near future may not be correct.
>
> Imperative programming is needed for some lower level tasks. For e.g.,
> 1. File handling
> 2. Network programming
> 3. Implementing distributed programs
> 4. Implementing multi-threaded applications
>
> These are just some of the examples which come to my mind, which
> require imperative programming.
>
> On Thu, Dec 4, 2008 at 12:09 AM, Kurt Cagle <kurt.cagle@g...> wrote:
> > Mukul,
> >
> > Re: your examples -
> >
> > #1. Complex Business Logic. I've actually found that if you break
> business
> > logic down into state transitions, XML-based solutions are actually more
> > effective there than Java ones are, in part because of the templating
> > capabilities of XSLT, in part because it makes changing business logic
> > simply a matter of changing a particular set of pragmas in an XML
> document
> > (I've done some very sophisticated BL type work using ISO schematron, for
> > instance).
> > #2 Game Programming. Again I'd differentiate here between the rendering
> > modules (which I would agree should be handled only via imperative code
> > because of processing speed limitations, though it should be pointed out
> > that OpenGL is for the most part a declarative language) and game logic,
> > which I'd argue is a specialized case of #1. Note even here, though, most
> > game engines maintain declarative data objects with very low level (CRUD
> > type) APIs, rather than maintaining the overhead of a full OOP object for
> > every entity instance in the game. I wouldn't necessarily use XML here,
> but
> > that doesn't mean that what's involved isn't defined within the context
> of a
> > declarative state diagram and timed transformations on those diagrams.
> > #3 GUI Programming. Er, um ... given the migration to HTML/AJAX based
> > systems of nearly all GUI-based applications, I'd question this.
> > JavaScript/AJAX may be involved, but again its a relatively simple
> mapping
> > in both cases to turn external JavaScript working on objects into
> internal
> > JavaScript bindings to a declarative (XHTML or HTML) environment. My
> > suspicion is that by by 2015, imperative GUI programming will be rare.
> >
> > -- Kurt Cagle
> > -- Editor, xml.com
> > -- O'Rielly Media
>
>
>
> --
> Regards,
> Mukul Gandhi
>



-- 
Kurt Cagle
Managing Editor, xml.com
O'Reilly
kurt@o...