[plt-scheme] Continuations

Hi Noel

On 18/11/06, Noel Welsh <noelwelsh at yahoo.com> wrote:
> I meant pages, not sites, here.

I am on same line of thought :-)

> A couple of points:
>
> The easy point is that continuation based frameworks
> introduce a bunch of trade offs, and it is our job as the
> software developers to choose the right trade off for the
> situation.  Specifically, with continuations you gain ease
> of development but lose bookmarkability, and use more
> server resources.  For pages that reference ephemeral data,
> such as form validation pages, I believe continuations are
> the right approach.  For pages that reference relatively
> permanent data, I would choose another technique by
> default.

Noel, in my experience I have found that things start small and they
grow big when we're not looking. In due course, they go through the
growing pains. It becomes the job of architect to foresee and minimize
these pains, at which they fail more often they should. A page bearing
just ephemeral or static content today, grows to contain interactive
dynamic data tomorrow, and this is just one of the several problems.
So in my view having two or more different models to develop pages in,
only to change into another in due time is inconvenient - at least.

The primary issue at hand that I see mentioned is increased server
resource utilization, and the point I wanted to convey was that
runtime support for serialization and persistence may help alleviate
that to a significant extent, if not totally (it might totally, I'm
nobody to judge with my limited understanding of the system).


> The second and, I believe, more important important point
> is that all these problems can be solved given time and
> resources but you have to be careful of
> cart-before-horseism.  We could spend unbounded time
> developing the world's greatest web framework, and when we
> finished realise the world has moved on to something else.
> Better to build something that works now.  If it is

In 1990s the world was at CGI and supporting libraries built around
the interface written in imperative languages. It is same now. Few
names have changed though.

The applications were constructed with an entry point with a "switch"
inside to delegate to the correct handler back then - it is the same
even now. It was done in Perl back then, it's being done in Java EE
and RoR now. The differences lie mostly in automating most of the
grunt work and providing essential libraries in base system
("batteries included" approach) - all the work aimed squarely at
reducing the competence required. Nobody's winning so far.

The world hasn't moved anywhere[1]! Yes, I am aware that I'm again
making a very strong statement that might cause backlash, but I'm
sorry, I disagree that world will move somewhere else tomorrow so we
need to rush tonight!

> successful we'll acquire the resources to develop it
> further, faster.  The trick is to balance the messy demands
> and limited resources of now against the ultimate goal of
> simplicity and purity.  If we're aware of the goal we can
> make decisions that don't prevent us from someday getting
> there.  Which is a long winded way of saying I agree with
> all the points you raise, but don't think developing the
> ideal framework first is the best way to proceed.

Noel, I am not even pitching in for that direction. All I can say is I
don't know what is right or what is wrong - let alone what is ideal! I
have been studying different approaches and the continuations based
approach, right now looks most logical. That's it.

Now I also see certain short-comings of this approach and I am here to
discuss whether the approach that I came across - serialization and
persistence in particular, will lead towards a solution. Its a pure
discussion on possible approaches that I wish to carry on in this
thread, not any advocacy on what should or shouldn't be done!

Now going back to the issue - my bent is setting the direction from
the onset. Once the masses get behind,it is difficult to change
direction (c.f. Perl 5 -> 6, Groovy dev., C++9x -> C++0X, C++ -> D,
PHP DB connectivity APIs, EJB2.x/Struts/Hibernate/ -> EJB3/JSF.
Aberrations: ASP -> ASP.NET).

So I feel it is important not to set the "exceptions as part of rules"
precedence so early. There might be resource constraints in the
development dept. but I'm pretty sure there are no such constraints in
the research & philosophy departments :-)

Sincerely
- Akhilesh

PS: Somehow I sense that my statement was taken as an attack on
continuations based framework. I deny any such intention and offer my
apologies if such an intention was carried through.

[1] It might be only half true. World did move once from LISP to
FORTRAN... but was it ever on LISP ? Naah, the collective momentum of
6 billion people is just too much for world to move anywhere.