Re: Y Store /Closures

[Sundar Narasimhan <address@hidden>]

   > Avi -- Thanks for your post.
   >
   > >The effect this all has on the maintainability of the code base is
   > >unbelievable.  And there is simply no way to get the same results
   > >without either having first class continuations in your language, or
   > >doing an automated transformation on all of your code to simulate them.
   >
   > What you seem to be talking about is simply maintaining and traversing
   > session state, no? Most frameworks I've used (struts, zope etc.) have
   > facilities for unwinding transactions and action chaining.

   Action chaining - sure.  My point has to do with what this action chaining
   specification looks like.  In Struts, you have a huge nest of XML
   configuration files that lay out what the flow from one "action" to the
   next is.  There is a *huge* difference between this and being able to
   specify the flow in a full programming language.

   What is the minimal piece of Java or XML or Python that shows the same
   kind of executable step-by-step definition of a task as I gave in my post?

Avi: You've gone from "cannot be done" to "cannot be done in as many
lines of code". I won't take that bait, Sorry. Because the lines of
code you are focussed on reducing is not what I (and other enterprise
developers are focused on -- supporting the back button in the manner
you describe is less than 5% of my use-cases). Thanks. I'll conclude
that thus far you seem to agree that in principle you can do w/out
continuations, but perhaps *you* think that in languages w/out such
support it might be verbose to implement "some" such traversals.
Would that be a fair characterization?

Personally speaking I feel that flows are very poorly characterized by
textual programs (regardless of the language they are in) that can
often represent only ONE serial course of action (it shows you how
dominant the single program-counter paradigm is :). struts 2-d
designers are a bit better in visualization of web app flows (I wonder
if "covigo" is still around -- you may want to look them up too), but
in any complex app, the flow diagrams tend to get fairly complex and
hard to manipulate. I take it you haven't used such tools.

   I have.  Not the same ballpark.  Again, the ability to specify the
   workflow in a method, not a configuration file, is *not* a minor feature.

Actually struts or zope (which doesn't have config. files btw) can
work the same way. I don't like to use the config files too heavily
either, although w/ some of the GUI builder tools that are emerging
(have you seen some of the Eclipse plugins for constructing struts
flows for example?) one could argue that there are different approaches
that hide that XML from the programmer.

   > In classical client-server GUI programming/literature -- the point you
   > raise was called the "event-driven vs. modal input" debate. We all
   > know who won that one now, don't we .. :)

   On the desktop.  The web is a very different environment, and modal input
   (or, more accurately, backtrackable and forkable modal input) is indeed
   the dominant paradigm.  The whole problem with most web app architectures
   is that they're trying to use event-driven solutions (MVC) for modal
   interfaces.

Personally speaking, I agree -- but the important distinction to make
is that customers are asking for more than just what the web
environment provides. So, I really wonder how long 
this backtrackable-forkable HTML/HTTP driven interface period will
last (already I have customers that are happier running a heavy rich-lient
app fronted by the likes of Citrix :).